Any MIPS experts?

Any MIPS experts?

[Dave Korn]

http://sourceware.org/bugzilla/show_bug.cgi?id=702


  PR702 is about object file bloat introduced in recent binutils versions
owing to the alignment of one of the sections having been increased from
4kB->64kB; the linker is apparently placing explicit padding in the output
files.  We've been trying to fix this on the crossgcc list[*] without
success, having tried patches to both gcc[**] and gas[***], and I haven't
been able to track down any discussion of this issue from the mailing list
archives.

  Does any of this ring any bells with MIPS gurus on the list?  Has anyone
got a fix?  Is it meant to be like this or is it a real bug?


[*]   - http://sources.redhat.com/ml/crossgcc/2005-09/msg00158.html and
thread
[**]  - http://gcc.gnu.org/ml/gcc-patches/2004-06/msg01187.html
[***] - http://sources.redhat.com/ml/binutils/2005-02/msg00648.html

    cheers, 
      DaveK
-- 
Can't think of a witty .sigline today....

Re: Any MIPS experts?

[Mike Frysinger]

On Thursday 22 September 2005 09:14 am, Dave Korn wrote:
>   PR702 is about object file bloat introduced in recent binutils versions
> owing to the alignment of one of the sections having been increased from
> 4kB->64kB; the linker is apparently placing explicit padding in the output
> files.  We've been trying to fix this on the crossgcc list[*] without
> success, having tried patches to both gcc[**] and gas[***], and I haven't
> been able to track down any discussion of this issue from the mailing list
> archives.

we use this patch in uClibc:
http://www.uclibc.org/cgi-bin/viewcvs.cgi/trunk/buildroot/toolchain/binutils/2.16.1/400-mips-ELF_MAXPAGESIZE-4K.patch?rev=10552&view=markup
-mike

Re: Any MIPS experts?

[Thiemo Seufer]

Dave Korn wrote:
> 
> 
> http://sourceware.org/bugzilla/show_bug.cgi?id=702
> 
> 
>   PR702 is about object file bloat introduced in recent binutils versions
> owing to the alignment of one of the sections having been increased from
> 4kB->64kB; the linker is apparently placing explicit padding in the output
> files.  We've been trying to fix this on the crossgcc list[*] without
> success, having tried patches to both gcc[**] and gas[***], and I haven't
> been able to track down any discussion of this issue from the mailing list
> archives.

The .data is placed at some offset in address space (because IRIX did
the same), The introduction of alignment for 64k page size caused then
the preceeding text segment to get padded to the next 64k border instead
of the 4k padding used before.

>   Does any of this ring any bells with MIPS gurus on the list?  Has anyone
> got a fix?  Is it meant to be like this or is it a real bug?

From the ld changelog:

2005-06-01  Maciej W. Rozycki  <macro@linux-mips.org>

	* emulparams/elf32btsmip.sh: Unset DATA_ADDR.
	
This removes the weird separate .data for "traditional" (linux-like)
mips. Also, in some cases ld -N may be acceptable as a workaround for
the problem.


Thiemo

RE: Any MIPS experts?

[Dave Korn]

----Original Message----
>From: Thiemo Seufer
>Sent: 22 September 2005 16:49

> Dave Korn wrote:

>>   Does any of this ring any bells with MIPS gurus on the list?  Has
>> anyone got a fix?  Is it meant to be like this or is it a real bug?
> 
> From the ld changelog:
> 
> 2005-06-01  Maciej W. Rozycki  <macro@linux-mips.org>
> 
> 	* emulparams/elf32btsmip.sh: Unset DATA_ADDR.
> 
> This removes the weird separate .data for "traditional" (linux-like)
> mips. Also, in some cases ld -N may be acceptable as a workaround for
> the problem.


  Brilliant.  Thanks a load Thiemo!


    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....

RE: Any MIPS experts?

[Maciej W. Rozycki]

On Thu, 22 Sep 2005, Dave Korn wrote:

> > This removes the weird separate .data for "traditional" (linux-like)
> > mips. Also, in some cases ld -N may be acceptable as a workaround for
> > the problem.
> 
> 
>   Brilliant.  Thanks a load Thiemo!

 Note that the increased alignment shouldn't actually affect the size of 
files generated, as trailing padding for segments is supported for ELF 
without occupying file space (cf "file size" vs "memory size" for 
segments).  Thus if that's what happens, then there is a problem with that 
particular toolchain.

$ cat main.c
int main(void)
{
	return 0;
}
$ mipsel-linux-gcc -o main main.c
$ ls -la main
-rwxr-xr-x  1 macro macro 7378 Sep 23 16:21 main

  Maciej

RE: Any MIPS experts?

[Dave Korn]

----Original Message----
>From: Maciej W. Rozycki
>Sent: 23 September 2005 16:30

> On Thu, 22 Sep 2005, Dave Korn wrote:
> 
>>> This removes the weird separate .data for "traditional" (linux-like)
>>> mips. Also, in some cases ld -N may be acceptable as a workaround for
>>> the problem.
>> 
>> 
>>   Brilliant.  Thanks a load Thiemo!
> 
>  Note that the increased alignment shouldn't actually affect the size of
> files generated, as trailing padding for segments is supported for ELF
> without occupying file space (cf "file size" vs "memory size" for
> segments).  Thus if that's what happens, then there is a problem with that
> particular toolchain.
> 
> $ cat main.c
> int main(void)
> {
> 	return 0;
> }
> $ mipsel-linux-gcc -o main main.c
> $ ls -la main
> -rwxr-xr-x  1 macro macro 7378 Sep 23 16:21 main
> 
>   Maciej

     Hi Maciej, 

  What binutils and gcc versions did you use for that?  And can we compare
the output from "mipsel-linux-objdump -x main" with the kind of thing we
were seeing at e.g.

http://sources.redhat.com/ml/crossgcc/2005-09/msg00169.html

I'm not familiar with PHDRS, but I /think/ that these lines:

    LOAD off    0x00000000 vaddr 0x00400000 paddr 0x00400000 align 2**16
         filesz 0x00000ac0 memsz 0x00000ac0 flags r-x
    LOAD off    0x00010000 vaddr 0x10000000 paddr 0x10000000 align 2**16
         filesz 0x00000090 memsz 0x000000a0 flags rw-

indicate that the second LOAD section has been aligned in the output file
according to its load-time alignment.  The filesz field shows that there's
hardly any data in each, but the off field shows that the data segment is at
64kB in the file, doesn't it?


    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....

RE: Any MIPS experts?

[Maciej W. Rozycki]

On Fri, 23 Sep 2005, Dave Korn wrote:

>   What binutils and gcc versions did you use for that?  And can we compare

 They are 2.16.1 and 4.0.1, respectively.  The version of GCC used 
shouldn't really matter, though.

> the output from "mipsel-linux-objdump -x main" with the kind of thing we
> were seeing at e.g.

 Here's mine:

    LOAD off    0x00000000 vaddr 0x00400000 paddr 0x00400000 align 2**16
         filesz 0x000009a4 memsz 0x000009a4 flags r-x
    LOAD off    0x000009a4 vaddr 0x004409a4 paddr 0x004409a4 align 2**16
         filesz 0x000000a8 memsz 0x000000bc flags rw-

> I'm not familiar with PHDRS, but I /think/ that these lines:
> 
>     LOAD off    0x00000000 vaddr 0x00400000 paddr 0x00400000 align 2**16
>          filesz 0x00000ac0 memsz 0x00000ac0 flags r-x
>     LOAD off    0x00010000 vaddr 0x10000000 paddr 0x10000000 align 2**16
>          filesz 0x00000090 memsz 0x000000a0 flags rw-
> 
> indicate that the second LOAD section has been aligned in the output file
> according to its load-time alignment.  The filesz field shows that there's
> hardly any data in each, but the off field shows that the data segment is at
> 64kB in the file, doesn't it?

 You are right.

  Maciej

RE: Any MIPS experts?

[Dave Korn]

----Original Message----
>From: Maciej W. Rozycki
>Sent: 23 September 2005 17:39

> On Fri, 23 Sep 2005, Dave Korn wrote:
> 
>>   What binutils and gcc versions did you use for that?  And can we
>> compare 
> 
>  They are 2.16.1 and 4.0.1, respectively.  The version of GCC used
> shouldn't really matter, though.

  Yes, I can see that it should not, but we've been getting the bloat with
2.16.1 and 3.3.4.  So perhaps the gcc driver is sending different command
line flags (such as -N, for example) to the linker between these two
versions.  Can I see your "gcc -v" output?


    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....

RE: Any MIPS experts?

[Maciej W. Rozycki]

On Fri, 23 Sep 2005, Dave Korn wrote:

>   Yes, I can see that it should not, but we've been getting the bloat with
> 2.16.1 and 3.3.4.  So perhaps the gcc driver is sending different command
> line flags (such as -N, for example) to the linker between these two
> versions.  Can I see your "gcc -v" output?

 No problem (except I must have clearly not looked at the version number 
of GCC carefully enough previously) -- here it is:

$ mipsel-linux-gcc -v -o main main.c
Using built-in specs.
Target: mipsel-linux
Configured with: ../configure --prefix=/usr --mandir=/man 
--with-local-prefix=/mipsel-linux/local --enable-libc --disable-multilib 
--enable-shared --enable-static --with-system-zlib --enable-threads 
--cache-file=config.cache --build=i386-linux --host=i386-linux 
--target=mipsel-linux
Thread model: posix
gcc version 4.0.0
 /usr/libexec/gcc/mipsel-linux/4.0.0/cc1 -quiet -v main.c -quiet -dumpbase 
main.c -auxbase main -version -o /tmp/ccUerFNs.s
ignoring duplicate directory 
"/usr/lib/gcc/mipsel-linux/4.0.0/../../../../mipsel-linux/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/mipsel-linux/4.0.0/include
 /usr/mipsel-linux/include
End of search list.
GNU C version 4.0.0 (mipsel-linux)
        compiled by GNU C version 4.0.0.
GGC heuristics: --param ggc-min-expand=38 --param ggc-min-heapsize=15932
 /usr/lib/gcc/mipsel-linux/4.0.0/../../../../mipsel-linux/bin/as -EL 
-no-mdebug -mabi=32 -v -KPIC -o /tmp/ccaSPpXL.o /tmp/ccUerFNs.s
GNU assembler version 2.16.1 (mipsel-linux) using BFD version 2.16.1
 /usr/libexec/gcc/mipsel-linux/4.0.0/collect2 --eh-frame-hdr -EL 
-dynamic-linker /lib/ld.so.1 -o main 
/usr/lib/gcc/mipsel-linux/4.0.0/../../../../mipsel-linux/lib/crt1.o 
/usr/lib/gcc/mipsel-linux/4.0.0/../../../../mipsel-linux/lib/crti.o 
/usr/lib/gcc/mipsel-linux/4.0.0/crtbegin.o 
-L/usr/lib/gcc/mipsel-linux/4.0.0 -L/usr/lib/gcc/mipsel-linux/4.0.0 
-L/usr/lib/gcc/mipsel-linux/4.0.0/../../../../mipsel-linux/lib 
/tmp/ccaSPpXL.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc 
--as-needed -lgcc_s --no-as-needed 
/usr/lib/gcc/mipsel-linux/4.0.0/crtend.o 
/usr/lib/gcc/mipsel-linux/4.0.0/../../../../mipsel-linux/lib/crtn.o

  Maciej