* Put MIPS .mdebug.* sections at address 0
@ 2011-12-20 16:53 Joseph S. Myers
2011-12-20 17:15 ` Richard Sandiford
0 siblings, 1 reply; 2+ messages in thread
From: Joseph S. Myers @ 2011-12-20 16:53 UTC (permalink / raw)
To: binutils; +Cc: Richard Sandiford
I've observed prelink problems on MIPS that related to the
.mdebug.abi32 section being located at address 0x412cb0 and so being a
SHT_PROGBITS section located after a SHT_NOBITS section, something
prelink does not expect.
Logically being at that address should be harmless, since the section
is unallocated, but prelink isn't designed to work on completely
arbitrary valid ELF binaries (it needs cooperation from the linker).
As this section is an unallocated section much like .comment, 0 seems
like the most appropriate address for it just as .comment is placed at
address 0; this patch places all the .mdebug.* sections at address 0
(I don't know enough about the other MIPS-specific sections to know if
they should go there as well).
Tested with no regressions with cross to mips-linux-gnu. OK to
commit?
2011-12-20 Joseph Myers <joseph@codesourcery.com>
* emulparams/elf32bmip.sh (OTHER_SECTIONS): Put .mdebug.* sections
at address 0.
Index: ld/emulparams/elf32bmip.sh
===================================================================
RCS file: /cvs/src/src/ld/emulparams/elf32bmip.sh,v
retrieving revision 1.17
diff -u -r1.17 elf32bmip.sh
--- ld/emulparams/elf32bmip.sh 8 Aug 2008 19:24:49 -0000 1.17
+++ ld/emulparams/elf32bmip.sh 20 Dec 2011 16:43:44 -0000
@@ -64,12 +64,12 @@
OTHER_SECTIONS='
.gptab.sdata : { *(.gptab.data) *(.gptab.sdata) }
.gptab.sbss : { *(.gptab.bss) *(.gptab.sbss) }
- .mdebug.abi32 : { KEEP(*(.mdebug.abi32)) }
- .mdebug.abiN32 : { KEEP(*(.mdebug.abiN32)) }
- .mdebug.abi64 : { KEEP(*(.mdebug.abi64)) }
- .mdebug.abiO64 : { KEEP(*(.mdebug.abiO64)) }
- .mdebug.eabi32 : { KEEP(*(.mdebug.eabi32)) }
- .mdebug.eabi64 : { KEEP(*(.mdebug.eabi64)) }
+ .mdebug.abi32 0 : { KEEP(*(.mdebug.abi32)) }
+ .mdebug.abiN32 0 : { KEEP(*(.mdebug.abiN32)) }
+ .mdebug.abi64 0 : { KEEP(*(.mdebug.abi64)) }
+ .mdebug.abiO64 0 : { KEEP(*(.mdebug.abiO64)) }
+ .mdebug.eabi32 0 : { KEEP(*(.mdebug.eabi32)) }
+ .mdebug.eabi64 0 : { KEEP(*(.mdebug.eabi64)) }
.gcc_compiled_long32 : { KEEP(*(.gcc_compiled_long32)) }
.gcc_compiled_long64 : { KEEP(*(.gcc_compiled_long64)) }
'
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: Put MIPS .mdebug.* sections at address 0
2011-12-20 16:53 Put MIPS .mdebug.* sections at address 0 Joseph S. Myers
@ 2011-12-20 17:15 ` Richard Sandiford
0 siblings, 0 replies; 2+ messages in thread
From: Richard Sandiford @ 2011-12-20 17:15 UTC (permalink / raw)
To: Joseph S. Myers; +Cc: binutils
"Joseph S. Myers" <joseph@codesourcery.com> writes:
> I've observed prelink problems on MIPS that related to the
> .mdebug.abi32 section being located at address 0x412cb0 and so being a
> SHT_PROGBITS section located after a SHT_NOBITS section, something
> prelink does not expect.
>
> Logically being at that address should be harmless, since the section
> is unallocated, but prelink isn't designed to work on completely
> arbitrary valid ELF binaries (it needs cooperation from the linker).
> As this section is an unallocated section much like .comment, 0 seems
> like the most appropriate address for it just as .comment is placed at
> address 0; this patch places all the .mdebug.* sections at address 0
Agreed that that sounds like the best fix.
> (I don't know enough about the other MIPS-specific sections to know if
> they should go there as well).
Yeah, we should do it for .gcc_compiled_long* as well. OK with that change
for trunk and 2.22 branch.
Richard
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2011-12-20 17:15 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-12-20 16:53 Put MIPS .mdebug.* sections at address 0 Joseph S. Myers
2011-12-20 17:15 ` Richard Sandiford
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).