EmbDev.net

Forum: ARM programming with GCC/GNU tools --gc-sections


Author: Madis (Guest)
Posted on:

Rate this post
0 useful
not useful
Hi,

I noticed a thread about creating smallest binaries here:

http://en.mikrocontroller.net/topic/74054

There is a suggestion to use -ffunction-sections and -fdata-sections for
C flags and --gc-sections for LD. But I have a same problem as noted in
that thread, ld issues internal error:

arm-elf-gcc boot.o Cstartup_STR73x.o main.o ./meas/MKM.o   -lc -lm -l73x
-L../lib/ -mcpu=arm7tdmi -mthumb-interwork -nostartfiles
-T../script/STR73x_RAM.ld
-Wl,-Map=MKM.map,--no-warn-mismatch,--gc-sections -o MKM.elf
c:\program
files\yagarto\bin\..\lib\gcc\arm-elf\4.1.1\..\..\..\..\arm-elf\bin\ld.ex 
e:
internal error ../../binutils-2.17/ld/ldlang.c 4275
collect2: ld returned 1 exit status
make: *** [MKM.elf] Error 1
make: Target `all' not remade because of errors.

My linker flags are the following:
LDFLAGS = $(MCFLAGS) -mthumb-interwork -nostartfiles -T$(LDSCRIPT)
-Wl,-Map=$(PROJECT).map,--no-warn-mismatch,--gc-sections

and C flags:
CPFLAGS = $(MCFLAGS) -mthumb-interwork $(OPT) -ggdb -fomit-frame-pointer
-ffunction-sections -fdata-sections -Wall -Wextra -Wstrict-prototypes
-Wmissing-prototypes -Wmissing-declarations -Wno-strict-aliasing
-fverbose-asm -Wa,-ahlms=$(<:.c=.lst) $(DEFS)

---------------------------------------------
Unfortunatelly the thread I pointed does not give a solution for that
"internal error" problem. Could you please give me a suggestion, what to
try next to get things working.

Thank you in advance,
Madis

P.s. I have been using these options (--gc-sections, -fdata-sections,
-ffunction-sections) with GNUARM (and cygwin) successfully. The problem
really started after switching to yagarto. Could somebody verify it,
maybe the toolchain is a little broken somehow...

Author: Martin Thomas (Guest)
Posted on:

Rate this post
0 useful
not useful
Madis wrote:
> Hi,
>
> I noticed a thread about creating smallest binaries here:
>
> http://en.mikrocontroller.net/topic/74054
>
> There is a suggestion to use -ffunction-sections and -fdata-sections for
> C flags and --gc-sections for LD. But I have a same problem as noted in
> that thread, ld issues internal error:
>
> arm-elf-gcc boot.o Cstartup_STR73x.o main.o ./meas/MKM.o   -lc -lm -l73x
> -L../lib/ -mcpu=arm7tdmi -mthumb-interwork -nostartfiles
> -T../script/STR73x_RAM.ld
> -Wl,-Map=MKM.map,--no-warn-mismatch,--gc-sections -o MKM.elf
> c:\program
> files\yagarto\bin\..\lib\gcc\arm-elf\4.1.1\..\..\..\..\arm-elf\bin\ld.ex e:
> internal error ../../binutils-2.17/ld/ldlang.c 4275
> collect2: ld returned 1 exit status
> make: *** [MKM.elf] Error 1
> make: Target `all' not remade because of errors.
>
> My linker flags are the following:
> LDFLAGS = $(MCFLAGS) -mthumb-interwork -nostartfiles -T$(LDSCRIPT)
> -Wl,-Map=$(PROJECT).map,--no-warn-mismatch,--gc-sections
>
> and C flags:
> CPFLAGS = $(MCFLAGS) -mthumb-interwork $(OPT) -ggdb -fomit-frame-pointer
> -ffunction-sections -fdata-sections -Wall -Wextra -Wstrict-prototypes
> -Wmissing-prototypes -Wmissing-declarations -Wno-strict-aliasing
> -fverbose-asm -Wa,-ahlms=$(<:.c=.lst) $(DEFS)
>
> ---------------------------------------------
> Unfortunatelly the thread I pointed does not give a solution for that
> "internal error" problem. Could you please give me a suggestion, what to
> try next to get things working.
>
> Thank you in advance,
> Madis
>
> P.s. I have been using these options (--gc-sections, -fdata-sections,
> -ffunction-sections) with GNUARM (and cygwin) successfully. The problem
> really started after switching to yagarto. Could somebody verify it,
> maybe the toolchain is a little broken somehow...

Could you please try to compile the project
http://www.siwawi.arubi.uni-kl.de/avr_projects/arm...
with Yagarto. The project includes settings for the "unused code
removal". If this does not work either we have a good test-case since
this project builds with the tools in WinARM. If it works please create
a minimal example-application from your project-code (source incl.
startup, makefile, linkerscript) to reproduce the problem, pack it and
place it somewhere in a "Web-Space". Maybe the linker-script needs
additional entries or modifications.

Anyway, the linker should at least print a more informative
error-message instead of "internal error". It may be worth to report
this to the binutils-developers.

Martin Thomas

Author: Norbert Langermann (norbertl)
Posted on:

Rate this post
0 useful
not useful
Hi,

I have exactly the same problem as Madis. My project will not even fit
into the RAM without --gc-sections. A collegue started the project in a
Keil environment with a Cygnus arm-uclibc-gcc 3.3.1 (as delivered by
Keil). With this compiler, the code/data removal seems to work (at least
his binary fits into the processor).

Using Yagarto's arm-elf-gcc 4.2.1, I run into the same linker error as
Madis.

Martin Thomas wrote:
>
> Could you please try to compile the project
> 
http://www.siwawi.arubi.uni-kl.de/avr_projects/arm...

I tried this, and it compiles and links fine.
My first try was to copy the CC and linker options from gamma into my
project, but that did not solve the problem:

Compiling (e.g.):
arm-elf-gcc -c -I ./include -I ./IP/uip -I ./IP/include -mthumb
-mcpu=arm7tdmi -mthumb-interwork -gdwarf-2 -Os -ffunction-sections
-fdata-sections  -o USB/Usart/cdc_enumerate.o USB/Usart/cdc_enumerate.c

Assembling (e.g.):
arm-elf-as -gdwarf-2 -mthumb-interwork -mcpu=arm7tdmi -o
DDS/tskmger_ext.o DDS/tskmger_ext.s > DDS/tskmger_ext.o.lst

Linking...
arm-elf-gcc -mthumb -mcpu=arm7tdmi -mthumb-interwork -gdwarf-2 -Os
-ffunction-sections -fdata-sections -o opald_ppp.out -nostartfiles
-Wl,-Map=main.map,--cref,--gc-sections -lc  -lm -lc -lgcc
AktorSensor/actor_service.o
... a lot more objects ...
Startup/Cstartup.o
c:/programme/yagarto/bin/../lib/gcc/arm-elf/4.2.1/../../../../arm-elf/bi 
n/ld.exe:
internal error ../../binutils-2.17/ld/ldlang.c 4275
collect2: ld returned 1 exit status
make: *** [opald_ppp.out] Error 1

Some symbols are not resolved (but needed) since I am porting a bunch of
code to the the project. Without --gc-sections I get the appropriate
linker errors.

Perhaps somebody could point me the right direction to find a
solution...

Thanks

Norbert Langermann

Author: Martin Thomas (mthomas) (Moderator)
Posted on:

Rate this post
0 useful
not useful
Just using -ffunction-sections/-fdata-sections and --gc-sections is not
enough if your linker-script is not prepared for the "GCC4 ununsed code
removal". A lot of simple linker-scripts do not support this.

For example if there is just a *(.text) entry in the .text section
replace it by *(.text .text.* .gnu.linkonce.t.*). Use the same approach
for .data and .bss too. For additional information you may compare your
linker-script with the default linker-script (arm-elf-ld --verbose). In
the "ARM bare-metal"-articles from embedded.com there are also some
explanations. Most but not all of my newer example-applications support
unused code removal too so the included linker-scripts may also provide
some hints (i.e. AT91 "gamma").

Also verify that the program-entry is detected. If not the generated
elf-file is basicly empty. Add an ENTRY-instruction in the linker-script
or pass the entry from the command-line/makefile if this happens.

For further hints please show your linker-script. Also try to create a
minimal example-application (sources, linker-script, Makefile) to
reproduce the issue and send it as attachment to this forum or to an
e-mail to mthomas(at)rhrk(dot)uni-kl(dot)de .

Martin Thomas

Author: Chen He (chenhe)
Posted on:

Rate this post
0 useful
not useful
Hi Martin,

I saw some messages in this forum saying the automatic removal of unused
functions is only enabled after GCC v4.0. Is this true? We're using GCC
v3.3.2, and having problem to get "-ffunction-sections" and
"--gc-sections" to work, even after updating the linker file as you
described.

Thanks!
Chen


Martin Thomas wrote:
> Just using -ffunction-sections/-fdata-sections and --gc-sections is not
> enough if your linker-script is not prepared for the "GCC4 ununsed code
> removal". A lot of simple linker-scripts do not support this.
>
> For example if there is just a *(.text) entry in the .text section
> replace it by *(.text .text.* .gnu.linkonce.t.*). Use the same approach
> for .data and .bss too. For additional information you may compare your
> linker-script with the default linker-script (arm-elf-ld --verbose). In
> the "ARM bare-metal"-articles from embedded.com there are also some
> explanations. Most but not all of my newer example-applications support
> unused code removal too so the included linker-scripts may also provide
> some hints (i.e. AT91 "gamma").
>
> Also verify that the program-entry is detected. If not the generated
> elf-file is basicly empty. Add an ENTRY-instruction in the linker-script
> or pass the entry from the command-line/makefile if this happens.
>
> For further hints please show your linker-script. Also try to create a
> minimal example-application (sources, linker-script, Makefile) to
> reproduce the issue and send it as attachment to this forum or to an
> e-mail to mthomas(at)rhrk(dot)uni-kl(dot)de .
>
> Martin Thomas

Author: Martin Thomas (mthomas) (Moderator)
Posted on:

Rate this post
0 useful
not useful
Chen He wrote:

> I saw some messages in this forum saying the automatic removal of unused
> functions is only enabled after GCC v4.0. Is this true?

I know that the feature is available with gcc4 and rather up-to-date
binutils. I can not remember where I have read that it's a feature
introduced with gcc 4.0 so I don't know it it has been a reliable source
of information.

> We're using GCC
> v3.3.2, and having problem to get "-ffunction-sections" and
> "--gc-sections" to work, even after updating the linker file as you
> described.

I have never tried -f*-sections and -gc-sections with gcc <4.0 or
binutils <2.17. Why don't you just test with a never version of the GNU
tools?

Martin Thomas

Author: Aaron D'souza (adsouzp)
Posted on:
Attached files:
  • t2 (1.48 KB, 209 downloads)

Rate this post
0 useful
not useful
hello Madis:

Madis wrote:
> c:\program 
files\yagarto\bin\..\lib\gcc\arm-elf\4.1.1\..\..\..\..\arm-elf\bin\ld.ex e:
> internal error ../../binutils-2.17/ld/ldlang.c 4275
> collect2: ld returned 1 exit status
> [...]
> Unfortunatelly the thread I pointed does not give a solution for that
> "internal error" problem. Could you please give me a suggestion, what to
> try next to get things working.

pls see these links for more information:
- GCC Bugzilla Bug 6726
  http://sourceware.org/bugzilla/show_bug.cgi?id=6726

- GCC Bugzilla Bug 6727
  http://sourceware.org/bugzilla/show_bug.cgi?id=6727

- Mikrocontroller.net Forum
  http://en.mikrocontroller.net/topic/158791#699646

GLOBAL CONDITIONS
if:
- you enable --gc-sections
- you enable Thumb Interworking

PROBLEM 1
- if you do not define program entry point: you get the ldlang.c 4275
error

SOLUTION 1
- simply define entry point _start or whatever using --entry if required

PROBLEM
- you position another section using --section-start before .text using
-Ttext
: you get ZERO interworking code

SOLUTION
- position .data/other section AFTER .text. place -Ttext before
--section-start
  or -Tdata.

i hope that this is helpful to you.

Aaron

Author: Aaron D'souza (adsouzp)
Posted on:

Rate this post
0 useful
not useful
hello Madis:

On 29.01.2007 10:58 IST, Madis wrote:
> files\yagarto\bin\..\lib\gcc\arm-elf\4.1.1\..\..\..\..\arm-elf\bin\ld.ex e:
> internal error ../../binutils-2.17/ld/ldlang.c 4275
> collect2: ld returned 1 exit status
> make: *** [MKM.elf] Error 1
> make: Target `all' not remade because of errors.

pls see my previous post. Nick Clifton has reported that these two
bugs are known ones that have been fixed in the latest version of
binutils.

pls see the Sourceware BugZilla bug reports for updates.

also, GNUARM4.1.1 package does not have this fix. Pablo Bleyer
KoSick has been informed.

thank you,

Aaron
--
{
  why cause a commotion and start discussion / violation of privacy
  when everything is going on smoothly; i do not need your help since
  i can solve my problems better, with less harm to anyone, with less
  loss of privacy of anyone, and will get the problem solved. yet, the
  interference will not stop. there has to be something else...
  why turn the wheels, turn the wheels, turn the wheels....
}

Reply

Entering an e-mail address is optional. If you want to receive reply notifications by e-mail, please log in.

Rules — please read before posting

  • Post long source code as attachment, not in the text
  • Posting advertisements is forbidden.

Formatting options

  • [c]C code[/c]
  • [avrasm]AVR assembler code[/avrasm]
  • [code]code in other languages, ASCII drawings[/code]
  • [math]formula (LaTeX syntax)[/math]




Bild automatisch verkleinern, falls nötig
Note: the original post is older than 6 months. Please don't ask any new questions in this thread, but start a new one.