DEBUG: relocate to fixed address
Subsystems (2)
cover DEBUG: relocate to fixed address
Hello,
U-Boot from NOR flash relocates itself to RAM erea. The relocation address is calaculated at runtime to get maxium contiguous space to load kernel. So it may vary after code changed. In the early debug phase it would be easier to handle if the relocation address does not change per build.
My idea is define fixed address as CONFIG_DEBUG_RELOC_FIX_ADDR in config file and relocate to the address. Then you don't need to execute 'bdinfo' command to get actual relocated address. It is done by the first patch.
The second patch is for u-boot_r, which is linked for fixed relocation address. When you want to symbolic debug after relocation, flash 'u-boot.bin' and load symbol from 'u-boot_r' to debugger.
(CF. When you want to symblic debug before relocation, load symbol from 'u-boot'
to debugger.)
This patch set is based on v2013.01-rc1. (Tell me if I should rebase.) This is for ARM, but similar change could apply for other arch.
Tetsuyuki Kobayashi (2):
DEBUG: fix relocation address
DEBUG: make u-boot_r which is linked for fixed relocation address
Makefile | 7 +++++-- arch/arm/lib/board.c | 9 ++++++++- config.mk | 5 +++++ include/configs/kzm9g.h | 4 ++++ 4 files changed, 22 insertions(+), 3 deletions(-)
Signature · 1 line
1.7.9.5
PATCH 1/2 DEBUG: fix relocation address
U-Boot from NOR flash relocates itself to RAM erea. The relocation address is calaculated at runtime to get maxium contiguous space to load kernel. So it may vary after code changed. In the early debug phase it would be easier to handle if the relocation address does not change.
This patch sets relocation address to fixed address specified by CONFIG_DEBUG_RELOC_FIX_ADDR. If there is no enough space after CONFIG_DEBUG_RELOC_FIX_ADDR, it is ignored.
patch to kzm9g.h is a example. CONFIG_DEBUG_RELOC_FIX_ADDR should be defined at each config file.
--- arch/arm/lib/board.c | 9 ++++++++- include/configs/kzm9g.h | 4 ++++ 2 files changed, 12 insertions(+), 1 deletion(-)
arch/arm/lib/board.c +8 -1
@@ -377,7 +377,14 @@ void board_init_f(ulong bootflag) addr &= ~(4096 -1 );debug ("Reserving %ldk for U-Boot at: %08lx\n" , gd->mon_len >>10 , addr); - +#ifdef CONFIG_DEBUG_RELOC_FIX_ADDR +if (addr >=CONFIG_DEBUG_RELOC_FIX_ADDR ) { + addr =CONFIG_DEBUG_RELOC_FIX_ADDR ; +debug ("Fixing relocation address to %08lx\n" , addr); + }else { +debug ("CONFIG_DEBUG_RELOC_FIX_ADDR is ignored. It should be less than %08lx\n" , addr); + } +#endif #ifndef CONFIG_SPL_BUILD /* * reserve memory for malloc() arena
include/configs/kzm9g.h +4 -0
@@ -23,6 +23,10 @@#undef DEBUG +/* Uncomment this to relocate to fixed address */ +/*#define CONFIG_DEBUG_RELOC_FIX_ADDR 0x5f800000 */ + +#define CONFIG_RMOBILE #define CONFIG_SH73A0 #define CONFIG_KZM_A9_GT
Signature · 1 line
1.7.9.5
PATCH 1/2 DEBUG: fix relocation address
Dear Tetsuyuki Kobayashi,
Quoted 10 lines · In message <[email protected]> you wrote:
U-Boot from NOR flash relocates itself to RAM erea. The relocation address is calaculated at runtime to get maxium contiguous space to load kernel. So it may vary after code changed. In the early debug phase it would be easier to handle if the relocation address does not change.
This patch sets relocation address to fixed address specified byCONFIG_DEBUG_RELOC_FIX_ADDR. If there is no enough space afterCONFIG_DEBUG_RELOC_FIX_ADDR, it is ignored.
patch tokzm9g.his a example.CONFIG_DEBUG_RELOC_FIX_ADDRshould be defined at each config file.
Quoted 5 lines
Signed-off-by Tetsuyuki Kobayashi <[email protected]>--- arch/arm/lib/board.c | 9 ++++++++- include/configs/kzm9g.h | 4 ++++ 2 files changed, 12 insertions(+), 1 deletion(-)
NAK for this patch for the general reasons outlined oin my summary reply to the cover letter.
In addition:
- If this is supposed to be a RFC patch series, then please add the RFC part to ALL patches, not only to the cover letter.
- Any changes to basic infrastucture like this have to be done in a general, architecture-independent way. Doing this for ARM only is not acceptable.
Best regards,
Wolfgang Denk
Signature · 5 lines
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de "Confound these ancestors.... They've stolen our best ideas!" - Ben Jonson
PATCH 2/2 DEBUG: make u-boot_r which is linked for fixed relocation address
In reply to Tetsuyuki KobayashiIf CONFIG_DEBUG_RELOC_FIX_ADDR is defined, make u-boot_r.
u-boot_r is ELF file which is linked for fixed relocation address specified by CONFIG_DEBUG_RELOC_FIX_ADDR. Feed this file to debugger to get relocated symbol addresses.
--- Makefile | 7 +++++-- config.mk | 5 +++++ 2 files changed, 10 insertions(+), 2 deletions(-)
Makefile +5 -2
@@ -405,6 +405,9 @@ ALL-$(CONFIG_NAND_U_BOOT) += $(obj)u-boot-nand.bin ALL-$(CONFIG_ONENAND_U_BOOT) += $(obj)u-boot-onenand.bin ALL-$(CONFIG_SPL) += $(obj)spl/u-boot-spl.bin ALL-$(CONFIG_OF_SEPARATE) += $(obj)u-boot.dtb $(obj)u-boot-dtb.bin +ifneq ($(CONFIG_DEBUG_RELOC_FIX_ADDR),) +ALL-y += $(obj)u-boot_r +endif # enable combined SPL/u-boot/dtb rules for tegra ifeq ($(SOC),tegra20)
@@ -540,10 +543,10 @@ GEN_UBOOT = \ cd $(LNDIR) && $(LD) $(LDFLAGS) $(LDFLAGS_$(@F)) \ $$UNDEF_LST $(__OBJS) \ --start-group $(__LIBS) --end-group $(PLATFORM_LIBS) \ - -Map u-boot.map -o u-boot + -Map u-boot.map -o $(notdir $@) endif -$(obj)u-boot: depend \ +$(obj)u-boot $(obj)u-boot_r: depend \ $(SUBDIR_TOOLS) $(OBJS) $(LIBBOARD) $(LIBS) $(LDSCRIPT) $(obj)u-boot.lds $(GEN_UBOOT) ifeq ($(CONFIG_KALLSYMS),y)
config.mk +5 -0
@@ -269,9 +269,14 @@ LDFLAGS += $(PLATFORM_LDFLAGS) LDFLAGS_FINAL += -Bstatic LDFLAGS_u-boot += -T $(obj)u-boot.lds $(LDFLAGS_FINAL) +LDFLAGS_u-boot_r := $(LDFLAGS_u-boot) + ifneq ($(CONFIG_SYS_TEXT_BASE),) LDFLAGS_u-boot += -Ttext $(CONFIG_SYS_TEXT_BASE) endif +ifneq ($(CONFIG_DEBUG_RELOC_FIX_ADDR),) +LDFLAGS_u-boot_r += -Ttext $(CONFIG_DEBUG_RELOC_FIX_ADDR) +endif LDFLAGS_u-boot-spl += -T $(obj)u-boot-spl.lds $(LDFLAGS_FINAL) ifneq ($(CONFIG_SPL_TEXT_BASE),)
Signature · 1 line
1.7.9.5
cover DEBUG: relocate to fixed address
In reply to Tetsuyuki KobayashiDear Tetsuyuki Kobayashi,
Quoted 5 lines · In message <[email protected]> you wrote:
U-Boot from NOR flash relocates itself to RAM erea. The relocation address is calaculated at runtime to get maxium contiguous space to load kernel. So it may vary after code changed. In the early debug phase it would be easier to handle if the relocation address does not change per build.
No, it is not. You still need to determine where it gets relocated to, and iot makes no difference for debugging wehter you enter one number or another one.
Any debugger out there today allows you to automatemost such operations by scripts or functions or macros you can define to help you doing that.
Quoted 3 lines
My idea is define fixed address as
CONFIG_DEBUG_RELOC_FIX_ADDRin config file and relocate to the address. Then you don't need to execute 'bdinfo' command to get actual relocated address. It is done by the first patch.
I'm not willing to accept such change. It appears to ad a (minimal) easement at first glance, but at the same time it bears potential to break a large number of other things, and not unlikely in areas which are why you need to run a debugger in the first place.
This makes no sense.
Quoted 5 lines
The second patch is for u-boot_r, which is linked for fixed relocation address. When you want to symbolic debug after relocation, flash 'u-boot.bin' and load symbol from 'u-boot_r' to debugger.
(CF. When you want to symblic debug before relocation, load symbol from 'u-boot'
to debugger.)
Why would that be needed? The standard ELF file has all debug information you ever may need.
Just to save the "load symbol table" command? Again, this is not
worth the effort on one side, and likely to break things in other places.
Best regards,
Wolfgang Denk
Signature · 8 lines
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de "The net result is a system that is not only binary compatible with 4.3 BSD, but is even bug for bug compatible in almost all features." - Avadit Tevanian, Jr., "Architecture-Independent Virtual Memory Management for Parallel and Distributed Environments: The Mach Approach"
cover DEBUG: relocate to fixed address
Quoted 6 lines · Wolfgang Denk
Dear Tetsuyuki Kobayashi,
In message <[email protected]> you
Quoted 2 lines · wrote:
U-Boot from NOR flash relocates itself to RAM erea. The relocation
Quoted 8 lines
address is
Quoted 1 line
calaculated at runtime to get maxium contiguous space to load
kernel. So it may
Quoted 1 line
vary after code changed. In the early debug phase it would be
easier to handle
Quoted 1 line
if the relocation address does not change per build.
No, it is not.
Maybe not for you, but for some of us it definitely would make things easier. I usually end up randomly peeking at some likely destinations until I find the expected content.
Quoted 7 lines
You still need to determine where it gets relocated to, and iot makes no difference for debugging wehter you enter one number or another one.
Any debugger out there today allows you to automatemost such operations by scripts or functions or macros you can define to help you doing that.
Just because you've managed to compensate for it doesn't mean it isn't annoying.
How am I going to script gdb to figure out the relocation address when I'm just running it on the image to get symbols, not actually connecting to the target?
Is such a script published anywhere?
Quoted 16 lines
Quoted 1 line
My idea is define fixed address as
CONFIG_DEBUG_RELOC_FIX_ADDRinconfig file
Quoted 1 line
and relocate to the address. Then you don't need to execute
'bdinfo' command to
Quoted 1 line
get actual relocated address. It is done by the first patch.
I'm not willing to accept such change. It appears to ad a (minimal) easement at first glance, but at the same time it bears potential to break a large number of other things, and not unlikely in areas which are why you need to run a debugger in the first place.
This makes no sense.
Quoted 1 line
The second patch is for u-boot_r, which is linked for fixed
relocation address.
Quoted 1 line
When you want to symbolic debug after relocation, flash
Quoted 8 lines
'u-boot.bin' and
Quoted 2 lines
load symbol from 'u-boot_r' to debugger.
(CF. When you want to symblic debug before relocation, load symbolfrom 'u-boot'
Quoted 1 line
to debugger.)
Why would that be needed? The standard ELF file has all debug information you ever may need.
If the symbols in the ELF ?file match where U-Boot is actually located, that avoids the need to manually apply the relocation offset every time you want to look at something.
Quoted 1 line
Just to save the "load symbol table" command?
Where would you get the symbol table to load that matches U-Boot post-relocation?
-Scott
cover DEBUG: relocate to fixed address
tis 2012-11-27 klockan 16:22 -0600 skrev Scott Wood:
Quoted 3 lines
How am I going to script gdb to figure out the relocation address when I'm just running it on the image to get symbols, not actually connecting to the target?
It can be calculated from ram size and size of your u-boot binary including bss (reported by size on the elf binary).
If you have u-boot running then bdinfo shows the address.
Hm.. wasn't there talk about a non-relocating u-boot binary for debugging? Isn't that more appropriate for what you are trying to accomplish?
Quoted 2 lines
Where would you get the symbol table to load that matches U-Boot post-relocation?
GDB supports symbol table relocation using add-symbol-file command.
Regards
Henrik
cover DEBUG: relocate to fixed address
Dear Henrik Nordstr?m,
Quoted 7 lines · In message <[email protected]> you wrote:
Quoted 4 lines
How am I going to script gdb to figure out the relocation address when I'm just running it on the image to get symbols, not actually connecting to the target?
It can be calculated from ram size and size of your u-boot binary including bss (reported by size on the elf binary).
This works only in very basic configurations of U-Boot.
Best regards,
Wolfgang Denk
Signature · 8 lines
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
A UNIX saleslady, Lenore,
Enjoys work, but she likes the beach more.
She found a good way
To combine work and play:
She sells C shells by the seashore.cover DEBUG: relocate to fixed address
In reply to Scott WoodDear Scott,
Quoted 10 lines · In message <1354054951.2317.14@tyr> you wrote:
Quoted 6 lines
Quoted 2 lines
vary after code changed. In the early debug phase it would be
easier to handle
Quoted 1 line
if the relocation address does not change per build.
No, it is not.
Maybe not for you, but for some of us it definitely would make things easier. I usually end up randomly peeking at some likely destinations until I find the expected content.
We have an entry with the relocation address in the global data structure. All you need to do is read that. You can even do this using a macro definition in GDB. There is no magic involved.
Quoted 6 lines
Quoted 3 lines
Any debugger out there today allows you to automatemost such operations by scripts or functions or macros you can define to help you doing that.
Just because you've managed to compensate for it doesn't mean it isn't annoying.
You fail to understand, or see only your specific, limited set of use cases.
Quoted 3 lines
How am I going to script gdb to figure out the relocation address when I'm just running it on the image to get symbols, not actually connecting to the target?
You cannot, and you need not.
If you are just running GDB on the image, without actually running it on the target, there is no need to consider the relocation at all. Just use the symbols of the ELF file as is.
But _if_ you are running on the target, then in general the relocation address is NOT known in advance, as it is computed dynamically, and even on the same system it may change from one run to the next, for example depending on settings of environment variables (like pram), etc.
Quoted 1 line
Is such a script published anywhere?
You are long enough in this business that I simply don't believe you if you claim you don't know how to read and print gd->relocaddr in GDB... Did you ever have a look at the documentation [1] ?
Quoted 3 lines
If the symbols in the ELF file match where U-Boot is actually located, that avoids the need to manually apply the relocation offset every time you want to look at something.
Typically, you run a debugger because soimething is not working as expected. In such a situation you want to debug the system that shows the problem, not something completely different. [If you have a generic problem that does not depend on specific settings, then just debug it in the sandbox.] In my experience there are more cases where a modified system (like one without relocation) just adds to the problems and is actually counter-productive.
Quoted 2 lines
Where would you get the symbol table to load that matches U-Boot post-relocation?
Well, if you really don't know all this after all the years, then maybe you might find it instructive to read the documentation, especially section "10.1.2. Debugging of U-Boot After Relocation" [1] ?
[1] http://www.denx.de/wiki/view/DULG/DebuggingUBoot#Section_10.1.2.
Best regards,
Wolfgang Denk
Signature · 4 lines
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de Things are not as simple as they seem at first. - Edward Thorp