* Load addresses for ELF program headers on ARM @ 2010-10-11 0:47 Matt Fischer 2010-10-11 1:55 ` Alan Modra 0 siblings, 1 reply; 14+ messages in thread From: Matt Fischer @ 2010-10-11 0:47 UTC (permalink / raw) To: binutils I'm trying to link an executable for bare-metal ARM, and am running across something that seems like it's in violation of ARM's ELF spec. I'm still learning some of this, so please let me know if this is just a misunderstanding on my part. I'm attempting to make a ROM-style executable, where the data segment is tacked onto the end of the text segment, and code in the startup routine copies it to its final address in RAM. Here's a test program, and the corresponding linker script: int x=5; void _start() { int y = x; } SECTIONS { TEXT 0 : { *(.init) *(.fini) *(.text) *(.init_array) *(.fini_array) *(.jcr)} DATA 0x10000000 : AT( ADDR( TEXT ) + SIZEOF( TEXT ) ) { *(.data) } } I'm attempting to give the TEXT section an address of 0, and then give the DATA segment a relocation address of 0x10000000, but a load address directly after the text segment. After linking this program, the resulting executable has the following: Section Headers: [Nr] Name Type Addr Off Size ES Flg Lk Inf Al [ 1] TEXT PROGBITS 00000000 008000 0000b4 00 WAX 0 0 4 [ 2] DATA PROGBITS 10000000 010000 000008 00 WA 0 0 4 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align LOAD 0x008000 0x00000000 0x00000000 0x000b4 0x000b4 RWE 0x8000 LOAD 0x010000 0x10000000 0x000000b4 0x00008 0x00009 RW 0x8000 The linker created two program headers, one for TEXT, and one for DATA. The TEXT one looks fine--both vaddr and paddr are at 0. The DATA segment, however, has a problem. It's been given a vaddr of 0x10000000, and a paddr of 0x000000b4. The former is the section's relocation address, and the latter is its load address. However, the ARM spec for ELF states that segments should have vaddr set to their load address, and paddr set to 0 . Is there a way to convince the linker to do this? Thanks, Matt P.S. After typing all of this, I ran across http://cygwin.ru/ml/binutils/2002-09/msg00516.html, which basically seems to describe my problem. Is this pretty much just broken by design, then, or is there some way around it? The reason it's a problem for me is that I may be using these executables with other tools which do obey the ARM spec, so as it stands they will try to put code in the wrong places. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Load addresses for ELF program headers on ARM 2010-10-11 0:47 Load addresses for ELF program headers on ARM Matt Fischer @ 2010-10-11 1:55 ` Alan Modra 2010-10-11 2:43 ` Matt Fischer 2010-10-11 2:50 ` Daniel Jacobowitz 0 siblings, 2 replies; 14+ messages in thread From: Alan Modra @ 2010-10-11 1:55 UTC (permalink / raw) To: Matt Fischer; +Cc: binutils On Sun, Oct 10, 2010 at 07:46:58PM -0500, Matt Fischer wrote: > The linker created two program headers, one for TEXT, and one for > DATA. The TEXT one looks fine--both vaddr and paddr are at 0. The > DATA segment, however, has a problem. It's been given a vaddr of > 0x10000000, and a paddr of 0x000000b4. The former is the section's > relocation address, and the latter is its load address. However, the > ARM spec for ELF states that segments should have vaddr set to their > load address, and paddr set to 0. Which ARM ELF spec are you talking about? An old and buggy one, I'd guess. If the one you're looking at says that it is clearly in conflict with the parent SysV ELF ABI spec. This spec http://infocenter.arm.com/help/topic/com.arm.doc.ihi0044b/IHI0044B_aaelf.pdf is silent on p_vaddr and p_paddr. -- Alan Modra Australia Development Lab, IBM ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Load addresses for ELF program headers on ARM 2010-10-11 1:55 ` Alan Modra @ 2010-10-11 2:43 ` Matt Fischer 2010-10-11 3:29 ` Alan Modra 2010-10-11 2:50 ` Daniel Jacobowitz 1 sibling, 1 reply; 14+ messages in thread From: Matt Fischer @ 2010-10-11 2:43 UTC (permalink / raw) To: Matt Fischer, binutils Ok, that makes sense. So if I really do want to create one blob which will then perform its own relocations, it looks like I need to just put both of those sections into a single program header. It seems like I ought to be able to do that with the following script: SECTIONS { TEXT 0 : { *(.init) *(.fini) *(.text) *(.init_array) *(.fini_array) *(.jcr)} :main DATA 0x10000000 : AT( ADDR( TEXT ) + SIZEOF( TEXT ) ) { *(.data) } :main } PHDRS { main PT_LOAD; } However, when I do this, it creates one gigantic segment which has both sections at their relocation addresses, and zero-fills the 200MB or so in between them. It seems like the linker is not correctly respecting load addresses when it tries to fit sections into segments. Is that something that can be gotten around somehow? Thanks, Matt On Sun, Oct 10, 2010 at 8:55 PM, Alan Modra <amodra@gmail.com> wrote: > On Sun, Oct 10, 2010 at 07:46:58PM -0500, Matt Fischer wrote: >> The linker created two program headers, one for TEXT, and one for >> DATA. The TEXT one looks fine--both vaddr and paddr are at 0. The >> DATA segment, however, has a problem. It's been given a vaddr of >> 0x10000000, and a paddr of 0x000000b4. The former is the section's >> relocation address, and the latter is its load address. However, the >> ARM spec for ELF states that segments should have vaddr set to their >> load address, and paddr set to 0. > > Which ARM ELF spec are you talking about? An old and buggy one, I'd > guess. If the one you're looking at says that it is clearly in > conflict with the parent SysV ELF ABI spec. This spec > http://infocenter.arm.com/help/topic/com.arm.doc.ihi0044b/IHI0044B_aaelf.pdf > is silent on p_vaddr and p_paddr. > > -- > Alan Modra > Australia Development Lab, IBM > ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Load addresses for ELF program headers on ARM 2010-10-11 2:43 ` Matt Fischer @ 2010-10-11 3:29 ` Alan Modra 2010-10-11 3:39 ` Matt Fischer 0 siblings, 1 reply; 14+ messages in thread From: Alan Modra @ 2010-10-11 3:29 UTC (permalink / raw) To: Matt Fischer; +Cc: binutils On Sun, Oct 10, 2010 at 09:43:27PM -0500, Matt Fischer wrote: > However, when I do this, it creates one gigantic segment which has > both sections at their relocation addresses, and zero-fills the 200MB > or so in between them. It seems like the linker is not correctly > respecting load addresses when it tries to fit sections into segments. > Is that something that can be gotten around somehow? This is a 2.20 bug. With current mainline you'll get a warning section `DATA' can't be allocated in segment 0 but ld will place DATA immediately after TEXT in the segment. The warning is because the VMA for DATA is outside the virtual addresses covered by your program header. (The warning should probably say something to that effect rather than "can't be allocated" when the section *is* allocated there.) -- Alan Modra Australia Development Lab, IBM ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Load addresses for ELF program headers on ARM 2010-10-11 3:29 ` Alan Modra @ 2010-10-11 3:39 ` Matt Fischer 2010-10-11 14:44 ` Daniel Jacobowitz 0 siblings, 1 reply; 14+ messages in thread From: Matt Fischer @ 2010-10-11 3:39 UTC (permalink / raw) To: Matt Fischer, binutils On Sun, Oct 10, 2010 at 10:29 PM, Alan Modra <amodra@gmail.com> wrote: > On Sun, Oct 10, 2010 at 09:43:27PM -0500, Matt Fischer wrote: >> However, when I do this, it creates one gigantic segment which has >> both sections at their relocation addresses, and zero-fills the 200MB >> or so in between them. It seems like the linker is not correctly >> respecting load addresses when it tries to fit sections into segments. >> Is that something that can be gotten around somehow? > > This is a 2.20 bug. With current mainline you'll get a warning > section `DATA' can't be allocated in segment 0 > but ld will place DATA immediately after TEXT in the segment. The > warning is because the VMA for DATA is outside the virtual addresses > covered by your program header. (The warning should probably say > something to that effect rather than "can't be allocated" when the > section *is* allocated there.) Ah, excellent. Ok, so I'll just patch the binaries for now, and then pick up that change once it's available. Dan, any idea when that fix will make its way into Sourcery Lite? --Matt ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Load addresses for ELF program headers on ARM 2010-10-11 3:39 ` Matt Fischer @ 2010-10-11 14:44 ` Daniel Jacobowitz 2010-10-11 15:21 ` Matt Fischer 0 siblings, 1 reply; 14+ messages in thread From: Daniel Jacobowitz @ 2010-10-11 14:44 UTC (permalink / raw) To: Matt Fischer; +Cc: binutils On Sun, Oct 10, 2010 at 10:38:59PM -0500, Matt Fischer wrote: > On Sun, Oct 10, 2010 at 10:29 PM, Alan Modra <amodra@gmail.com> wrote: > > On Sun, Oct 10, 2010 at 09:43:27PM -0500, Matt Fischer wrote: > >> However, when I do this, it creates one gigantic segment which has > >> both sections at their relocation addresses, and zero-fills the 200MB > >> or so in between them. Â It seems like the linker is not correctly > >> respecting load addresses when it tries to fit sections into segments. > >> Â Is that something that can be gotten around somehow? > > > > This is a 2.20 bug. Â With current mainline you'll get a warning > > Â section `DATA' can't be allocated in segment 0 > > but ld will place DATA immediately after TEXT in the segment. Â The > > warning is because the VMA for DATA is outside the virtual addresses > > covered by your program header. Â (The warning should probably say > > something to that effect rather than "can't be allocated" when the > > section *is* allocated there.) > > Ah, excellent. Ok, so I'll just patch the binaries for now, and then > pick up that change once it's available. Dan, any idea when that fix > will make its way into Sourcery Lite? A bit off topic for this list but... If this fix is in assign_file_positions_for_load_sections, which I think it is, then it will be in our November releases. -- Daniel Jacobowitz CodeSourcery ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Load addresses for ELF program headers on ARM 2010-10-11 14:44 ` Daniel Jacobowitz @ 2010-10-11 15:21 ` Matt Fischer 2011-03-15 15:36 ` Matt Fischer 0 siblings, 1 reply; 14+ messages in thread From: Matt Fischer @ 2010-10-11 15:21 UTC (permalink / raw) To: Matt Fischer, binutils On Mon, Oct 11, 2010 at 9:44 AM, Daniel Jacobowitz <dan@codesourcery.com> wrote: > On Sun, Oct 10, 2010 at 10:38:59PM -0500, Matt Fischer wrote: >> On Sun, Oct 10, 2010 at 10:29 PM, Alan Modra <amodra@gmail.com> wrote: >> > On Sun, Oct 10, 2010 at 09:43:27PM -0500, Matt Fischer wrote: >> >> However, when I do this, it creates one gigantic segment which has >> >> both sections at their relocation addresses, and zero-fills the 200MB >> >> or so in between them. It seems like the linker is not correctly >> >> respecting load addresses when it tries to fit sections into segments. >> >> Is that something that can be gotten around somehow? >> > >> > This is a 2.20 bug. With current mainline you'll get a warning >> > section `DATA' can't be allocated in segment 0 >> > but ld will place DATA immediately after TEXT in the segment. The >> > warning is because the VMA for DATA is outside the virtual addresses >> > covered by your program header. (The warning should probably say >> > something to that effect rather than "can't be allocated" when the >> > section *is* allocated there.) >> >> Ah, excellent. Ok, so I'll just patch the binaries for now, and then >> pick up that change once it's available. Dan, any idea when that fix >> will make its way into Sourcery Lite? > > A bit off topic for this list but... If this fix is in > assign_file_positions_for_load_sections, which I think it is, > then it will be in our November releases. Perfect. Thanks to both of you for all your help with this. --Matt P.S. Dan--sorry, you're right, I should have queried for the Sourcery info elsewhere. Thanks for obliging me, though. :) ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Load addresses for ELF program headers on ARM 2010-10-11 15:21 ` Matt Fischer @ 2011-03-15 15:36 ` Matt Fischer 2011-03-16 4:29 ` Alan Modra 0 siblings, 1 reply; 14+ messages in thread From: Matt Fischer @ 2011-03-15 15:36 UTC (permalink / raw) To: Matt Fischer, binutils Sorry to resurrect this old thread, but I'm finally following up on this, and had a couple more questions. I've pulled in the newest version of binutils, which has the fix that Alan mentions above. The test program I used above now generates the expected results: int x=5; void _start() { int y = x; } SECTIONS { TEXT 0 : { *(.init) *(.fini) *(.text) *(.init_array) *(.fini_array) *(.jcr)} :main DATA 0x10000000 : AT( LOADADDR( TEXT ) + SIZEOF( TEXT ) ) { *(.data) } :main } PHDRS { main PT_LOAD; } I now see the following in readelf: Section Headers: [Nr] Name Type Addr Off Size ES Flg Lk Inf Al [ 0] NULL 00000000 000000 000000 00 0 0 0 [ 1] TEXT PROGBITS 00000000 008000 0000b4 00 WAX 0 0 4 [ 2] DATA PROGBITS 10000000 0080b4 000008 00 WA 0 0 4 [ 3] .bss NOBITS 10000008 0080bc 000001 00 WA 0 0 1 [ 4] .ARM.attributes ARM_ATTRIBUTES 00000000 0080bc 000030 00 0 0 1 [ 5] .comment PROGBITS 00000000 0080ec 00002a 01 MS 0 0 1 [ 6] .shstrtab STRTAB 00000000 008116 000043 00 0 0 1 [ 7] .symtab SYMTAB 00000000 0082c4 000260 10 8 32 4 [ 8] .strtab STRTAB 00000000 008524 0000df 00 0 0 1 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align LOAD 0x008000 0x00000000 0x00000000 0x000bc 0x000bd RWE 0x8000 Section to Segment mapping: Segment Sections... 00 TEXT The two sections I've set up are packed contiguously into a single program header, even though their relocation addresses are far apart in memory, because I've instructed them to have their load addresses adjacent to each other using the AT() keyword. So far so good. However, if I now attempt to objcopy this with '-O binary', it seems to ignore the load addresses of the sections, and tries to construct a huge file with the two sections at their relocation addresses. It seems like this is a bug, because it's ignoring the load addresses of the sections. Is this correct, or am I misunderstanding what objcopy is supposed to do in this case? Interestingly, objcopy does still do the right thing if I allow the sections to be placed in separate program headers. That is, if I do the following: SECTIONS { TEXT 0 : { *(.init) *(.fini) *(.text) *(.init_array) *(.fini_array) *(.jcr)} DATA 0x10000000 : AT( LOADADDR( TEXT ) + SIZEOF( TEXT ) ) { *(.data) } } giving me this: Section Headers: [Nr] Name Type Addr Off Size ES Flg Lk Inf Al [ 0] NULL 00000000 000000 000000 00 0 0 0 [ 1] TEXT PROGBITS 00000000 008000 0000b4 00 WAX 0 0 4 [ 2] DATA PROGBITS 10000000 010000 000008 00 WA 0 0 4 [ 3] .bss NOBITS 10000008 010008 000001 00 WA 0 0 1 [ 4] .ARM.attributes ARM_ATTRIBUTES 00000000 010008 000030 00 0 0 1 [ 5] .comment PROGBITS 00000000 010038 00002a 01 MS 0 0 1 [ 6] .shstrtab STRTAB 00000000 010062 000043 00 0 0 1 [ 7] .symtab SYMTAB 00000000 010210 000260 10 8 32 4 [ 8] .strtab STRTAB 00000000 010470 0000df 00 0 0 1 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align LOAD 0x008000 0x00000000 0x00000000 0x000b4 0x000b4 RWE 0x8000 LOAD 0x010000 0x10000000 0x000000b4 0x00008 0x00009 RW 0x8000 Section to Segment mapping: Segment Sections... 00 TEXT 01 DATA .bss then objcopy correctly places both sections next to each other in the binary file, at their load addresses. I can't tell what it's getting hung up on in the first case that causes it to think the sections need to be placed at their relocation addresses. Another thing I noticed, which is possibly related, is that when readelf looks at the program headers in the first example, it can't figure out the section to segment mapping correctly. Even though TEXT, DATA, and .bss are all located in the single phdr, it only shows TEXT. Is this confusion about where things live related to objcopy's inability to correctly convert the binary? In either case, does this look like a bug in the tool, or a bug in my understanding of how to use it? :) Thanks, Matt On Mon, Oct 11, 2010 at 10:21 AM, Matt Fischer <mattfischer84@gmail.com> wrote: > > On Mon, Oct 11, 2010 at 9:44 AM, Daniel Jacobowitz <dan@codesourcery.com> wrote: > > On Sun, Oct 10, 2010 at 10:38:59PM -0500, Matt Fischer wrote: > >> On Sun, Oct 10, 2010 at 10:29 PM, Alan Modra <amodra@gmail.com> wrote: > >> > On Sun, Oct 10, 2010 at 09:43:27PM -0500, Matt Fischer wrote: > >> >> However, when I do this, it creates one gigantic segment which has > >> >> both sections at their relocation addresses, and zero-fills the 200MB > >> >> or so in between them. It seems like the linker is not correctly > >> >> respecting load addresses when it tries to fit sections into segments. > >> >> Is that something that can be gotten around somehow? > >> > > >> > This is a 2.20 bug. With current mainline you'll get a warning > >> > section `DATA' can't be allocated in segment 0 > >> > but ld will place DATA immediately after TEXT in the segment. The > >> > warning is because the VMA for DATA is outside the virtual addresses > >> > covered by your program header. (The warning should probably say > >> > something to that effect rather than "can't be allocated" when the > >> > section *is* allocated there.) > >> > >> Ah, excellent. Ok, so I'll just patch the binaries for now, and then > >> pick up that change once it's available. Dan, any idea when that fix > >> will make its way into Sourcery Lite? > > > > A bit off topic for this list but... If this fix is in > > assign_file_positions_for_load_sections, which I think it is, > > then it will be in our November releases. > > Perfect. Thanks to both of you for all your help with this. > > --Matt > > P.S. Dan--sorry, you're right, I should have queried for the Sourcery > info elsewhere. Thanks for obliging me, though. :) ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Load addresses for ELF program headers on ARM 2011-03-15 15:36 ` Matt Fischer @ 2011-03-16 4:29 ` Alan Modra 2011-03-17 0:37 ` Matt Fischer 0 siblings, 1 reply; 14+ messages in thread From: Alan Modra @ 2011-03-16 4:29 UTC (permalink / raw) To: Matt Fischer; +Cc: binutils You might like to change the ELF_SECTION_IN_SEGMENT (hdr, phdr) in elf.c:_bfd_elf_make_section_from_shdr to ELF_SECTION_IN_SEGMENT_1 (hdr, phdr, 0, 0), and see what happens. -- Alan Modra Australia Development Lab, IBM ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Load addresses for ELF program headers on ARM 2011-03-16 4:29 ` Alan Modra @ 2011-03-17 0:37 ` Matt Fischer 2011-03-17 2:38 ` Alan Modra 0 siblings, 1 reply; 14+ messages in thread From: Matt Fischer @ 2011-03-17 0:37 UTC (permalink / raw) To: Matt Fischer, binutils; +Cc: Alan Modra That does seem to fix the problem. It looks like that change simply disables the VMA check on the section, which makes sense because in this model the section's VMA won't be inside of the segment anymore. Given that the code inside this block looks like it can correctly deal with a segment that contains noncontiguous VMA's, I'm assuming this change is ok to submit as an actual patch, correct? If so, I'd be happy to write it up and submit it, if you'd like. --Matt On Tue, Mar 15, 2011 at 11:29 PM, Alan Modra <amodra@gmail.com> wrote: > You might like to change the ELF_SECTION_IN_SEGMENT (hdr, phdr) in > elf.c:_bfd_elf_make_section_from_shdr to > ELF_SECTION_IN_SEGMENT_1 (hdr, phdr, 0, 0), and see what happens. > > -- > Alan Modra > Australia Development Lab, IBM > ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Load addresses for ELF program headers on ARM 2011-03-17 0:37 ` Matt Fischer @ 2011-03-17 2:38 ` Alan Modra 2011-03-17 2:56 ` Matt Fischer 0 siblings, 1 reply; 14+ messages in thread From: Alan Modra @ 2011-03-17 2:38 UTC (permalink / raw) To: Matt Fischer; +Cc: binutils On Wed, Mar 16, 2011 at 07:37:30PM -0500, Matt Fischer wrote: > That does seem to fix the problem. It looks like that change simply > disables the VMA check on the section, which makes sense because in > this model the section's VMA won't be inside of the segment anymore. > Given that the code inside this block looks like it can correctly deal > with a segment that contains noncontiguous VMA's, I'm assuming this > change is ok to submit as an actual patch, correct? If so, I'd be > happy to write it up and submit it, if you'd like. I figured the change would fix your particular testcase. The difficult part of "see what happens" is determining what this change might break, and convincing me or another binutils maintainer that the change is safe.. At the moment I don't have time to investigate that myself. > > --Matt > > On Tue, Mar 15, 2011 at 11:29 PM, Alan Modra <amodra@gmail.com> wrote: > > You might like to change the ELF_SECTION_IN_SEGMENT (hdr, phdr) in > > elf.c:_bfd_elf_make_section_from_shdr to > > ELF_SECTION_IN_SEGMENT_1 (hdr, phdr, 0, 0), and see what happens. -- Alan Modra Australia Development Lab, IBM ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Load addresses for ELF program headers on ARM 2011-03-17 2:38 ` Alan Modra @ 2011-03-17 2:56 ` Matt Fischer 0 siblings, 0 replies; 14+ messages in thread From: Matt Fischer @ 2011-03-17 2:56 UTC (permalink / raw) To: Matt Fischer, binutils On Wed, Mar 16, 2011 at 9:38 PM, Alan Modra <amodra@gmail.com> wrote: > On Wed, Mar 16, 2011 at 07:37:30PM -0500, Matt Fischer wrote: >> That does seem to fix the problem. It looks like that change simply >> disables the VMA check on the section, which makes sense because in >> this model the section's VMA won't be inside of the segment anymore. >> Given that the code inside this block looks like it can correctly deal >> with a segment that contains noncontiguous VMA's, I'm assuming this >> change is ok to submit as an actual patch, correct? If so, I'd be >> happy to write it up and submit it, if you'd like. > > I figured the change would fix your particular testcase. The > difficult part of "see what happens" is determining what this change > might break, and convincing me or another binutils maintainer that the > change is safe.. At the moment I don't have time to investigate that > myself. > That's fair. I admit this is a pretty odd edge case, and while it happens to come up in the specific thing I'm working on, that doesn't necessarily make it an overall priority for you guys. I'll try to take a bit of time to familiarize myself with the code, and see if I can make a case for it going in. And if nothing else, I can at least keep it as a local patch for the thing I'm working on. Thanks for all your help. --Matt ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Load addresses for ELF program headers on ARM 2010-10-11 1:55 ` Alan Modra 2010-10-11 2:43 ` Matt Fischer @ 2010-10-11 2:50 ` Daniel Jacobowitz 2010-10-11 3:28 ` Matt Fischer 1 sibling, 1 reply; 14+ messages in thread From: Daniel Jacobowitz @ 2010-10-11 2:50 UTC (permalink / raw) To: Matt Fischer, binutils On Mon, Oct 11, 2010 at 12:25:06PM +1030, Alan Modra wrote: > On Sun, Oct 10, 2010 at 07:46:58PM -0500, Matt Fischer wrote: > > The linker created two program headers, one for TEXT, and one for > > DATA. The TEXT one looks fine--both vaddr and paddr are at 0. The > > DATA segment, however, has a problem. It's been given a vaddr of > > 0x10000000, and a paddr of 0x000000b4. The former is the section's > > relocation address, and the latter is its load address. However, the > > ARM spec for ELF states that segments should have vaddr set to their > > load address, and paddr set to 0. > > Which ARM ELF spec are you talking about? An old and buggy one, I'd > guess. If the one you're looking at says that it is clearly in > conflict with the parent SysV ELF ABI spec. This spec > http://infocenter.arm.com/help/topic/com.arm.doc.ihi0044b/IHI0044B_aaelf.pdf > is silent on p_vaddr and p_paddr. My memory on this is a bit vague, but I think that the ARM debugger does behave as Matt described (or used to). You should be able to post-process the file, either with objcopy or a custom utility; it will be a simple one. -- Daniel Jacobowitz CodeSourcery ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Load addresses for ELF program headers on ARM 2010-10-11 2:50 ` Daniel Jacobowitz @ 2010-10-11 3:28 ` Matt Fischer 0 siblings, 0 replies; 14+ messages in thread From: Matt Fischer @ 2010-10-11 3:28 UTC (permalink / raw) To: Matt Fischer, binutils On Sun, Oct 10, 2010 at 9:50 PM, Daniel Jacobowitz <dan@codesourcery.com> wrote: > On Mon, Oct 11, 2010 at 12:25:06PM +1030, Alan Modra wrote: >> On Sun, Oct 10, 2010 at 07:46:58PM -0500, Matt Fischer wrote: >> > The linker created two program headers, one for TEXT, and one for >> > DATA. The TEXT one looks fine--both vaddr and paddr are at 0. The >> > DATA segment, however, has a problem. It's been given a vaddr of >> > 0x10000000, and a paddr of 0x000000b4. The former is the section's >> > relocation address, and the latter is its load address. However, the >> > ARM spec for ELF states that segments should have vaddr set to their >> > load address, and paddr set to 0. >> >> Which ARM ELF spec are you talking about? An old and buggy one, I'd >> guess. If the one you're looking at says that it is clearly in >> conflict with the parent SysV ELF ABI spec. This spec >> http://infocenter.arm.com/help/topic/com.arm.doc.ihi0044b/IHI0044B_aaelf.pdf >> is silent on p_vaddr and p_paddr. > > My memory on this is a bit vague, but I think that the ARM debugger > does behave as Matt described (or used to). You should be able to > post-process the file, either with objcopy or a custom utility; it > will be a simple one. This is second-hand information, but what I've been told is that the ARM debugger does indeed behave that way--that's the main use-case I'm trying to cover here. If that's the case, it sounds like the best way forward is just to create an image with multiple program headers, and then post-process them to have the load address in the vaddr field, even though that's not to spec. I'm new to objcopy--does it have facilities for changing the program headers? Most of its options just seem to be geared around messing with the section headers. --Matt ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2011-03-17 2:56 UTC | newest] Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2010-10-11 0:47 Load addresses for ELF program headers on ARM Matt Fischer 2010-10-11 1:55 ` Alan Modra 2010-10-11 2:43 ` Matt Fischer 2010-10-11 3:29 ` Alan Modra 2010-10-11 3:39 ` Matt Fischer 2010-10-11 14:44 ` Daniel Jacobowitz 2010-10-11 15:21 ` Matt Fischer 2011-03-15 15:36 ` Matt Fischer 2011-03-16 4:29 ` Alan Modra 2011-03-17 0:37 ` Matt Fischer 2011-03-17 2:38 ` Alan Modra 2011-03-17 2:56 ` Matt Fischer 2010-10-11 2:50 ` Daniel Jacobowitz 2010-10-11 3:28 ` Matt Fischer
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).