same prog, different sizes

Post by Jorge Almeida
I just noticed that the same program compiled with the same flags (in
particular, march=i686) have *very* different sizes, both before and
after stripping. On a prescott and a ION atom, about 4K. On a core i3,
about 8K.
I expected differences (prescott and atom always yielded different
sizes, slightly smaller on prescott), but this seems absurd. Or is it?
As you guess, I've not been touching very modern hw. Is this something
to be expected? Am I doing something wrong?
Any one with this experience?

I don't even get chance to test compile size difference - the current
CVS version is still producing broken programs for me.

gcc 4.9.1 stable (also tried snapshot)
haswell i5, 16gb ram

dietlibc 0.33 still works fine

Thanks,
Steven

Jorge Almeida

2014-09-16 21:00:33 UTC

On Tue, Sep 16, 2014 at 9:56 PM, Steven Honeyman

I don't even get chance to test compile size difference - the current
CVS version is still producing broken programs for me.
gcc 4.9.1 stable (also tried snapshot)
haswell i5, 16gb ram
dietlibc 0.33 still works fine
Thanks,
Steven

I forgot to mention that I'm talking about dietlibc 0.33. Compilation
of the CVS version (yesterday) failed on the i3. The programs work
fine with dietlibc 0.33 on atom and prescott. I didn't have a chance
to test it on the i3)

Jorge

Felix von Leitner

2014-09-17 08:33:03 UTC

Post by Jorge Almeida
I forgot to mention that I'm talking about dietlibc 0.33. Compilation
of the CVS version (yesterday) failed on the i3. The programs work
fine with dietlibc 0.33 on atom and prescott. I didn't have a chance
to test it on the i3)

I did not check anything in yesterday and compilation works for me.
Please give error messages for the compilation failure.

Felix

Jorge Almeida

2014-09-17 09:41:59 UTC

On Wed, Sep 17, 2014 at 9:33 AM, Felix von Leitner

I did not check anything in yesterday and compilation works for me.
Please give error messages for the compilation failure.

I will next saturday, can't get to the i3 before that. But this thread
was about the much bigger binaries in the i3, with diet 0.33. I'm at a
loss there.

Thanks

Jorge

Felix von Leitner

2014-09-17 12:35:06 UTC

Post by Jorge Almeida
I will next saturday, can't get to the i3 before that. But this thread
was about the much bigger binaries in the i3, with diet 0.33. I'm at a
loss there.

Possibilities that come to mind:

1) different compiler options (you edited Makefile)
2) different dietlibc flags (you edited dietfeatures.h)
3) different compiler

Felix

Jorge Almeida

2014-09-20 16:58:46 UTC

On Wed, Sep 17, 2014 at 1:35 PM, Felix von Leitner

Post by Jorge Almeida
I will next saturday, can't get to the i3 before that. But this thread
was about the much bigger binaries in the i3, with diet 0.33. I'm at a
loss there.

1) different compiler options (you edited Makefile)
2) different dietlibc flags (you edited dietfeatures.h)
3) different compiler

I sent to Google drive two compiled (unstripped) versions of the same
program, in case some elfwise person would take a look and find
something fishy:

srvmng_dietlibc_atom:
dietlibc-0.33
gcc 4.8.2
https://drive.google.com/file/d/0B42qvLQhgjZCTkUwOVo1NmEtcWM/edit?usp=sharing

srvmng_dietlibc_i3
dietlibc-0.33
gcc 4.8.3
https://drive.google.com/file/d/0B42qvLQhgjZCMHVvMm9QeW02cXc/edit?usp=sharing

Both were compiled with:
diet gcc -fdata-sections -ffunction-sections -Wl,--gc-sections
-fno-asynchronous-unwind-tables -std=c99 -Os -march=i686 -pipe
-fomit-frame-pointer -Wall -o srvmng srvmng.c

THNX

Jorge

Steven Honeyman

2014-09-20 17:32:15 UTC

Post by Jorge Almeida
On Wed, Sep 17, 2014 at 1:35 PM, Felix von Leitner

Post by Jorge Almeida
I will next saturday, can't get to the i3 before that. But this thread
was about the much bigger binaries in the i3, with diet 0.33. I'm at a
loss there.

1) different compiler options (you edited Makefile)
2) different dietlibc flags (you edited dietfeatures.h)
3) different compiler

I sent to Google drive two compiled (unstripped) versions of the same
program, in case some elfwise person would take a look and find

On your Gentoo i3... am I right in thinking you have a hardened/PaX
build environment?

Thanks,
Steven

Jorge Almeida

2014-09-20 17:36:51 UTC

On Sat, Sep 20, 2014 at 6:32 PM, Steven Honeyman

Post by Jorge Almeida
On Wed, Sep 17, 2014 at 1:35 PM, Felix von Leitner

Post by Jorge Almeida
I will next saturday, can't get to the i3 before that. But this thread
was about the much bigger binaries in the i3, with diet 0.33. I'm at a
loss there.

1) different compiler options (you edited Makefile)
2) different dietlibc flags (you edited dietfeatures.h)
3) different compiler

I sent to Google drive two compiled (unstripped) versions of the same
program, in case some elfwise person would take a look and find

On your Gentoo i3... am I right in thinking you have a hardened/PaX
build environment?

Nope. It's a standard profile, no fancy
stuff whatsoever (box is used to backups and compiling some stuff,
used mainly via ssh, not even X installed)

Thanks

Jorge

Steven Honeyman

2014-09-20 17:52:59 UTC

Post by Jorge Almeida
On Sat, Sep 20, 2014 at 6:32 PM, Steven Honeyman

Post by Jorge Almeida
On Wed, Sep 17, 2014 at 1:35 PM, Felix von Leitner

Post by Jorge Almeida
I will next saturday, can't get to the i3 before that. But this thread
was about the much bigger binaries in the i3, with diet 0.33. I'm at a
loss there.

1) different compiler options (you edited Makefile)
2) different dietlibc flags (you edited dietfeatures.h)
3) different compiler

I sent to Google drive two compiled (unstripped) versions of the same
program, in case some elfwise person would take a look and find

On your Gentoo i3... am I right in thinking you have a hardened/PaX
build environment?

Nope. It's a standard profile, no fancy
stuff whatsoever (box is used to backups and compiling some stuff,
used mainly via ssh, not even X installed)
Thanks
Jorge

Oh well, worth a guess! I just noticed this strange program header
entry (only in the i3 version), which google says has something to do
with PaX. They are both the same binary really, but the i3 has a few
kb of padding on the end (just empty space). I have no idea why; but
I'm sure someone will be able to help you.

...
0x65041580 off 0x00000000 vaddr 0x00000000 paddr 0x00000000 align 2**2
filesz 0x00000000 memsz 0x00000000 flags --- 2800

Thanks,
Steven.

Bela Lubkin

2014-09-22 01:12:47 UTC

Jorge Almeida and Steven Honeyman wrote:

Steven>>> On your Gentoo i3... am I right in thinking you have a hardened/PaX
Steven>>> build environment?

Jorge>> Nope. It's a standard profile, no fancy
Jorge>> stuff whatsoever (box is used to backups and compiling some stuff,
Jorge>> used mainly via ssh, not even X installed)

Steven> Oh well, worth a guess! I just noticed this strange program header
Steven> entry (only in the i3 version), which google says has something to do
Steven> with PaX. They are both the same binary really, but the i3 has a few
Steven> kb of padding on the end (just empty space). I have no idea why; but
Steven> I'm sure someone will be able to help you.

I think Steven's right. For instance, see:

https://blogs.gentoo.org/mgorny/2014/06/23/inlining-marchnative-for-distcc/

which says (about flags being bandied about by `gcc`):

" You may also notice -fstack-protector there. This is because nowadays
" Gentoo enables it by default.

-- the 2nd sentence links to:

http://sources.gentoo.org/gitweb/?p=proj/gentoo-news.git;a=blob;f=2014/2014-06-15-gcc48_ssp/2014-06-15-gcc48_ssp.en.txt

which certainly seems to support the claim.

The two binaries contain .comment sections with "GCC: (GNU) 4.8.2" and
"GCC: (Gentoo 4.8.3 p1.1, pie-0.5.9) 4.8.3"; in which I *think* the
"pie-0.5.9" is another hint about hardening.

Bela<

Jorge Almeida

2014-09-22 07:54:30 UTC

Post by Bela Lubkin
Steven>>> On your Gentoo i3... am I right in thinking you have a hardened/PaX
Steven>>> build environment?
Jorge>> Nope. It's a standard profile, no fancy
Jorge>> stuff whatsoever (box is used to backups and compiling some stuff,
Jorge>> used mainly via ssh, not even X installed)
Steven> Oh well, worth a guess! I just noticed this strange program header
Steven> entry (only in the i3 version), which google says has something to do
Steven> with PaX. They are both the same binary really, but the i3 has a few
Steven> kb of padding on the end (just empty space). I have no idea why; but
Steven> I'm sure someone will be able to help you.
https://blogs.gentoo.org/mgorny/2014/06/23/inlining-marchnative-for-distcc/
" You may also notice -fstack-protector there. This is because nowadays
" Gentoo enables it by default.
http://sources.gentoo.org/gitweb/?p=proj/gentoo-news.git;a=blob;f=2014/2014-06-15-gcc48_ssp/2014-06-15-gcc48_ssp.en.txt
which certainly seems to support the claim.

This looked promising. I tried it with -fno-stack-protector, but there
is no difference. I also added -fno-pie, still no joy.

Post by Bela Lubkin
The two binaries contain .comment sections with "GCC: (GNU) 4.8.2" and
"GCC: (Gentoo 4.8.3 p1.1, pie-0.5.9) 4.8.3"; in which I *think* the
"pie-0.5.9" is another hint about hardening.

$ eselect profile list
Available profile symlink targets:
[1] default/linux/x86/13.0 *
[2] default/linux/x86/13.0/selinux
[3] default/linux/x86/13.0/desktop
[4] default/linux/x86/13.0/desktop/gnome
[5] default/linux/x86/13.0/desktop/gnome/systemd
[6] default/linux/x86/13.0/desktop/kde
[7] default/linux/x86/13.0/desktop/kde/systemd
[8] default/linux/x86/13.0/developer
[9] hardened/linux/x86
[10] hardened/linux/x86/selinux
[11] hardened/linux/musl/x86
[12] default/linux/uclibc/x86
[13] hardened/linux/uclibc/x86

Maybe some hardening features are somehow pulled when compiling with -static?

Just in case this contains some usefull info:

$ gcc -### -march=native -x c -
Using built-in specs.
COLLECT_GCC=/usr/i686-pc-linux-gnu/gcc-bin/4.8.3/gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/i686-pc-linux-gnu/4.8.3/lto-wrapper
Target: i686-pc-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-4.8.3/work/gcc-4.8.3/configure
--host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --prefix=/usr
--bindir=/usr/i686-pc-linux-gnu/gcc-bin/4.8.3
--includedir=/usr/lib/gcc/i686-pc-linux-gnu/4.8.3/include
--datadir=/usr/share/gcc-data/i686-pc-linux-gnu/4.8.3
--mandir=/usr/share/gcc-data/i686-pc-linux-gnu/4.8.3/man
--infodir=/usr/share/gcc-data/i686-pc-linux-gnu/4.8.3/info
--with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/4.8.3/include/g++-v4
--with-python-dir=/share/gcc-data/i686-pc-linux-gnu/4.8.3/python
--enable-languages=c,c++,fortran --enable-obsolete --enable-secureplt
--disable-werror --with-system-zlib --disable-nls
--enable-checking=release --with-bugurl=https://bugs.gentoo.org/
--with-pkgversion='Gentoo 4.8.3 p1.1, pie-0.5.9'
--enable-libstdcxx-time --enable-shared --enable-threads=posix
--enable-__cxa_atexit --enable-clocale=gnu --disable-multilib
--disable-altivec --disable-fixed-point --with-arch=i686
--enable-targets=all --disable-libgcj --enable-libgomp
--disable-libmudflap --disable-libssp --enable-lto --without-cloog
Thread model: posix
gcc version 4.8.3 (Gentoo 4.8.3 p1.1, pie-0.5.9)
COLLECT_GCC_OPTIONS='-march=native'
/usr/libexec/gcc/i686-pc-linux-gnu/4.8.3/cc1 -quiet -
"-march=core-avx2" -mcx16 -msahf -mmovbe -maes -mpclmul -mpopcnt -mabm
-mno-lwp -mfma -mno-fma4 -mno-xop -mbmi -mbmi2 -mno-tbm -mavx -mavx2
-msse4.2 -msse4.1 -mlzcnt -mno-rtm -mno-hle -mrdrnd -mf16c -mfsgsbase
-mno-rdseed -mno-prfchw -mno-adx -mfxsr -mxsave -mxsaveopt --param
"l1-cache-size=32" --param "l1-cache-line-size=64" --param
"l2-cache-size=3072" "-mtune=core-avx2" -quiet -dumpbase - -auxbase -
-fstack-protector -o /tmp/ccxOOjI3.s
COLLECT_GCC_OPTIONS='-march=native'
/usr/lib/gcc/i686-pc-linux-gnu/4.8.3/../../../../i686-pc-linux-gnu/bin/as
--32 -o /tmp/ccm6d0Pe.o /tmp/ccxOOjI3.s
COMPILER_PATH=/usr/libexec/gcc/i686-pc-linux-gnu/4.8.3/:/usr/libexec/gcc/i686-pc-linux-gnu/4.8.3/:/usr/libexec/gcc/i686-pc-linux-gnu/:/usr/lib/gcc/i686-pc-linux-gnu/4.8.3/:/usr/lib/gcc/i686-pc-linux-gnu/:/usr/lib/gcc/i686-pc-linux-gnu/4.8.3/../../../../i686-pc-linux-gnu/bin/
LIBRARY_PATH=/usr/lib/gcc/i686-pc-linux-gnu/4.8.3/:/usr/lib/gcc/i686-pc-linux-gnu/4.8.3/../../../../i686-pc-linux-gnu/lib/../lib/:/usr/lib/gcc/i686-pc-linux-gnu/4.8.3/../../../../lib/:/lib/../lib/:/usr/lib/../lib/:/usr/lib/gcc/i686-pc-linux-gnu/4.8.3/../../../../i686-pc-linux-gnu/lib/:/usr/lib/gcc/i686-pc-linux-gnu/4.8.3/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-march=native'
/usr/libexec/gcc/i686-pc-linux-gnu/4.8.3/collect2 --eh-frame-hdr -m
elf_i386 -dynamic-linker /lib/ld-linux.so.2
/usr/lib/gcc/i686-pc-linux-gnu/4.8.3/../../../../lib/crt1.o
/usr/lib/gcc/i686-pc-linux-gnu/4.8.3/../../../../lib/crti.o
/usr/lib/gcc/i686-pc-linux-gnu/4.8.3/crtbegin.o
-L/usr/lib/gcc/i686-pc-linux-gnu/4.8.3
-L/usr/lib/gcc/i686-pc-linux-gnu/4.8.3/../../../../i686-pc-linux-gnu/lib/../lib
-L/usr/lib/gcc/i686-pc-linux-gnu/4.8.3/../../../../lib -L/lib/../lib
-L/usr/lib/../lib
-L/usr/lib/gcc/i686-pc-linux-gnu/4.8.3/../../../../i686-pc-linux-gnu/lib
-L/usr/lib/gcc/i686-pc-linux-gnu/4.8.3/../../.. /tmp/ccm6d0Pe.o -lgcc
--as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s
--no-as-needed /usr/lib/gcc/i686-pc-linux-gnu/4.8.3/crtend.o
/usr/lib/gcc/i686-pc-linux-gnu/4.8.3/../../../../lib/crtn.o

Thanks,

Jorge

Jorge Almeida

2014-09-20 17:08:13 UTC

On Wed, Sep 17, 2014 at 9:33 AM, Felix von Leitner

I did not check anything in yesterday and compilation works for me.
Please give error messages for the compilation failure.
Felix

Sep_20_2014_make.log
https://drive.google.com/file/d/0B42qvLQhgjZCT29YcHh3UXFUUGM/edit?usp=sharing

Jorge

Felix von Leitner

2014-09-17 08:26:02 UTC

Post by Steven Honeyman
I don't even get chance to test compile size difference - the current
CVS version is still producing broken programs for me.

Can you be a little more specific please?
It works fine for me.

Felix

Steven Honeyman

2014-09-17 17:13:13 UTC

Post by Steven Honeyman
I don't even get chance to test compile size difference - the current
CVS version is still producing broken programs for me.

Can you be a little more specific please?
It works fine for me.

Hi Felix,

I posted around a month ago to this mailing list the details, and this
is the same problem.
Here's an archive link: http://comments.gmane.org/gmane.linux.lib.dietlibc/1753

If there's anything you would like me to test/try/check please ask and I will.

Thanks,
Steven.

Steven Honeyman

2014-09-17 18:10:10 UTC

"produces broken programs" means to me "all programs compiled against it
don't work".
What you actually have is "one program does not work right, and I'm not
even sure it's dietlibc's fault". I for one have never heard of dash
and have trouble even finding the source code.

Really? It's been Debian's default shell for years https://wiki.debian.org/Shell
The source code is quite well hidden:
http://git.kernel.org/cgit/utils/dash/dash.git

If it worked in 0.33 fine, and the exact same source compiles without
a warning, error, or problem (in every libc known to man, including
klibc) - would that suggest it's a bug in dietlibc?
Do you have a test suite or suggestion for a bunch of "known good"
programs (that include tests), I can compile with both versions and
let you know the results?

Thanks,
Steven

Erik Weber

2014-09-17 22:07:16 UTC

Hi guys,

please provide concise descriptions:

- program to be compiled (f.i. dash x.x.z, file xxx.tgz from site yyy,
URL to download, GIT reference with download-day or something in this
direction),
- platform (f.i. Debian testing on ARM / I7... whatever hardware) ,
- compiler ("gcc --version" )
- which dietlibc (file... from URL....)
- what was expected behavior, and what was the real output
(compiler/linker; from program itself)

Sorry for typos.

Best regards
Erik Weber.

Really? It's been Debian's default shell for years https://wiki.debian.org/Shell
http://git.kernel.org/cgit/utils/dash/dash.git
If it worked in 0.33 fine, and the exact same source compiles without
a warning, error, or problem (in every libc known to man, including
klibc) - would that suggest it's a bug in dietlibc?
Do you have a test suite or suggestion for a bunch of "known good"
programs (that include tests), I can compile with both versions and
let you know the results?
Thanks,
Steven

Steven Honeyman

2014-09-17 22:53:46 UTC