This is the mail archive of the
binutils@sourceware.cygnus.com
mailing list for the binutils project.
Re: Possible problem debug sections default addresses on powerpc-linux-gnu
- To: Alan Modra <alan at linuxcare dot com dot au>
- Subject: Re: Possible problem debug sections default addresses on powerpc-linux-gnu
- From: Franz Sirl <Franz dot Sirl-kernel at lauterbach dot com>
- Date: Fri, 14 Apr 2000 01:34:40 +0200
- Cc: Ian Lance Taylor <ian at zembu dot com>,donnte at microsoft dot com,binutils at sourceware dot cygnus dot com
- References: <Pine.LNX.4.21.0004132218150.26457-100000@front.linuxcare.com.au>
Am Thu, 13 Apr 2000 schrieb Alan Modra:
>On Wed, 12 Apr 2000, Franz Sirl wrote:
>
>> while loading a vmlinux kernel file with debugging information, I got a warning
>> about some debug section addresses not being 0. I tracked this down to the
>> linkerscript "vmlinux.lds" used during kernel builds, which doesn't mention any
>> debug sections like .stab at all. After adding the debug section entries from
>> elf.sc to vmlinux.lds the warning went away.
>
>Try this patch, which implements Ian's suggestion about handling
>SEC_DEBUGGING & ~ (SEC_LOAD | SEC_ALLOC) sections. Ian, why not do this
>for all ~ (SEC_LOAD | SEC_ALLOC) sections?
>
>Note the change in pe.em to set all relocateable section start addresses.
>I don't know a great deal about pe, but this looks right to me. Someone
>who uses pe might like to check this patch out. Donn?
>
>--
>Linuxcare. Support for the Revolution.
>
>ld/ChangeLog
> * emultempl/elf32.em (gld${EMULATION_NAME}_place_section): Process
> ~SEC_ALLOC sections too. Init start address of debug sections.
> * emultempl/armelf.em (gld${EMULATION_NAME}_place_section): Ditto.
> * emultempl/pe.em (gld${EMULATION_NAME}_place_section): Ditto.
> Also set all relocateable section start addresses.
Hmm, doesn't seem to work. I applied this patch and your last one (keep
orphan sections in order) to hjl's .34 release to get comparable results, but I
have some problems here:
ld -T arch/ppc/vmlinux.lds -Ttext 0xc0000000 -Bstatic arch/ppc/kernel/head.o init/main.o init/version.o \
--start-group \
arch/ppc/kernel/kernel.o arch/ppc/mm/mm.o arch/ppc/lib/lib.o kernel/kernel.o mm/mm.o fs/fs.o ipc/ipc.o arch/ppc/math-emu/math-emu.o \
fs/filesystems.a \
net/network.a \
drivers/block/block.a drivers/char/char.a drivers/misc/misc.a drivers/net/net.a drivers/macintosh/macintosh.a arch/ppc/8xx_io/8xx_io.a drivers/net/net.a \
/cvsx/linux-2.2.13/lib/lib.a \
--end-group \
-o vmlinux
arch/ppc/kernel/head.o: In function `start_here':
arch/ppc/kernel/head.o(.text+0x2214): relocation truncated to fit: R_PPC_REL24 identify_machine
...
arch/ppc/kernel/kernel.o: In function `m8xx_init_IRQ':
arch/ppc/kernel/kernel.o(.text.init+0x558): relocation truncated to fit: R_PPC_REL24 cpm_interrupt_init
arch/ppc/kernel/kernel.o: In function `m8xx_init':
arch/ppc/kernel/kernel.o(.text.init+0x5cc): relocation truncated to fit: R_PPC_REL24 memcpy
arch/ppc/kernel/kernel.o(.text.init+0x610): relocation truncated to fit: R_PPC_REL24 strcpy
make: *** [vmlinux] Segmentation fault (core dumped)
make: *** Deleting file `vmlinux'
make[1]: Leaving directory `/cvsx/linux-2.2.13/arch/ppc/8xx_io'
The kernel was compiled with gcc-2.95.3pre and -gdwarf-2 and this was only a
relink, so I wonder what's going on here. Do your patches trigger a latent bug
on PPC? In case this is caused by the "keep orphan sections in order" patch,
would you mind doing a patch against the 2_10-branch?
Franz.