Bug 6726 - enabling LD garbage collection with Thumb interworking causes ASSERT in ldlang.c line 4275
Summary: enabling LD garbage collection with Thumb interworking causes ASSERT in ldlan...
Status: VERIFIED FIXED
Alias: None
Product: binutils
Classification: Unclassified
Component: ld (show other bugs)
Version: 2.17
: P2 normal
Target Milestone: ---
Assignee: unassigned
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-07-08 05:14 UTC by Aaron P. D'Souza
Modified: 2008-07-23 15:13 UTC (History)
1 user (show)

See Also:
Host: CYGWIN_NT-5.1 jenny 1.5.25(0.156/4/2) 2008-06-12 19:34 i686 Cygw
Target: ARM ELF
Build:
Last reconfirmed:


Attachments
contains the Makefile, Assembly file and C file to reproduce the problem (473 bytes, application/octet-stream)
2008-07-08 05:16 UTC, Aaron P. D'Souza
Details
contains the Makefile, Assembly file and C file to reproduce the problem (473 bytes, text/plain)
2008-07-08 05:21 UTC, Aaron P. D'Souza
Details
Makefile, 2 assembly files, C file to prevent the error (509 bytes, text/plain)
2008-07-08 06:52 UTC, Aaron P. D'Souza
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Aaron P. D'Souza 2008-07-08 05:14:44 UTC
using arm-elf-ld:

when:
- you have an asm file with .data & .text with Thumb interworking enabled
  and .data is not accessed anywhere and will be garbage-collected
- you have a C file compiled in Thumb mode with Thumb interworking enabled
- you enable --gc-sections

you get an assert from ldlang.c line 4275
Comment 1 Aaron P. D'Souza 2008-07-08 05:16:56 UTC
Created attachment 2817 [details]
contains the Makefile, Assembly file and C file to reproduce the problem

Makefile, ARM assembly, C code to reproduce the problem
Comment 2 Aaron P. D'Souza 2008-07-08 05:18:46 UTC
here are the output and error messages:

----------------------------------------------------------------------------

veneer2> make
arm-elf-as  -mno-fpu -march=armv4t -mcpu=arm7tdmi -mthumb-interwork -o 
FirstAsm.
o FirstAsm.s
arm-elf-as  -mno-fpu -march=armv4t -mcpu=arm7tdmi -mthumb-interwork -o 
SecondAsm
.o SecondAsm.s
arm-elf-gcc -O0  -march=armv4t -mcpu=arm7tdmi -mthumb-interwork -mthumb 
-c -o Th
irdC.o ThirdC.c
arm-elf-objdump -S FirstAsm.o > FirstAsm.lst
arm-elf-objdump -S SecondAsm.o > SecondAsm.lst
arm-elf-objdump -S ThirdC.o > ThirdC.lst
arm-elf-ld --gc-sections -Ttext 0x40001000 --section-start 
FirstSection=0x400000
00 --defsym _start=0x400C0000 -o FinalProgram.elf FirstAsm.o SecondAsm.o 
ThirdC.
o
arm-elf-ld: internal error ../../binutils-2.17/ld/ldlang.c 4275
make: *** [all] Error 1

----------------------------------------------------------------------------

as you can see, we get the error from ldlang.c line 4275. as soon as you
remove -gc-sections, this error goes away.
Comment 3 Aaron P. D'Souza 2008-07-08 05:20:28 UTC
Comment on attachment 2817 [details]
contains the Makefile, Assembly file and C file to reproduce the problem

will attach the code again
as text to enable viewing.
Comment 4 Aaron P. D'Souza 2008-07-08 05:21:40 UTC
Created attachment 2818 [details]
contains the Makefile, Assembly file and C file to reproduce the problem

contains the Makefile, Assembly file and C file to reproduce the problem
Comment 5 Aaron P. D'Souza 2008-07-08 05:23:39 UTC
Comment on attachment 2817 [details]
contains the Makefile, Assembly file and C file to reproduce the problem

leave this attachment to
enable download.
Comment 6 Aaron P. D'Souza 2008-07-08 06:52:56 UTC
Created attachment 2819 [details]
Makefile, 2 assembly files, C file to prevent the error

Makefile, 2 assembly files, C file to prevent the error
Comment 7 Aaron P. D'Souza 2008-07-08 06:54:31 UTC
i found a way to prevent the error from occuring.
all you have to do is to insert a global symbol
in the first section that is resolved by another
file that is also linked in at the same time.
voila! the problem disappears!
Comment 8 Aaron P. D'Souza 2008-07-08 07:13:51 UTC
i found out how to eliminate the problem:

- when you enable --gc-sections and Thumb interworking,
  all you need to do is to define the entry point.
  either define _start or the symbol defined using
  --entry=<entry_point>

in t2, we have defined _start, that solved the problem.
Comment 9 Nick Clifton 2008-07-09 10:29:29 UTC
Hi Aaron,

  I believe that this is an old problem, and that if you try the latest binutils
sources (from the mainline of the CVS repository) you will find that the bug
goes away.

Cheers
  Nick
Comment 10 Nick Clifton 2008-07-09 10:34:52 UTC
Additional:

  I should also point out that you should not be invoking the linker directly. 
Please use gcc to run the linker as this will ensure that the correct command
line options are used.

Cheers
  Nick
Comment 11 Aaron P. D'Souza 2008-07-17 10:04:28 UTC
good day Nick:

> if you try the latest binutils sources (from the mainline of the CVS
> repository) you will find that the bug goes away.

how do i build binutils from source for ARM?
i followed instructions on http://www.gnuarm.com/support.html

# cd [binutils-build]
# [binutils-source]/configure --target=arm-elf --prefix=[toolchain-prefix]
#   --enable-interwork --enable-multilib
# make all install

i found this to be incorrect. so, i changed it to:
--program-prefix=arm-elf --prefix=${HOME}/local --target=arm-elf

however, i get a message that i am building for arm-unknown-elf.
what should i do?

btw, i am no longer on the GCC list, so you know.

Aaron
Comment 12 Aaron P. D'Souza 2008-07-17 10:10:34 UTC
hello Nick again:

> I should also point out that you should not be invoking the linker directly. 
> Please use gcc to run the linker as this will ensure that the correct command
> line options are used.

however, if i use GCC to link, i will not be able to position the
objects and libraries in the order i want. currently, i want to:
- skip linking with crt0.o
- optionally link in crtbegin.o and the others when they are needed
- link one of my objects first
- link the other objects
- link the libraries
- link another of my objects last

if i use GCC for linking, i cannot do this.

also, i have to change all the linker options to
-Wl, style whereas with LD i can place simple space
separated options.

Aaron
Comment 13 Aaron P. D'Souza 2008-07-23 09:17:25 UTC
i just checked with the latest GNUARM distribution from GNUARM.org.
as you stated, the problem has been solved in the latest binutils.

this is the latest GNUARM package that i used for confirming the fix.
binutils-2.18, gcc-4.2.2-c-c++, newlib-1.15.0 (reentrant), insight-6.7.1,
setup.exe [102MB]
Comment 14 Aaron P. D'Souza 2008-07-23 15:13:07 UTC
i was able to download and build binutils-2.18.50 that was released today.
after building it, i verified that the bug described in this report has
been fixed. also, i confirmed that problem in bug6727 has also been fixed.