Bloated binaries following the use of AT(...) linker script command

Bloated binaries following the use of AT(...) linker script command

[Prasad B]

Hello All,

To change the load address of an application through the AT(...)
command, the linker script has been changed as:

PHDRS {
-       text PT_LOAD FLAGS(7);  /* RWX */
+      text PT_LOAD AT(0xffffffff84000000) FLAGS(7);   /* RWX */
        note PT_NOTE FLAGS(4);  /* R__ */
}

However, due to the above change the executable bloats up from about
16MB to about a Gibabyte. The output of the readelf indicates that the
start of section headers shifted by large value:

Entry point address:             0xc00050b0
Start of program headers:    52 (bytes into file)
Start of section headers:      1069295608 (bytes into file)

Although the sum of the sizes of individual section is only about
16MB, the size of the segment (only one segment) increases by the
bloated size:

Program Headers:
Type        Offset        VirtAddr        PhysAddr      FileSiz
  MemSiz     Flg      Align
LOAD     0x002000 0xc0000000 0x84000000 0x3fbbc8a0 0x3fc27f50 RWE   0x2000

Could someone indicate the possible reasons for the bloating of the executable ?

thank you,
Prasad.

Re: Bloated binaries following the use of AT(...) linker script command

[Alan Modra]

On Mon, Jun 15, 2009 at 06:24:14PM -0700, Prasad B wrote:
> Could someone indicate the possible reasons for the bloating of the executable ?

Why are you specifying a 64-bit AT value for a 32-bit target?  My
guess is that you have ld compiled with a 64-bit vma (either 64-bit
host, at least one 64-bit target, or --enable-64-bit-bfd) and have hit
some ld code that isn't 64-bit clean.

Please submit a bugzilla report with a testcase.

-- 
Alan Modra
Australia Development Lab, IBM

Re: Bloated binaries following the use of AT(...) linker script command

[Prasad B]

On Mon, Jun 15, 2009 at 7:17 PM, Alan Modra<amodra@bigpond.net.au> wrote:

> Why are you specifying a 64-bit AT value for a 32-bit target?  My
> guess is that you have ld compiled with a 64-bit vma (either 64-bit
> host, at least one 64-bit target, or --enable-64-bit-bfd) and have hit
> some ld code that isn't 64-bit clean.

Thanks Alan for the response. I changed the value to a 32-bit one and
the problem persists.

PHDRS {
    text PT_LOAD AT(0x81000000) FLAGS(7);   /* RWX */
    note PT_NOTE FLAGS(4);  /* R__ */
}

Entry point address:               0xc00050b0
Start of program headers:      52 (bytes into file)
Start of section headers:        1069094904 (bytes into file)

The binary referred to in the problem is linux kernel.

thank you,
Prasad.

Re: Bloated binaries following the use of AT(...) linker script command

[John Reiser]

> PHDRS {
> -       text PT_LOAD FLAGS(7);  /* RWX */
> +      text PT_LOAD AT(0x84000000) FLAGS(7);   /* RWX */
>         note PT_NOTE FLAGS(4);  /* R__ */
> }

> Entry point address:             0xc00050b0
> Start of program headers:    52 (bytes into file)
> Start of section headers:      1069295608 (bytes into file)

> Program Headers:
> Type       Offset   VirtAddr   PhysAddr    FileSiz     MemSiz  Flg   Align
> LOAD     0x002000 0xc0000000 0x84000000 0x3fbbc8a0 0x3fc27f50 RWE   0x2000
> 
> Could someone indicate the possible reasons for the bloating of the executable ?

Somewhere there is a confusion between physical address and virtual address.
The bloat amount is about (0xc0000000 - 0x84000000) bytes, which is the
difference between VirtAddr and PhysAddr.

-- 

Re: Bloated binaries following the use of AT(...) linker script command

[Prasad B]

On Mon, Jun 15, 2009 at 9:01 PM, John Reiser<jreiser@bitwagon.com> wrote:

> Somewhere there is a confusion between physical address and virtual address.
> The bloat amount is about (0xc0000000 - 0x84000000) bytes, which is the
> difference between VirtAddr and PhysAddr.

Hi John,

You are spot on. I built the binary with and without the AT(...)
command and the size difference of the two binaries is exactly the
difference between virtual address (p_vaddr) and load address
(p_paddr).

truncated readelf output:

Start of section headers:      1018763256 (bytes into file) /* with AT(...) */
Start of section headers:          12130296 (bytes into file) /*
without AT(...) */

(gdb) p/x 1018763256 - 12130296 = 0x3c000000
(gdb) p/x 0xc0000000 - 0x84000000 = 0x3c000000

For the case without the AT(...) command:

PHDRS {
/* text PT_LOAD AT(0x84000000) FLAGS(7); */   /* RWX */
text PT_LOAD FLAGS(7);  /* RWX */
    ...
}

Corresponding program headers:

Program Headers:
Type       Offset  VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
LOAD     0x002000 0xc0000000 0xc0000000 0xb8b8a0 0xbf5f50 RWE 0x2000

thanks,
Prasad.

Re: Bloated binaries following the use of AT(...) linker script command

[Prasad B]

On Mon, Jun 15, 2009 at 9:01 PM, John Reiser<jreiser@bitwagon.com> wrote:

> Somewhere there is a confusion between physical address and virtual address.
> The bloat amount is about (0xc0000000 - 0x84000000) bytes, which is the
> difference between VirtAddr and PhysAddr.

Hi John,

You are spot on. I built the binary with and without the AT(...)
command and the size difference of the two binaries is exactly the
difference between virtual address (p_vaddr) and load address
(p_paddr).

truncated readelf output:

Start of section headers:      1018763256 (bytes into file) /* with AT(...) */
Start of section headers:          12130296 (bytes into file) /*
without AT(...) */

(gdb) p/x 1018763256 - 12130296 = 0x3c000000
(gdb) p/x 0xc0000000 - 0x84000000 = 0x3c000000

For the case without the AT(...) command:

PHDRS {
/* text PT_LOAD AT(0x84000000) FLAGS(7); */   /* RWX */
text PT_LOAD FLAGS(7);  /* RWX */
    ...
}

Corresponding program headers:

Program Headers:
Type       Offset  VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
LOAD     0x002000 0xc0000000 0xc0000000 0xb8b8a0 0xbf5f50 RWE 0x2000

thanks,
Prasad.

Re: Bloated binaries following the use of AT(...) linker script command

[Alan Modra]

On Mon, Jun 15, 2009 at 08:10:51PM -0700, Prasad B wrote:
> Thanks Alan for the response. I changed the value to a 32-bit one and
> the problem persists.
> 
> PHDRS {
>     text PT_LOAD AT(0x81000000) FLAGS(7);   /* RWX */
>     note PT_NOTE FLAGS(4);  /* R__ */
> }

Sorry, I should have looked properly at what you were trying to do
before my first reply..  AT in PHDRS specifies the load address of
the segment, but doesn't change the load address of sections
assigned to that segment.  No doubt your section load addresses are a
long way from 0x81000000, so the segment contains a lot of zeros.

-- 
Alan Modra
Australia Development Lab, IBM

Re: Bloated binaries following the use of AT(...) linker script command

[Prasad B]

On Tue, Jun 16, 2009 at 2:26 AM, Alan Modra <amodra@bigpond.net.au> wrote:

> On Mon, Jun 15, 2009 at 08:10:51PM -0700, Prasad B wrote:
> > Thanks Alan for the response. I changed the value to a 32-bit one and
> > the problem persists.
> >
> > PHDRS {
> >     text PT_LOAD AT(0x81000000) FLAGS(7);   /* RWX */
> >     note PT_NOTE FLAGS(4);  /* R__ */
> > }
>
> Sorry, I should have looked properly at what you were trying to do
> before my first reply..  AT in PHDRS specifies the load address of
> the segment, but doesn't change the load address of sections
> assigned to that segment.  No doubt your section load addresses are a
> long way from 0x81000000, so the segment contains a lot of zeros.

As the manual says "The AT command for a program header overrides the
section attribute". Since all sections could map into a lone segment,
isn't the above math a source of inflated binaries ?

Is there any alternative way (without causing bloated binaries) of
specifying that all sections be mapped into a lone segment and that
the virtual address of the segment is 0xc0000000 (3GB) and the load
address is 0x81000000 (in MIPS the address translates to physical
address of 0x1000000) ?

thank you,
Prasad.

Re: Bloated binaries following the use of AT(...) linker script command

[Alan Modra]

On Tue, Jun 16, 2009 at 02:05:11PM -0700, Prasad B wrote:
> On Tue, Jun 16, 2009 at 2:26 AM, Alan Modra <amodra@bigpond.net.au> wrote:
> > AT in PHDRS specifies the load address of
> > the segment, but doesn't change the load address of sections
> > assigned to that segment.  No doubt your section load addresses are a
> > long way from 0x81000000, so the segment contains a lot of zeros.
> 
> As the manual says "The AT command for a program header overrides the
> section attribute".

That's exactly what happened.  AT overrode the load address for the
segment rather than taking the load address from the first section in
the segment.

-- 
Alan Modra
Australia Development Lab, IBM