This is the mail archive of the
binutils@sourceware.cygnus.com
mailing list for the binutils project.
Re: A patch for http://sourceware.cygnus.com/ml/binutils/2000-04/msg00373.html
At 00:50 17.04.00, H . J . Lu wrote:
>On Mon, Apr 17, 2000 at 12:22:13AM +0200, Franz Sirl wrote:
> > Am Sun, 16 Apr 2000 schrieb H . J . Lu:
> > >The old gld${EMULATION_NAME}_place_orphan assumes it only processes
> > >SEC_ALLOC sections. When we allow ~SEC_ALLOC sections, we have to
> > >check it. This patch seems to fix
> > >
> > >http://sourceware.cygnus.com/ml/binutils/2000-04/msg00373.html
> > >
> > >
> > >--
> > >H.J. Lu (hjl@gnu.org)
> > >---
> > >2000-04-16 H.J. Lu <hjl@gnu.org>
> > >
> > > * emultempl/elf32.em (gld${EMULATION_NAME}_place_orphan): Take
> > > into account that we also proecess ~SEC_ALLOC sections when
> > > placing a section.
> > > * emultempl/armelf.em (gld${EMULATION_NAME}_place_orphan):
> > > Likewise.
> > > * emultempl/pe.em (gld${EMULATION_NAME}_place_orphan):
> > > Likewise.
> >
> > H.J., Alan,
> >
> > this patch solves the vmlinux relocation errors on PPC I got, but if I
> compile
> > the kernel with -gdwarf-2, it seems the debug sections no longer get
> merged now:
> >
> > 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 c0000000 010000 174318
> 00 AX 0 0 16
> > [ 2] .rodata PROGBITS c0174320 184320 0415e0
> 00 A 0 0 16
> > [ 3] .data PROGBITS c01bb000 1cb000 022f14
> 00 WA 0 0 16
> > [ 4] __ex_table PROGBITS c0204e48 214e48 000f50
> 00 A 0 0 4
> > [ 5] .data.cacheline_a PROGBITS c0205da0 215da0 000020
> 00 WA 0 0 4
> > [ 6] .text.init PROGBITS c0206000 216000 020270
> 00 AX 0 0 4
> > [ 7] .data.init PROGBITS c0226270 236270 0074b4
> 00 WA 0 0 4
> > [ 8] .text.pmac PROGBITS c022e000 23e000 002d2c
> 00 AX 0 0 4
> > [ 9] .data.pmac PROGBITS c0230d2c 240d2c 000020
> 00 WA 0 0 4
> > [10] .text.prep PROGBITS c0231000 241000 001070
> 00 AX 0 0 4
> > [11] .data.prep PROGBITS c0232070 242070 006b9c
> 00 WA 0 0 4
> > [12] .text.openfirmwar PROGBITS c0239000 249000 002bec
> 00 AX 0 0 4
> > [13] .data.openfirmwar PROGBITS c023bbec 24bbec 000200
> 00 WA 0 0 1
> > [14] .bss NOBITS c023c000 24c000 0436f0
> 00 WA 0 0 16
> > [15] .debug_abbrev PROGBITS 00000000 24c000 000000
> 00 0 0 1
> > [16] .debug_info PROGBITS 00000000 24c000 000000
> 00 0 0 1
> > [17] .debug_line PROGBITS 00000000 24c000 000000
> 00 0 0 1
> > [18] .eh_frame PROGBITS c01ddf14 1edf14 026f34
> 00 WA 0 0 4
> > [19] .debug_pubnames PROGBITS 00000000 24c000 000000
> 00 0 0 1
> > [20] .debug_aranges PROGBITS 00000000 24c000 000000
> 00 0 0 1
> > [21] .comment PROGBITS 00000000 24c000 000000
> 00 0 0 1
> > [22] .debug_abbrev0 PROGBITS 00000000 24c000 000000
> 00 0 0 1
> > [23] .debug_info0 PROGBITS 00000000 24c000 000000
> 00 0 0 1
> > [24] .debug_line0 PROGBITS 00000000 24c000 000000
> 00 0 0 1
> > [25] .debug_pubnames0 PROGBITS 00000000 24c000 000000
> 00 0 0 1
> > [26] .comment0 PROGBITS 00000000 24c000 000000
> 00 0 0 1
> > [27] .comment1 PROGBITS 00000000 24c000 000000
> 00 0 0 1
> > [28] .debug_aranges0 PROGBITS 00000000 24c000 000000
> 00 0 0 1
> > [29] .debug_pubnames1 PROGBITS 00000000 24c000 000000
> 00 0 0 1
> > [30] .debug_info1 PROGBITS 00000000 24c000 000000
> 00 0 0 1
> > [31] .debug_abbrev1 PROGBITS 00000000 24c000 000000
> 00 0 0 1
> > [32] .debug_line1 PROGBITS 00000000 24c000 000000
> 00 0 0 1
> > [33] .kstrtab PROGBITS c01b5900 1c5900 003a54
> 00 A 0 0 4
> > [34] __ksymtab PROGBITS c01b9354 1c9354 001c88
> 00 A 0 0 4
> > [35] .comment2 PROGBITS 00000000 24c000 000000
> 00 0 0 1
> > [36] .debug_aranges1 PROGBITS 00000000 24c000 000000
> 00 0 0 1
> > [37] .debug_pubnames2 PROGBITS 00000000 24c000 000000
> 00 0 0 1
> > [38] .debug_info2 PROGBITS 00000000 24c000 000000
> 00 0 0 1
> > [39] .debug_abbrev2 PROGBITS 00000000 24c000 000000
> 00 0 0 1
> > [40] .debug_line2 PROGBITS 00000000 24c000 000000
> 00 0 0 1
> > etc.
> >
> > H.J., I think you should be able to reproduce this on any Linux
> platform, if
> > you add -gdwarf-2 to the toplevel Linux Makefile (I used the
> gcc-2_95-branch to
> > compile, if that matters).
> >
>
>Could you please tell me what I should get? I will look into it
>tomorrow if I know what is the expected output.
Well, I would expect merged debug sections, close to that what happens with
a linker script mentioning the debug sections, eg. a single .debug_info
instead of .debug_info, .debug_info1, .debug_info2, etc.
Franz.