From: Aneesh V <aneesh@ti.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [RFC PATCH] arm: provide a CONFIG flag for disabling relocation
Date: Thu, 21 Apr 2011 12:26:14 +0530 [thread overview]
Message-ID: <4DAFD50E.7090705@ti.com> (raw)
In-Reply-To: <BANLkTinxJ0Nq=Q8-ua8eNOQ1pj-zmwFtvQ@mail.gmail.com>
Hi Simon, Wolfgang,
On Thursday 21 April 2011 12:04 AM, Simon Glass wrote:
> On Fri, Mar 25, 2011 at 11:35 AM, Albert ARIBAUD<albert.aribaud@free.fr> wrote:
>> Le 25/03/2011 17:12, Aneesh V a ?crit :
>>
>>> Another problem I have with relocation is that it makes debugging with
>>> JTAG debugers more difficult. The addresses of symbols in the ELF
>>> target are no longer valid. Of course, you can load the symbols at an
>>> offset from the original location. But one has to first enable debug
>>> prints, find the relocation offset, use it while loading the symbols
>>> before you can do source level debugging.
>>
>> Actually you don't need recompiling: simply set a breakpoint at the
>> entry of relocate_code and once you hit the bp, look up r2: it contains
>> the destination. If you want the offset rather than the absolute
>> address, set the breakpoint right after the 'sub r9, r6, r0' round line
>> 222: r9 will then give you the offset. Unload the current symbols,
>> reload the symbols with the relevant offset, and there you go.
>
> I would like to revisit this thread. I'm not sure how other people do
> development in U-Boot but I like to use an ICE and a source-level
> debugger for any significant effort. I think it should be possible to
> use a JTAG debugging just by loading the u-boot ELF file and running.
>
> With this patch (or something similar) this is possible. Without it,
> it is painful.
>
> To be clear, we are not talking here about creating a platform that
> doesn't use relocation, just that for development purposes it is
> convenient to be able to disable it.
Actually, I am not even sure why relocation shouldn't be disabled in my
platform for good. It may be useful to have things such as the frame
buffer at the end of available memory. But, IMHO, that can still be
done without relocating u-boot. That's what the patch does.Am I missing
something?
>
> Looking at the December thread
> http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/88067/focus=88262
>
> Aneesh:
>>> Shouldn't we provide a CONFIG option by which users can disable
>>> Elf relocation?
>
> Wolfgang:
>> Why should we? It would just make the code even more complicated, and
>> require a lot of additional test cases.
>
> From what I can see this is a new CONFIG option, two ifdefs in the
> board.c file, and optionally disabling the -pie position-independent
> executable option to reduce size. It is pretty trivial:
>
> arch/arm/config.mk | 2 ++
> arch/arm/lib/board.c | 5 +++++
> 2 files changed, 7 insertions(+), 0 deletions(-)
>
> Regards,
> Simon
>
>>
>> Amicalement,
>> --
>> Albert.
>> _______________________________________________
>> U-Boot mailing list
>> U-Boot at lists.denx.de
>> http://lists.denx.de/mailman/listinfo/u-boot
>>
next prev parent reply other threads:[~2011-04-21 6:56 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-25 13:12 [U-Boot] [RFC PATCH] arm: provide a CONFIG flag for disabling relocation Aneesh V
2011-03-25 13:27 ` Aneesh V
2011-03-25 14:12 ` Wolfgang Denk
2011-03-25 16:12 ` Aneesh V
2011-03-25 18:35 ` Albert ARIBAUD
2011-04-20 18:34 ` Simon Glass
2011-04-21 6:56 ` Aneesh V [this message]
2011-04-21 15:18 ` Simon Glass
-- strict thread matches above, loose matches on Subject: below --
2011-09-20 14:22 GROYER, Anthony
2011-09-20 18:09 ` Wolfgang Denk
2011-09-20 19:13 ` Albert ARIBAUD
2011-09-21 9:29 ` GROYER, Anthony
2011-09-21 10:45 ` Wolfgang Denk
2011-09-21 11:44 ` Albert ARIBAUD
2011-09-21 10:51 ` Albert ARIBAUD
2011-09-21 11:20 ` Andreas Bießmann
2011-09-21 12:03 ` Albert ARIBAUD
2011-09-21 12:31 ` Andreas Bießmann
2011-09-21 14:23 ` Albert ARIBAUD
2011-09-22 7:10 ` Andreas Bießmann
2011-09-29 16:14 ` Andreas Bießmann
2011-09-30 7:21 ` Simon Schwarz
2011-10-01 6:48 ` Albert ARIBAUD
2011-09-20 21:34 ` Simon Glass
2011-09-21 14:21 ` Aneesh V
2011-09-23 16:04 ` Simon Glass
2011-10-01 7:01 ` Albert ARIBAUD
2011-10-03 3:34 ` Simon Glass
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4DAFD50E.7090705@ti.com \
--to=aneesh@ti.com \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox