Size of executable files gets too large with SDK v53.20

Have a question about our Software Developer Kit? Ask them here.
User avatar
jostein_aarbakk
Beta Tester
Beta Tester
Posts: 37
Joined: Thu Aug 04, 2011 11:08 pm
Location: Norway

Re: Size of executable files gets too large with SDK v53.20

Post by jostein_aarbakk »

@all:
Thanks for your quick response.
By using the -N option kas1e suggested, the issue disappeared (gcc -N HelloWorld.c -o HelloWorld).
This created an executable of only 5977 Bytes.
A good workaround.

I wish you all a merry X-Mas.

Trev
Posts: 5
Joined: Sat Jun 18, 2011 5:48 pm

Re: Size of executable files gets too large with SDK v53.20

Post by Trev »

Is this patch in adtools? My cross-compiler doesn't align sections on 64K boundaries. Was it implemented in a host-specific way? I haven't looked at adtools source in over a year....

User avatar
tonyw
AmigaOS Core Developer
AmigaOS Core Developer
Posts: 1433
Joined: Wed Mar 09, 2011 1:36 pm
Location: Sydney, Australia

Re: Size of executable files gets too large with SDK v53.20

Post by tonyw »

Where is that "-N" supposed to go? I tried it in the compile options "-O2 -N ..." and in the link options "-N -L. ..." and neither made any difference here for one system component.
cheers
tony

kas1e
Beta Tester
Beta Tester
Posts: 483
Joined: Sat Jun 18, 2011 7:56 am
Contact:

Re: Size of executable files gets too large with SDK v53.20

Post by kas1e »

@Trev
Is this patch in adtools? My cross-compiler doesn't align sections on 64K boundaries. Was it implemented in a host-specific way? I haven't looked at adtools source in over a year....
Not sure if is "a patch", its just seems that alignment-based-linker-scripts now used by default (as well as on my cross-compiler setup too, btw). Maybe for previous versions by default SDKs use non-alignment linker scripts ..

@TonyW
Where is that "-N" supposed to go? I tried it in the compile options "-O2 -N ..." and in the link options "-N -L. ..." and neither made any difference here for one system component.
"gcc -N 1.c -o 1" quoted few times in topic :) You can start from simple hello-world binary, check the differences in size with -N and without , and then step by step try to add it to bigger componets.

-N itself passed to linker (LD), and handles via ldscripts in /sdk/gcc/ppc-amigaos/lib/ldscripts/, but when you run it via gcc you don't need to worry. By logic you can mimik it like this when you pass -N to gcc:

shell:> cc1 1.c -o 1.s
shell:> as 1.s -o 1.o
shell:> ld -q -N 1.o -o 1

But of course when you just use gcc, you just pass -N , linker scripts do the work, and your binary builds as non-alignment 64k segments. If it make no differences for you, that mean that or you use beta-version of SDK where is by default non-alignment-ldscripts are used, or you just pass -N to objects (but should pass to final linking line), or you just do something wrong. The best ways its just check on hello_world example, if you have differences in size with and without -N, then all works for you, just you do something wrong for your programms. And if no differences, then your SDK by some reassons worry about already.

You always can do that: gcc -v 1.c , and you will see all the stuff which happens in background. The latest strings will be final-linking strings, and if you have -N here, then its all automatic for you already, if not , then check via hello_world example, etc

You also can check sdk/gcc/ppc-amigaos/lib/ldscripts directory. Files which ends on "n" (like amigaos.xn and elf32ppc.xbn) are linker scripts which handle that -N. And in those scripts you can find how binary builds on that matter. In coments it says "script for -N: mix text and data on same page; don't align data". And in the whole scripts many comments which explain how -N will reacts at low level (i.e. when construct elf)

@all
Anyway, just to add, i do not know if we use on amigaos4 PPC SVR4 ABI or PPC EABI ? Because by specifications:

PPC SVR4 ABI, pg. 5-1: The PPC SVR4 ABI specifies that segments are aligned on 64K (0x10000) boundaries.
PPC EABI, pg. 19: The PPC EABI says that there are no program loading requirements.

As we have alignment right now by default, i assume we going via PPC SVR4 ABI ? And if so, then have 64k alignment for segments by default are "right".

Trev
Posts: 5
Joined: Sat Jun 18, 2011 5:48 pm

Re: Size of executable files gets too large with SDK v53.20

Post by Trev »

I'll have to track down where my ld scripts originated.

User avatar
ssolie
Beta Tester
Beta Tester
Posts: 1010
Joined: Mon Dec 20, 2010 8:51 pm
Location: Canada
Contact:

Re: Size of executable files gets too large with SDK v53.20

Post by ssolie »

salass00 wrote:
ssolie wrote:
salass00 wrote:It has nothing to do with the Sam440EP or AmigaOS for that matter.
Thomas added it thinking it fixed an alignment issue on the 440ep. If this is not the case I suppose somebody should let him know...
Thomas did add extra alignment for the Sam440 but this is not what is causing the large noticeable difference in executable size.
I had a chat with Thomas via email and he is not intending to revisit this issue.

What Thomas suggested is that any changes be made directly to the adtools project. I do have plans to release an updated SDK so it would be nice to have any fixes in adtools before that. We at least have to release a new SDK with updated MUI includes, etc.

In other words, stop talking about it and apply any fix in adtools. :mrgreen:
ExecSG Team Lead

kas1e
Beta Tester
Beta Tester
Posts: 483
Joined: Sat Jun 18, 2011 7:56 am
Contact:

Re: Size of executable files gets too large with SDK v53.20

Post by kas1e »

@ssolie
I do have plans to release an updated SDK so it would be nice to have any fixes in adtools before that. We at least have to release a new SDK with updated MUI includes, etc.
Did it mean that its only you works on SDK ? I mean you say "i do have plans to release an updated SDK", like its only you working on it ? Or by "i" you mean whole hyperion ? Why i ask, its because as i know Thomas and his brother works on SDK too , as well as Rigo do something interesting for.
In other words, stop talking about it and apply any fix in adtools.
Have you any timeline when new SDK will be released ? (to know how much time we have left for change adtools to use non-alignment ldscripts by default)

kas1e
Beta Tester
Beta Tester
Posts: 483
Joined: Sat Jun 18, 2011 7:56 am
Contact:

Re: Size of executable files gets too large with SDK v53.20

Post by kas1e »

@all

Just to inform you all: i talk with Sebastian Bauer , and he say that he fix alignment issues some time ago in adtools repo. Of course, the best way is if someone will build latest adtools, and trying to produce a "hello world" binary via "gcc test.c -o test", if it will by default catch the non-alignment ldscripts , or not. If yes, then its indeed fixed, if not, then still need to.

User avatar
ChrisH
Beta Tester
Beta Tester
Posts: 917
Joined: Mon Dec 20, 2010 9:09 pm
Contact:

Re: Size of executable files gets too large with SDK v53.20

Post by ChrisH »

kas1e wrote:Did it mean that its only you works on SDK ? I mean you say "i do have plans to release an updated SDK", like its only you working on it ? Or by "i" you mean whole hyperion ?
I interpreted it as NEITHER of those meanings. Since he is responsible for *organising* (and arranging) the release of various OS4 stuff (like Update 4), i.e. being the OS4 project manager, I interpreted it as meaning he was planning on organising/arranging for a new SDK release. (i.e. Nothing to do with any work that he may do on SDK.)

User avatar
tonyw
AmigaOS Core Developer
AmigaOS Core Developer
Posts: 1433
Joined: Wed Mar 09, 2011 1:36 pm
Location: Sydney, Australia

Re: Size of executable files gets too large with SDK v53.20

Post by tonyw »

@kas1e:
shell:> cc1 1.c -o 1.s
shell:> as 1.s -o 1.o
shell:> ld -q -N 1.o -o 1
I don't use commands like that, I use makefiles with separate option strings for the compile and link commands.

I have tried the -N option in both option strings and it had no effect. That may be because the placement within the options string is important, hence my question.
cheers
tony

Post Reply