comp.lang.ada
 help / color / mirror / Atom feed
* Differences between gnat 4.4.5 and 4.5.1
@ 2011-03-10  6:01 Noel Duffy
  2011-03-10 13:48 ` Julian Leyh
  2011-03-21  8:35 ` Dmitry A. Kazakov
  0 siblings, 2 replies; 12+ messages in thread
From: Noel Duffy @ 2011-03-10  6:01 UTC (permalink / raw)


I recently started learning Ada using Fedora 14 and gcc-gnat 4.5.1 as my 
development environment and a copy of John Barne's book. I have another 
computer on which I installed Debian Squeeze and gcc-gnat-4.4.5. Both 
versions of gcc-gnat (I think it's gcc-gnat, the man pages describe it as 
GNU gnat) are the default versions from the distribution repositories. 
However, I noticed some differences in the generated executables created 
by these two compilers and I thought it worth investigating. The 
following (admittedly silly) program demonstrates the issue:

--
with Ada.Strings.Wide_Unbounded; use Ada.Strings.Wide_Unbounded;
with Ada.Text_IO;

procedure Hello is
   N:Unbounded_Wide_String;
begin
   Ada.Text_IO.Put_Line ("Hello World"); 
end Hello;
--

I compile on both environments with this command:

gnatmake -f -Os hello.adb -largs -s

On Fedora 14, the generated program looks like this:

$ ls -l hello
-rwxrwxr-x. 1 noeld noeld 36352 Mar 10 18:08 hello

On Debian, I see:

$ ls -l hello
-rwxr-xr-x 1 noeld noeld 13728 Mar 10 18:15 hello

I only notice this disparity in size when my programs use unbounded 
strings. I develop using dynamic languages like PHP and Python to earn a 
living so I use unbounded strings in pretty much everything. I compiled 
some larger programs and the size disparity seems to remain relatively 
fixed. E.g, I have one program whose executable is 110k on Fedora but 83k 
on Debian. Both compilers produce dynamically linked executable programs.
The programs all work equally well on both platforms.

I wonder whether what I am seeing is a result of a difference in gcc-gnat 
version, a difference in distribution packaging, or possibly a 
combination of both. Is there anyone using Fedora here who could possibly 
shed any light on this?

I must say that Ada development on Debian looks much nicer than Fedora: 
GPS is packaged along with GTK and POSIX bindings, and not forgetting the 
Ada standard in html. 



^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Differences between gnat 4.4.5 and 4.5.1
  2011-03-10  6:01 Differences between gnat 4.4.5 and 4.5.1 Noel Duffy
@ 2011-03-10 13:48 ` Julian Leyh
  2011-03-10 21:32   ` Mart van de Wege
  2011-03-10 21:36   ` Noel Duffy
  2011-03-21  8:35 ` Dmitry A. Kazakov
  1 sibling, 2 replies; 12+ messages in thread
From: Julian Leyh @ 2011-03-10 13:48 UTC (permalink / raw)


On 10 Mrz., 07:01, Noel Duffy <hobcraft-use...@yahooxtra.co.nz> wrote:
> I wonder whether what I am seeing is a result of a difference in gcc-gnat
> version, a difference in distribution packaging, or possibly a
> combination of both. Is there anyone using Fedora here who could possibly
> shed any light on this?

What do "file" and "ldd" tell you about them? Are the sizes more
similar if you "strip" them?



^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Differences between gnat 4.4.5 and 4.5.1
  2011-03-10 13:48 ` Julian Leyh
@ 2011-03-10 21:32   ` Mart van de Wege
  2011-03-10 21:39     ` Ludovic Brenta
  2011-03-10 21:42     ` Noel Duffy
  2011-03-10 21:36   ` Noel Duffy
  1 sibling, 2 replies; 12+ messages in thread
From: Mart van de Wege @ 2011-03-10 21:32 UTC (permalink / raw)


Julian Leyh <julian@vgai.de> writes:

> On 10 Mrz., 07:01, Noel Duffy <hobcraft-use...@yahooxtra.co.nz> wrote:
>> I wonder whether what I am seeing is a result of a difference in gcc-gnat
>> version, a difference in distribution packaging, or possibly a
>> combination of both. Is there anyone using Fedora here who could possibly
>> shed any light on this?
>
> What do "file" and "ldd" tell you about them? Are the sizes more
> similar if you "strip" them?

I'd be inclined to think stripping may be the culprit. Debian is well
known to use stripped binaries by default, so I wouldn't be surprised if
the various toolchains are set up that way as well.

IIRC, this is what led them to stop being the default GNU distro, as the
GNU folks like their binaries with debug info by default. And since
Fedora is mostly a Red Hat project, and Red Hat has absorbed a *lot* of
the GCC devs via Cygnus, I'd expect Fedora to *not* strip by default.

Ludovic could probably answer that one in his sleep.

Mart

-- 
"We will need a longer wall when the revolution comes."
    --- AJS, quoting an uncertain source.



^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Differences between gnat 4.4.5 and 4.5.1
  2011-03-10 13:48 ` Julian Leyh
  2011-03-10 21:32   ` Mart van de Wege
@ 2011-03-10 21:36   ` Noel Duffy
  1 sibling, 0 replies; 12+ messages in thread
From: Noel Duffy @ 2011-03-10 21:36 UTC (permalink / raw)


On Thu, 10 Mar 2011 05:48:25 -0800, Julian Leyh wrote:
> What do "file" and "ldd" tell you about them? Are the sizes more similar
> if you "strip" them?

As I said, I compile with this command:

$ gnatmake -f -Os hello.adb -largs -s

which strips the executables, so the size disparity is for final stripped 
executables. file shows this for Fedora:

$ file hello
hello: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically 
linked (uses shared libs), for GNU/Linux 2.6.32, stripped

On Debian:

$ file hello
hello: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically 
linked (uses shared libs), for GNU/Linux 2.6.18, stripped

ldd shows that both are dynamically linked against libgnat. I.e, on Fedora:

$ ldd hello
	linux-vdso.so.1 =>  (0x00007fff1b5a3000)
	libgnat-4.5.so => /usr/lib64/libgnat-4.5.so (0x00007f89c2909000)
	libc.so.6 => /lib64/libc.so.6 (0x000000343e600000)
	libm.so.6 => /lib64/libm.so.6 (0x000000343f200000)
	libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x000000343f600000)
	/lib64/ld-linux-x86-64.so.2 (0x000000343e200000)

On Debian:

$ ldd hello
	linux-vdso.so.1 =>  (0x00007fff52d9e000)
	libgnat-4.4.so.1 => /usr/lib/libgnat-4.4.so.1 (0x00007f47c6c2a000)
	libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00007f47c6a14000)
	libc.so.6 => /lib/libc.so.6 (0x00007f47c66b2000)
	libm.so.6 => /lib/libm.so.6 (0x00007f47c6430000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f47c7160000)



^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Differences between gnat 4.4.5 and 4.5.1
  2011-03-10 21:32   ` Mart van de Wege
@ 2011-03-10 21:39     ` Ludovic Brenta
  2011-03-11  9:16       ` Mart van de Wege
  2011-03-20 20:11       ` Ludovic Brenta
  2011-03-10 21:42     ` Noel Duffy
  1 sibling, 2 replies; 12+ messages in thread
From: Ludovic Brenta @ 2011-03-10 21:39 UTC (permalink / raw)


Mart van de Wege writes:
> Julian Leyh <julian@vgai.de> writes:
>
>> On 10 Mrz., 07:01, Noel Duffy <hobcraft-use...@yahooxtra.co.nz> wrote:
>>> I wonder whether what I am seeing is a result of a difference in gcc-gnat
>>> version, a difference in distribution packaging, or possibly a
>>> combination of both. Is there anyone using Fedora here who could possibly
>>> shed any light on this?
>>
>> What do "file" and "ldd" tell you about them? Are the sizes more
>> similar if you "strip" them?
>
> I'd be inclined to think stripping may be the culprit. Debian is well
> known to use stripped binaries by default, so I wouldn't be surprised
> if the various toolchains are set up that way as well.
>
> IIRC, this is what led them to stop being the default GNU distro, as
> the GNU folks like their binaries with debug info by default. And
> since Fedora is mostly a Red Hat project, and Red Hat has absorbed a
> *lot* of the GCC devs via Cygnus, I'd expect Fedora to *not* strip by
> default.
>
> Ludovic could probably answer that one in his sleep.

No, not in my sleep :)

Stripping means removing debugging symbols from an executable.  For the
debugging symbols to be present in the first place requires an explicit
-g option.

The "default" you speak of is that contained in most upstream Makefiles.
Debian *packaging scripts*, by default, passes -g to the compiler and
then strips the executables, moving the debugging symbols to a separate
-dbg package (this is in fact mandatory for the Ada libraries...).  But
packaging scripts have nothing to do with the OP's way of calling GCC.

Personally I'd be inclined to think the difference in size is due to the
compiler, not differences between distributions.  I'd have to check with
gnat-4.5 when it reaches a usable state.

-- 
Ludovic Brenta.



^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Differences between gnat 4.4.5 and 4.5.1
  2011-03-10 21:32   ` Mart van de Wege
  2011-03-10 21:39     ` Ludovic Brenta
@ 2011-03-10 21:42     ` Noel Duffy
  1 sibling, 0 replies; 12+ messages in thread
From: Noel Duffy @ 2011-03-10 21:42 UTC (permalink / raw)


On Thu, 10 Mar 2011 22:32:04 +0100, Mart van de Wege wrote:

> Julian Leyh <julian@vgai.de> writes:
 
>> What do "file" and "ldd" tell you about them? Are the sizes more
>> similar if you "strip" them?
> 
> I'd be inclined to think stripping may be the culprit. Debian is well
> known to use stripped binaries by default, so I wouldn't be surprised if
> the various toolchains are set up that way as well.

I took care to strip both executables before comparison. The disparity in 
size is after stripping, not before.

> IIRC, this is what led them to stop being the default GNU distro, as the
> GNU folks like their binaries with debug info by default. And since
> Fedora is mostly a Red Hat project, and Red Hat has absorbed a *lot* of
> the GCC devs via Cygnus, I'd expect Fedora to *not* strip by default.

On both Debian and Fedora gnatmake leaves debug information in by default. 
However, I am use -largs -s to strip the executables. 

Redhat like to ship debug information as separate .dbg files these days, 
so you get smaller executables without losing debug information. There is 
a special debug repository where you can download debug information for 
any rpm.



^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Differences between gnat 4.4.5 and 4.5.1
  2011-03-10 21:39     ` Ludovic Brenta
@ 2011-03-11  9:16       ` Mart van de Wege
  2011-03-20 20:11       ` Ludovic Brenta
  1 sibling, 0 replies; 12+ messages in thread
From: Mart van de Wege @ 2011-03-11  9:16 UTC (permalink / raw)


Ludovic Brenta <ludovic@ludovic-brenta.org> writes:

> Mart van de Wege writes:
>> Julian Leyh <julian@vgai.de> writes:
>>
>>> On 10 Mrz., 07:01, Noel Duffy <hobcraft-use...@yahooxtra.co.nz> wrote:
>>>> I wonder whether what I am seeing is a result of a difference in gcc-gnat
>>>> version, a difference in distribution packaging, or possibly a
>>>> combination of both. Is there anyone using Fedora here who could possibly
>>>> shed any light on this?
>>>
>>> What do "file" and "ldd" tell you about them? Are the sizes more
>>> similar if you "strip" them?
>>
>> I'd be inclined to think stripping may be the culprit. Debian is well
>> known to use stripped binaries by default, so I wouldn't be surprised
>> if the various toolchains are set up that way as well.
>>
>> IIRC, this is what led them to stop being the default GNU distro, as
>> the GNU folks like their binaries with debug info by default. And
>> since Fedora is mostly a Red Hat project, and Red Hat has absorbed a
>> *lot* of the GCC devs via Cygnus, I'd expect Fedora to *not* strip by
>> default.
>>
>> Ludovic could probably answer that one in his sleep.
>
> No, not in my sleep :)
>
> Stripping means removing debugging symbols from an executable.  For the
> debugging symbols to be present in the first place requires an explicit
> -g option.
>
> The "default" you speak of is that contained in most upstream Makefiles.
> Debian *packaging scripts*, by default, passes -g to the compiler and
> then strips the executables, moving the debugging symbols to a separate
> -dbg package (this is in fact mandatory for the Ada libraries...).  But
> packaging scripts have nothing to do with the OP's way of calling GCC.
>
Thanks. That is clear. I was working from vague recollection about the
Debian/GNU split.

For work and hobby, I just use the tools provided, not worrying overmuch
about such details. And I have a distribution maintainer who does a lot
of work to keep me from worrying.

For which I say: Thanks Ludo.

Mart

-- 
"We will need a longer wall when the revolution comes."
    --- AJS, quoting an uncertain source.



^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Differences between gnat 4.4.5 and 4.5.1
  2011-03-10 21:39     ` Ludovic Brenta
  2011-03-11  9:16       ` Mart van de Wege
@ 2011-03-20 20:11       ` Ludovic Brenta
  2011-03-21  7:05         ` Noel Duffy
  1 sibling, 1 reply; 12+ messages in thread
From: Ludovic Brenta @ 2011-03-20 20:11 UTC (permalink / raw)


I wrote on 2011-03-10 on comp.lang.ada:
> Personally I'd be inclined to think the difference in size is due to
> the compiler, not differences between distributions.  I'd have to
> check with gnat-4.5 when it reaches a usable state.

OK, I've got gnat-4.5 installed on my machine now (with all Debian
patches ported).  Here are my results:

gnat-4.4:


$ ls -lrt hello*
  -rwxr-xr-x  1 lbrenta lbrenta 13728 2011-03-17T20:35:58 hello
  -rw-r--r--  1 lbrenta lbrenta  2944 2011-03-17T20:35:57 hello.o
  -rw-r--r--  1 lbrenta lbrenta  2240 2011-03-17T20:35:57 hello.ali

$ objdump --headers hello
hello:     file format elf64-x86-64

Sections:
Idx Name          Size      VMA               LMA               File off  Algn
  0 .interp       0000001c  0000000000400200  0000000000400200  00000200  2**0
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  1 .note.ABI-tag 00000020  000000000040021c  000000000040021c  0000021c  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  2 .note.gnu.build-id 00000024  000000000040023c  000000000040023c  0000023c  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  3 .hash         00000264  0000000000400260  0000000000400260  00000260  2**3
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  4 .gnu.hash     00000180  00000000004004c8  00000000004004c8  000004c8  2**3
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  5 .dynsym       000007e0  0000000000400648  0000000000400648  00000648  2**3
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  6 .dynstr       0000085b  0000000000400e28  0000000000400e28  00000e28  2**0
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  7 .gnu.version  000000a8  0000000000401684  0000000000401684  00001684  2**1
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  8 .gnu.version_r 00000040  0000000000401730  0000000000401730  00001730  2**3
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  9 .rela.dyn     000003f0  0000000000401770  0000000000401770  00001770  2**3
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
 10 .rela.plt     00000348  0000000000401b60  0000000000401b60  00001b60  2**3
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
 11 .init         00000018  0000000000401ea8  0000000000401ea8  00001ea8  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
 12 .plt          00000240  0000000000401ec0  0000000000401ec0  00001ec0  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
 13 .text         000004c8  0000000000402100  0000000000402100  00002100  2**4
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
 14 .fini         0000000e  00000000004025c8  00000000004025c8  000025c8  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
 15 .rodata       00000080  00000000004025e0  00000000004025e0  000025e0  2**4
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
 16 .eh_frame_hdr 00000044  0000000000402660  0000000000402660  00002660  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
 17 .eh_frame     0000011c  00000000004026a8  00000000004026a8  000026a8  2**3
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
 18 .gcc_except_table 00000018  00000000004027c4  00000000004027c4  000027c4  2**0
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
 19 .ctors        00000010  00000000006027e0  00000000006027e0  000027e0  2**3
                  CONTENTS, ALLOC, LOAD, DATA
 20 .dtors        00000010  00000000006027f0  00000000006027f0  000027f0  2**3
                  CONTENTS, ALLOC, LOAD, DATA
 21 .jcr          00000008  0000000000602800  0000000000602800  00002800  2**3
                  CONTENTS, ALLOC, LOAD, DATA
 22 .dynamic      000001c0  0000000000602808  0000000000602808  00002808  2**3
                  CONTENTS, ALLOC, LOAD, DATA
 23 .got          00000008  00000000006029c8  00000000006029c8  000029c8  2**3
                  CONTENTS, ALLOC, LOAD, DATA
 24 .got.plt      00000130  00000000006029d0  00000000006029d0  000029d0  2**3
                  CONTENTS, ALLOC, LOAD, DATA
 25 .data         000001c8  0000000000602b00  0000000000602b00  00002b00  2**4
                  CONTENTS, ALLOC, LOAD, DATA
 26 .bss          00000268  0000000000602ce0  0000000000602ce0  00002cc8  2**5
                  ALLOC
 27 .comment      00000056  0000000000000000  0000000000000000  00002cc8  2**0
                  CONTENTS, READONLY


gnat-4.5:

$ ls -lrt hello*
  -rwxr-xr-x  1 lbrenta lbrenta 15376 2011-03-20T20:56:55 hello
  -rw-r--r--  1 lbrenta lbrenta  2936 2011-03-20T20:56:54 hello.o
  -rw-r--r--  1 lbrenta lbrenta  2240 2011-03-20T20:56:54 hello.ali

$ objdump --headers hello
hello:     file format elf64-x86-64

Sections:
Idx Name          Size      VMA               LMA               File off  Algn
  0 .interp       0000001c  0000000000400200  0000000000400200  00000200  2**0
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  1 .note.ABI-tag 00000020  000000000040021c  000000000040021c  0000021c  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  2 .note.gnu.build-id 00000024  000000000040023c  000000000040023c  0000023c  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  3 .hash         0000026c  0000000000400260  0000000000400260  00000260  2**3
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  4 .gnu.hash     000001a4  00000000004004d0  00000000004004d0  000004d0  2**3
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  5 .dynsym       00000810  0000000000400678  0000000000400678  00000678  2**3
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  6 .dynstr       00000893  0000000000400e88  0000000000400e88  00000e88  2**0
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  7 .gnu.version  000000ac  000000000040171c  000000000040171c  0000171c  2**1
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  8 .gnu.version_r 00000040  00000000004017c8  00000000004017c8  000017c8  2**3
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  9 .rela.dyn     00000408  0000000000401808  0000000000401808  00001808  2**3
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
 10 .rela.plt     00000360  0000000000401c10  0000000000401c10  00001c10  2**3
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
 11 .init         00000018  0000000000401f70  0000000000401f70  00001f70  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
 12 .plt          00000250  0000000000401f88  0000000000401f88  00001f88  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
 13 .text         00000548  00000000004021e0  00000000004021e0  000021e0  2**4
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
 14 .fini         0000000e  0000000000402728  0000000000402728  00002728  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
 15 .rodata       000001e0  0000000000402740  0000000000402740  00002740  2**4
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
 16 .eh_frame_hdr 00000044  0000000000402920  0000000000402920  00002920  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
 17 .eh_frame     0000010c  0000000000402968  0000000000402968  00002968  2**3
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
 18 .gcc_except_table 00000024  0000000000402a74  0000000000402a74  00002a74  2**0
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
 19 .ctors        00000010  0000000000603000  0000000000603000  00003000  2**3
                  CONTENTS, ALLOC, LOAD, DATA
 20 .dtors        00000010  0000000000603010  0000000000603010  00003010  2**3
                  CONTENTS, ALLOC, LOAD, DATA
 21 .jcr          00000008  0000000000603020  0000000000603020  00003020  2**3
                  CONTENTS, ALLOC, LOAD, DATA
 22 .dynamic      000001c0  0000000000603028  0000000000603028  00003028  2**3
                  CONTENTS, ALLOC, LOAD, DATA
 23 .got          00000008  00000000006031e8  00000000006031e8  000031e8  2**3
                  CONTENTS, ALLOC, LOAD, DATA
 24 .got.plt      00000138  00000000006031f0  00000000006031f0  000031f0  2**3
                  CONTENTS, ALLOC, LOAD, DATA
 25 .data         00000014  0000000000603328  0000000000603328  00003328  2**3
                  CONTENTS, ALLOC, LOAD, DATA
 26 .bss          00000298  0000000000603340  0000000000603340  0000333c  2**5
                  ALLOC
 27 .comment      00000054  0000000000000000  0000000000000000  0000333c  2**0
                  CONTENTS, READONLY




Comparing the sizes of the sections shows a small increase in most
sections and a move of most data from .data to .rodata.  The .text
section, for example, has increased by 10%.

-- 
Ludovic Brenta.



^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Differences between gnat 4.4.5 and 4.5.1
  2011-03-20 20:11       ` Ludovic Brenta
@ 2011-03-21  7:05         ` Noel Duffy
  2011-03-21  7:52           ` Ludovic Brenta
  0 siblings, 1 reply; 12+ messages in thread
From: Noel Duffy @ 2011-03-21  7:05 UTC (permalink / raw)


On Sun, 20 Mar 2011 21:11:04 +0100, Ludovic Brenta wrote:

>> Personally I'd be inclined to think the difference in size is due to
>> the compiler, not differences between distributions.  I'd have to check
>> with gnat-4.5 when it reaches a usable state.
> 
> OK, I've got gnat-4.5 installed on my machine now (with all Debian
> patches ported).  Here are my results:
> 
[snipped for brevity]
> 
> Comparing the sizes of the sections shows a small increase in most
> sections and a move of most data from .data to .rodata.  The .text
> section, for example, has increased by 10%.

Thanks for taking the time to look into this. For comparison, here is the
objdump output I see for Fedora/gnat-4.5.1:


hello:     file format elf64-x86-64

Sections:
Idx Name          Size      VMA               LMA               File off  
Algn
  0 .interp       0000001c  0000000000400200  0000000000400200  00000200  
2**0
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  1 .note.ABI-tag 00000020  000000000040021c  000000000040021c  0000021c  
2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  2 .note.gnu.build-id 00000024  000000000040023c  000000000040023c  
0000023c  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  3 .gnu.hash     000001a4  0000000000400260  0000000000400260  00000260  
2**3
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  4 .dynsym       00000900  0000000000400408  0000000000400408  00000408  
2**3
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  5 .dynstr       000008fb  0000000000400d08  0000000000400d08  00000d08  
2**0
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  6 .gnu.version  000000c0  0000000000401604  0000000000401604  00001604  
2**1
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  7 .gnu.version_r 00000030  00000000004016c8  00000000004016c8  000016c8  
2**3
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  8 .rela.dyn     00000420  00000000004016f8  00000000004016f8  000016f8  
2**3
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  9 .rela.plt     00000438  0000000000401b18  0000000000401b18  00001b18  
2**3
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
 10 .init         00000018  0000000000401f50  0000000000401f50  00001f50  
2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
 11 .plt          000002e0  0000000000401f68  0000000000401f68  00001f68  
2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
 12 .text         00004b08  0000000000402250  0000000000402250  00002250  
2**4
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
 13 .fini         0000000e  0000000000406d58  0000000000406d58  00006d58  
2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
 14 .rodata       00000740  0000000000406d70  0000000000406d70  00006d70  
2**4
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
 15 .eh_frame_hdr 00000204  00000000004074b0  00000000004074b0  000074b0  
2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
 16 .eh_frame     00000b4c  00000000004076b8  00000000004076b8  000076b8  
2**3
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
 17 .gcc_except_table 00000024  0000000000408204  0000000000408204  
00008204  2**0
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
 18 .ctors        00000010  0000000000608228  0000000000608228  00008228  
2**3
                  CONTENTS, ALLOC, LOAD, DATA
 19 .dtors        00000010  0000000000608238  0000000000608238  00008238  
2**3
                  CONTENTS, ALLOC, LOAD, DATA
 20 .jcr          00000008  0000000000608248  0000000000608248  00008248  
2**3
                  CONTENTS, ALLOC, LOAD, DATA
 21 .dynamic      000001a0  0000000000608250  0000000000608250  00008250  
2**3
                  CONTENTS, ALLOC, LOAD, DATA
 22 .got          00000010  00000000006083f0  00000000006083f0  000083f0  
2**3
                  CONTENTS, ALLOC, LOAD, DATA
 23 .got.plt      00000180  0000000000608400  0000000000608400  00008400  
2**3
                  CONTENTS, ALLOC, LOAD, DATA
 24 .data         00000010  0000000000608580  0000000000608580  00008580  
2**3
                  CONTENTS, ALLOC, LOAD, DATA
 25 .bss          000004a8  00000000006085a0  00000000006085a0  00008590  
2**5
                  ALLOC
 26 .comment      0000002c  0000000000000000  0000000000000000  00008590  
2**0
                  CONTENTS, READONLY

The .text section is noticeably larger in this executable, 0x4B08
(19208), than in the executable generated on Debian, 0x4c8. Since
.text is code, I ran objdump -S on the text sections in both
executables after recompiling but not stripping debug symbols. The
Fedora/gnat-4.5.1 executable has many more functions. Here is a list
of them.

$ objdump -S -j .text hello | egrep "^0[a-f0-9]+"
0000000000402250 <_start>:
000000000040227c <call_gmon_start>:
00000000004022a0 <__do_global_dtors_aux>:
0000000000402310 <frame_dummy>:
0000000000402334 <adainit>:
000000000040259d <adafinal>:
00000000004025a2 <main>:
00000000004025f4 <hello___clean.2354>:
000000000040261d <_ada_hello>:
00000000004026c0 <read_sleb128>:
0000000000402710 <read_encoded_value_with_base>:
0000000000402870 <init_dwarf_reg_size_table>:
00000000004028f0 <execute_cfa_program>:
00000000004031b0 <uw_frame_state_for>:
0000000000403860 <execute_stack_op>:
0000000000403f40 <uw_update_context_1>:
0000000000404300 <uw_update_context>:
00000000004043b0 <_Unwind_ForcedUnwind_Phase2>:
0000000000404480 <_Unwind_RaiseException_Phase2>:
0000000000404520 <uw_init_context_1>:
00000000004046d0 <uw_install_context_1>:
0000000000404840 <_Unwind_GetGR>:
0000000000404890 <_Unwind_GetCFA>:
00000000004048a0 <_Unwind_SetGR>:
00000000004048f0 <_Unwind_GetIP>:
0000000000404900 <_Unwind_GetIPInfo>:
0000000000404920 <_Unwind_SetIP>:
0000000000404930 <_Unwind_GetLanguageSpecificData>:
0000000000404940 <_Unwind_GetRegionStart>:
0000000000404950 <_Unwind_FindEnclosingFunction>:
0000000000404980 <_Unwind_GetDataRelBase>:
0000000000404990 <_Unwind_GetTextRelBase>:
00000000004049a0 <__frame_state_for>:
0000000000404ad0 <_Unwind_DebugHook>:
0000000000404ae0 <_Unwind_RaiseException>:
0000000000404c60 <_Unwind_ForcedUnwind>:
0000000000404d70 <_Unwind_Resume>:
0000000000404e60 <_Unwind_Resume_or_Rethrow>:
0000000000404f80 <_Unwind_DeleteException>:
0000000000404fa0 <_Unwind_Backtrace>:
0000000000405060 <fde_unencoded_compare>:
0000000000405080 <frame_downheap>:
0000000000405140 <frame_heapsort>:
0000000000405210 <size_of_encoded_value>:
0000000000405280 <read_encoded_value_with_base>:
00000000004053c0 <get_cie_encoding>:
0000000000405500 <base_from_object.clone.3>:
0000000000405570 <classify_object_over_fdes>:
00000000004056f0 <fde_single_encoding_compare>:
00000000004057a0 <linear_search_fdes>:
0000000000405930 <add_fdes.clone.4>:
0000000000405a80 <base_from_cb_data.clone.5>:
0000000000405af0 <search_object>:
00000000004061e0 <fde_mixed_encoding_compare>:
00000000004062b0 <_Unwind_IteratePhdrCallback>:
0000000000406770 <__register_frame_info_bases>:
0000000000406810 <__register_frame_info>:
0000000000406820 <__register_frame>:
0000000000406850 <__register_frame_info_table_bases>:
00000000004068d0 <__register_frame_info_table>:
00000000004068e0 <__register_frame_table>:
0000000000406900 <__deregister_frame_info_bases>:
0000000000406a40 <__deregister_frame_info>:
0000000000406a50 <__deregister_frame>:
0000000000406a80 <_Unwind_Find_FDE>:
0000000000406c80 <__libc_csu_init>:
0000000000406d10 <__libc_csu_fini>:
0000000000406d20 <__do_global_ctors_aux>:

There are 68 of them. The Debian/gnat-4.4.5 version contains just:

0000000000402100 <_start>:
000000000040212c <call_gmon_start>:
0000000000402150 <__do_global_dtors_aux>:
00000000004021c0 <frame_dummy>:
00000000004021e4 <adafinal>:
00000000004021e9 <adainit>:
00000000004023da <main>:
000000000040242c <hello___clean.2605>:
0000000000402455 <_ada_hello>:
00000000004024f0 <__libc_csu_fini>:
0000000000402500 <__libc_csu_init>:
0000000000402590 <__do_global_ctors_aux>:

A lot of the extra functions appear to be related to debugging and
generating backtraces. Not sure why they're still present when debugging
information is stripped. I suppose it's possible that Redhat want these
functions left in binaries for some reason, but that's just a guess. 

Time perhaps to take this to Fedora's mailing lists to see if they can
shed any light on it.



^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Differences between gnat 4.4.5 and 4.5.1
  2011-03-21  7:05         ` Noel Duffy
@ 2011-03-21  7:52           ` Ludovic Brenta
  0 siblings, 0 replies; 12+ messages in thread
From: Ludovic Brenta @ 2011-03-21  7:52 UTC (permalink / raw)


Noel Duffy writes:
> I ran objdump -S on the text sections in both executables after
> recompiling but not stripping debug symbols. The Fedora/gnat-4.5.1
> executable has many more functions. Here is a list of them. [...]
> 
> There are 68 of them. The Debian/gnat-4.4.5 version contains just:
>
> 0000000000402100 <_start>:
> 000000000040212c <call_gmon_start>:
> 0000000000402150 <__do_global_dtors_aux>:
> 00000000004021c0 <frame_dummy>:
> 00000000004021e4 <adafinal>:
> 00000000004021e9 <adainit>:
> 00000000004023da <main>:
> 000000000040242c <hello___clean.2605>:
> 0000000000402455 <_ada_hello>:
> 00000000004024f0 <__libc_csu_fini>:
> 0000000000402500 <__libc_csu_init>:
> 0000000000402590 <__do_global_ctors_aux>:

Here is what I have on my executable compiled with gnat-4.5:

00000000004021e0 <_start>:
000000000040220c <call_gmon_start>:
0000000000402230 <__do_global_dtors_aux>:
00000000004022a0 <frame_dummy>:
00000000004022c4 <adainit>:
000000000040252d <adafinal>:
0000000000402532 <main>:
0000000000402584 <hello___clean.2354>:
00000000004025ad <_ada_hello>:
0000000000402650 <__libc_csu_fini>:
0000000000402660 <__libc_csu_init>:
00000000004026f0 <__do_global_ctors_aux>:

> Time perhaps to take this to Fedora's mailing lists to see if they can
> shed any light on it.

Or maybe try with stock GCC 4.5?

-- 
Ludovic Brenta.



^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Differences between gnat 4.4.5 and 4.5.1
  2011-03-10  6:01 Differences between gnat 4.4.5 and 4.5.1 Noel Duffy
  2011-03-10 13:48 ` Julian Leyh
@ 2011-03-21  8:35 ` Dmitry A. Kazakov
  2011-03-21 10:16   ` Simon Wright
  1 sibling, 1 reply; 12+ messages in thread
From: Dmitry A. Kazakov @ 2011-03-21  8:35 UTC (permalink / raw)


On Thu, 10 Mar 2011 06:01:53 +0000 (UTC), Noel Duffy wrote:

> I wonder whether what I am seeing is a result of a difference in gcc-gnat 
> version, a difference in distribution packaging, or possibly a 
> combination of both. Is there anyone using Fedora here who could possibly 
> shed any light on this?

I installed Fedora 14 recently and tested it a bit. Unfortunately it is
unusable to me. I didn't really tested it for the compiler bugs (there were
plenty before), because the first stumble block I could not overcome was an
outdated gnatmake It does not support relocatable library projects to
depend on static ones. Binutils have some libraries only static, and I
needed them. The older gnatmake just ignored the issue. The newer one does
not, but the switch to shut it up (--unchecked-shared-lib-imports) is not
there. gprbuild is not there either. So I put it in ice until another
version.

It seems that GNAT GPL 2010 is still the only choice for Fedora 14.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de



^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Differences between gnat 4.4.5 and 4.5.1
  2011-03-21  8:35 ` Dmitry A. Kazakov
@ 2011-03-21 10:16   ` Simon Wright
  0 siblings, 0 replies; 12+ messages in thread
From: Simon Wright @ 2011-03-21 10:16 UTC (permalink / raw)


"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> I installed Fedora 14 recently and tested it a bit. Unfortunately it is
> unusable to me. I didn't really tested it for the compiler bugs (there were
> plenty before), because the first stumble block I could not overcome was an
> outdated gnatmake It does not support relocatable library projects to
> depend on static ones. Binutils have some libraries only static, and I
> needed them. The older gnatmake just ignored the issue. The newer one does
> not, but the switch to shut it up (--unchecked-shared-lib-imports) is not
> there. gprbuild is not there either. So I put it in ice until another
> version.

On Mac OS X I fell over this (trying to build a relocatable GNATcoll/GMP
against a static GMP). It wasn't GCC that complained, though, it was ld
- trying to create a pic binary from a non-pic library. I forget the
exact error message. But, on this platform,
--unchecked-shared-lib-imports would probably be no use anyway.

> It seems that GNAT GPL 2010 is still the only choice for Fedora 14.

One thing you can do with it is build a stable FSF GCC.



^ permalink raw reply	[flat|nested] 12+ messages in thread

end of thread, other threads:[~2011-03-21 10:16 UTC | newest]

Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-03-10  6:01 Differences between gnat 4.4.5 and 4.5.1 Noel Duffy
2011-03-10 13:48 ` Julian Leyh
2011-03-10 21:32   ` Mart van de Wege
2011-03-10 21:39     ` Ludovic Brenta
2011-03-11  9:16       ` Mart van de Wege
2011-03-20 20:11       ` Ludovic Brenta
2011-03-21  7:05         ` Noel Duffy
2011-03-21  7:52           ` Ludovic Brenta
2011-03-10 21:42     ` Noel Duffy
2011-03-10 21:36   ` Noel Duffy
2011-03-21  8:35 ` Dmitry A. Kazakov
2011-03-21 10:16   ` Simon Wright

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox