This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [PATCH 2/2] Add sparc IFUNC support to Gold.
> No, there are more differences than just that last value. ?Here
> is the stdout file from the test:
You could try doubling the origin values in the MEMORY section of
memory_test.t, in order to prevent the headers from merging with .sec0
in the first load segment, and .sec3 from being placed in the third
load segment with .sec4 and .sec5. Then you may need to modify the
patterns to ignore the values in the Offset column. For reference, I
modified memory_test.t as follows:
3,6c3,6
< region1 : ORIGIN = 0x1000, LENGTH = 0x1000 ,
< region2 (r) : org = 0x2000, len = 300
< region3 (wx) : o = 0x4000, l = 4
< region4 (!r) : o = 0x6000 + 60, len = 0x30 * 0x6
---
> region1 : ORIGIN = 0x2000, LENGTH = 0x1000 ,
> region2 (r) : org = 0x4000, len = 300
> region3 (wx) : o = 0x8000, l = 4
> region4 (!r) : o = 0xc000 + 60, len = 0x30 * 0x6
19c19
< .sec3 0x5000 : { *(*.sec3) }
---
> .sec3 0xa000 : { *(*.sec3) }
And I get the following load segments on x86_64:
Program Headers:
Type Offset VirtAddr PhysAddr
FileSiz MemSiz Flg Align
LOAD 0x000000 0x0000000000003000 0x0000000000003000
0x000190 0x000190 R 0x1000
LOAD 0x001000 0x0000000000004000 0x0000000000004000
0x000004 0x000004 R 0x1000
LOAD 0x001004 0x0000000000002000 0x0000000000004004
0x000004 0x000004 R 0x1000
LOAD 0x001008 0x0000000000004008 0x0000000000004008
0x000008 0x000008 R 0x1000
LOAD 0x002000 0x000000000000a000 0x000000000000a000
0x000004 0x000004 R 0x1000
LOAD 0x00203c 0x0000000000008000 0x000000000000c03c
0x000004 0x000004 R 0x1000
On Sparc, your offset values may differ, but with luck you'll get the
same section-to-segment mapping, and the PhysAddr values will be the
same. If that's the case, it should be possible to modify the patterns
in memory_test.sh to pass on all platforms.
I also get this when linking with the modified memory_test.t:
ld: warning: creating a segment to contain the file and program
headers outside of any MEMORY region
But I'm not really sure why I don't see that warning with the original
memory_test.t. I think it's OK with that warning, though.
-cary