From: Jeff Baker <jbaker@qnx.com>
To: Jeff Baker <jbaker@qnx.com>,
"'binutils@sources.redhat.com'" <binutils@sources.redhat.com>
Subject: RE: How do I prevent ld from merging PT_LOAD segments?
Date: Wed, 09 Jul 2003 20:50:00 -0000 [thread overview]
Message-ID: <1578FF984ABAD411AFA5000102C4BB5B04E41278@nimbus> (raw)
I've discovered that if I set the MAXPAGESIZE in the linker script to be the
same as the alignment of the PT_LOAD segment everything seems to fall back
into place.
Now my question becomes why did the alignment change from 4k to 32k?
> Ping.
>
> Oh, I was wrong about sh4. sh4 seems to work. It's just our arm and ppc
> ports that are broken.
>
> > In case it helps, here are two objdumps. The first is of a correct
> binary
> > linked with the 2.10.1 linker. The second is a bad binary linked with
> the
> > 2.12.1 linker. Both were linked from the same object files and using
> the
> > same linker script. I left off the symbol tables to keep this as short
> as
> > possible.
> >
> > portmap-good: file format elf32-littlearm
> > portmap-good
> > architecture: arm, flags 0x00000112:
> > EXEC_P, HAS_SYMS, D_PAGED
> > start address 0x00100bcc
> >
> > Program Header:
> > PHDR off 0x00000034 vaddr 0x00100034 paddr 0x00000000 align 2**2
> > filesz 0x000000c0 memsz 0x000000c0 flags r-x
> > INTERP off 0x000000f4 vaddr 0x001000f4 paddr 0x00000000 align 2**0
> > filesz 0x00000014 memsz 0x00000014 flags r--
> > LOAD off 0x00000000 vaddr 0x00100000 paddr 0x00100000 align 2**12
> > filesz 0x00001cb0 memsz 0x00001cb0 flags r-x
> > LOAD off 0x00001cb0 vaddr 0x00102cb0 paddr 0x00102cb0 align 2**12
> > filesz 0x00000164 memsz 0x00000204 flags rw-
> > DYNAMIC off 0x00001d7c vaddr 0x00102d7c paddr 0x00000000 align 2**2
> > filesz 0x00000098 memsz 0x00000098 flags rw-
> > NOTE off 0x00001e14 vaddr 0x00000000 paddr 0x00000000 align 2**2
> > filesz 0x00000050 memsz 0x00000000 flags ---
> >
> > Dynamic Section:
> > NEEDED librpc.so.2
> > NEEDED libsocket.so.2
> > NEEDED libc.so.2
> > INIT 0x100950
> > FINI 0x101ca4
> > HASH 0x100108
> > STRTAB 0x1005f0
> > SYMTAB 0x100280
> > STRSZ 0x21f
> > SYMENT 0x10
> > DEBUG 0x0
> > PLTGOT 0x102cd0
> > PLTRELSZ 0x130
> > PLTREL 0x11
> > JMPREL 0x100820
> > REL 0x100810
> > RELSZ 0x10
> > RELENT 0x8
> > private flags = 0: [interworking not enabled] [APCS-32] [floats passed
> in
> > integer registers] [absolute position]
> >
> > Sections:
> > Idx Name Size VMA LMA File off Algn
> > 0 .interp 00000014 001000f4 001000f4 000000f4 2**0
> > CONTENTS, ALLOC, LOAD, READONLY, DATA
> > 1 .note 00000000 00100108 00100108 00000108 2**0
> > CONTENTS, ALLOC, LOAD, READONLY, DATA
> > 2 .hash 00000178 00100108 00100108 00000108 2**2
> > CONTENTS, ALLOC, LOAD, READONLY, DATA
> > 3 .dynsym 00000370 00100280 00100280 00000280 2**2
> > CONTENTS, ALLOC, LOAD, READONLY, DATA
> > 4 .dynstr 0000021f 001005f0 001005f0 000005f0 2**0
> > CONTENTS, ALLOC, LOAD, READONLY, DATA
> > 5 .rel.bss 00000010 00100810 00100810 00000810 2**2
> > CONTENTS, ALLOC, LOAD, READONLY, DATA
> > 6 .rel.plt 00000130 00100820 00100820 00000820 2**2
> > CONTENTS, ALLOC, LOAD, READONLY, DATA
> > 7 .init 0000000c 00100950 00100950 00000950 2**2
> > CONTENTS, ALLOC, LOAD, READONLY, CODE
> > 8 .plt 00000270 0010095c 0010095c 0000095c 2**2
> > CONTENTS, ALLOC, LOAD, READONLY, CODE
> > 9 .text 000010d8 00100bcc 00100bcc 00000bcc 2**2
> > CONTENTS, ALLOC, LOAD, READONLY, CODE
> > 10 .fini 0000000c 00101ca4 00101ca4 00001ca4 2**2
> > CONTENTS, ALLOC, LOAD, READONLY, CODE
> > 11 .data 00000010 00102cb0 00102cb0 00001cb0 2**2
> > CONTENTS, ALLOC, LOAD, DATA
> > 12 .ctors 00000008 00102cc0 00102cc0 00001cc0 2**2
> > CONTENTS, ALLOC, LOAD, DATA
> > 13 .dtors 00000008 00102cc8 00102cc8 00001cc8 2**2
> > CONTENTS, ALLOC, LOAD, DATA
> > 14 .got 000000ac 00102cd0 00102cd0 00001cd0 2**2
> > CONTENTS, ALLOC, LOAD, DATA
> > 15 .dynamic 00000098 00102d7c 00102d7c 00001d7c 2**2
> > CONTENTS, ALLOC, LOAD, DATA
> > 16 .bss 000000a0 00102e14 00102e14 00001e14 2**3
> > ALLOC
> > 17 QNX_usage 00000003 00000000 00000000 00002a6c 2**0
> > CONTENTS, READONLY
> > 18 QNX_info 000000a4 00000000 00000000 00002a6f 2**0
> > CONTENTS, READONLY
> >
> > =================================================================
> >
> > portmap: file format elf32-littlearm
> > portmap
> > architecture: arm, flags 0x00000112:
> > EXEC_P, HAS_SYMS, D_PAGED
> > start address 0x00100b9c
> >
> > Program Header:
> > PHDR off 0x00000034 vaddr 0x00100034 paddr 0x00100034 align 2**2
> > filesz 0x000000c0 memsz 0x000000c0 flags r-x
> > INTERP off 0x000000f4 vaddr 0x001000f4 paddr 0x001000f4 align 2**0
> > filesz 0x00000014 memsz 0x00000014 flags r--
> > LOAD off 0x00000000 vaddr 0x00100000 paddr 0x00100000 align 2**15
> > filesz 0x00002e0c memsz 0x00002eac flags rwx
> > DYNAMIC off 0x00002c90 vaddr 0x00102c90 paddr 0x00102c90 align 2**2
> > filesz 0x000000c0 memsz 0x000000c0 flags rw-
> > NOTE off 0x00000108 vaddr 0x00100108 paddr 0x00100108 align 2**0
> > filesz 0x00000000 memsz 0x00000000 flags r--
> >
> > Dynamic Section:
> > NEEDED librpc.so.2
> > NEEDED libsocket.so.2
> > NEEDED libc.so.2
> > INIT 0x100920
> > FINI 0x101c74
> > HASH 0x100108
> > STRTAB 0x1005dc
> > SYMTAB 0x10027c
> > STRSZ 0x202
> > SYMENT 0x10
> > DEBUG 0x0
> > PLTGOT 0x102d60
> > PLTRELSZ 0x130
> > PLTREL 0x11
> > JMPREL 0x1007f0
> > REL 0x1007e0
> > RELSZ 0x10
> > RELENT 0x8
> > private flags = 2: [interworking not enabled] [APCS-32] [floats passed
> in
> > integer registers] [absolute position]
> >
> > Sections:
> > Idx Name Size VMA LMA File off Algn
> > 0 .interp 00000014 001000f4 001000f4 000000f4 2**0
> > CONTENTS, ALLOC, LOAD, READONLY, DATA
> > 1 .note 00000000 00100108 00100108 00000108 2**0
> > CONTENTS, ALLOC, LOAD, READONLY, DATA
> > 2 .hash 00000174 00100108 00100108 00000108 2**2
> > CONTENTS, ALLOC, LOAD, READONLY, DATA
> > 3 .dynsym 00000360 0010027c 0010027c 0000027c 2**2
> > CONTENTS, ALLOC, LOAD, READONLY, DATA
> > 4 .dynstr 00000202 001005dc 001005dc 000005dc 2**0
> > CONTENTS, ALLOC, LOAD, READONLY, DATA
> > 5 .rel.bss 00000010 001007e0 001007e0 000007e0 2**2
> > CONTENTS, ALLOC, LOAD, READONLY, DATA
> > 6 .rel.plt 00000130 001007f0 001007f0 000007f0 2**2
> > CONTENTS, ALLOC, LOAD, READONLY, DATA
> > 7 .init 0000000c 00100920 00100920 00000920 2**2
> > CONTENTS, ALLOC, LOAD, READONLY, CODE
> > 8 .plt 00000270 0010092c 0010092c 0000092c 2**2
> > CONTENTS, ALLOC, LOAD, READONLY, CODE
> > 9 .text 000010d8 00100b9c 00100b9c 00000b9c 2**2
> > CONTENTS, ALLOC, LOAD, READONLY, CODE
> > 10 .fini 0000000c 00101c74 00101c74 00001c74 2**2
> > CONTENTS, ALLOC, LOAD, READONLY, CODE
> > 11 .data 00000010 00102c80 00102c80 00002c80 2**2
> > CONTENTS, ALLOC, LOAD, DATA
> > 12 .dynamic 000000c0 00102c90 00102c90 00002c90 2**2
> > CONTENTS, ALLOC, LOAD, DATA
> > 13 .ctors 00000008 00102d50 00102d50 00002d50 2**2
> > CONTENTS, ALLOC, LOAD, DATA
> > 14 .dtors 00000008 00102d58 00102d58 00002d58 2**2
> > CONTENTS, ALLOC, LOAD, DATA
> > 15 .got 000000ac 00102d60 00102d60 00002d60 2**2
> > CONTENTS, ALLOC, LOAD, DATA
> > 16 .bss 000000a0 00102e0c 00102e0c 00002e0c 2**3
> > ALLOC
> >
> > > -----Original Message-----
> > > From: Jeff Baker [mailto:jbaker@qnx.com]
> > > Sent: July 7, 2003 4:08 PM
> > > To: 'binutils@sources.redhat.com'
> > > Subject: How do I prevent ld from merging PT_LOAD segments?
> > >
> > > We're currently in the process of moving from binutils-2.10.1 (Wow,
> > that's
> > > old) to binutils-2.12.1 (Wow, that's... not quite so old). I've
> > observed
> > > a
> > > new behaviour that I've confirmed is also in the current head branch.
> > >
> > > The newer binutils (arm, ppc and sh4) seem to be merging two PT_LOAD
> > > segments into one (x86 and mips don't). For various reasons we need
> to
> > > have
> > > both of these segments separate.
> > >
> > > My wild, uninformed theory is that this is the result of a new feature
> > > added
> > > after 2.10.1 that can be overridden somewhere in the linker scripts.
> > > Whether I'm correct or not, I don't know how to deal with this. I
> would
> > > appreciate an explanation of this behaviour if someone is feeling
> > > benevolent
> > > enough to give me one.
> > >
> > > Thanks,
> > > Jeff
next reply other threads:[~2003-07-09 20:50 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-07-09 20:50 Jeff Baker [this message]
2003-07-11 14:17 ` Nick Clifton
-- strict thread matches above, loose matches on Subject: below --
2003-07-11 14:28 Jeff Baker
2003-07-09 20:13 Jeff Baker
2003-07-08 19:41 Jeff Baker
2003-07-07 20:08 Jeff Baker
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1578FF984ABAD411AFA5000102C4BB5B04E41278@nimbus \
--to=jbaker@qnx.com \
--cc=binutils@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).