EmbDev.net

Forum: ARM programming with GCC/GNU tools GNU LD fails to generate correct ARM Thumb veneer


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

Rate this post
0 useful
not useful
good day people:

i have been using GNUARM/Cygwin for some time now and i
have not encountered a problem like this before.

BACKGROUND
- target MCU is STR71x
- CPU core is ARM7TDMI
- toolchain is GNUARM 4.1.1 on Cygwin
- source code
  - the first file to be linked is an ARM assembly .s file
    that contains the ARM vector table and handler addresses.
    the vector table is in a separate section called .VhaInit.
    when linked, it is located to 0x20000000 (SRAM) or 0x40000000
(Flash)

  - the second file is another ARM assembly .s file that contains
    C startup code. when linked, the .text is located to 0x20000080
(SRAM)
    or 0x40000080 (Flash), just after .VhaInit.

  - assembly files are assembled with -mthumb-interworking but are
written
    in pure ARM code.

  - there is a C file that is compiled with -mthumb
-mthumb-interworking.

  - i also link with -gc-sections, and C code is compiled with
    -ffunction-sections and -fdata-sections so that unused C code is
    eliminated by the linker.

  - ResetHandler entry is set to 0x400C0000 using --defsym option of LD:
    --defsym ResetHandler=0x400C0000

PROBLEM
- when i add code to access .VhaInit entries from .text to prevent the
  garbage collection of .VhaInit, Thumb Interworking code is ZERO. the
  entries are present, but no interworking code is present.

- when i remove code that accesses .VhaInit, Interworking code is
correct.

- when i disable -ffunction-sections, -fdata-sections, and -gc-sections,
  and when i still access data in .VhaInit from .text, Interworking is
correct.

so, what's going on? 8-)

i think its a bug in GNU LD.

any help will be gratefully accepted.

have a nice day,

Aaron

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

Rate this post
0 useful
not useful
Please create a minimal example to reproduce the problem with all files
needed for a "make all" and attach it to a message

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

Rate this post
0 useful
not useful
Martin Thomas wrote:
> Please create a minimal example to reproduce the problem with all files
> needed for a "make all" and attach it to a message

okay. its just early morning here. 8-)
thank you, Martin, for your prompt response.

Aaron

Author: Aaron D'souza (adsouzp)
Posted on:
Attached files:
  • t1 (1.22 KB, 330 downloads)

Rate this post
0 useful
not useful
Martin Thomas wrote:
> Please create a minimal example to reproduce the problem with all files
> needed for a "make all" and attach it to a message

i have attached a file t1 which contains Makefile, FirstAsm.s,
SecondC.c.
here, i was able to reproduce a related problem and not the problem that
i observed.

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

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.

i am still trying to reproduce the problem that i first observed and
will
post the code after that.

Aaron

Author: Aaron D'souza (adsouzp)
Posted on:
Attached files:
  • t3 (1.55 KB, 255 downloads)

Rate this post
0 useful
not useful
hello Martin, others:

Aaron D'souza wrote:
> i am still trying to reproduce the problem that i first observed and
> will post the code after that.

attached is the source and the results.

ATTACHMENT
Makefile, 2 assembly files, C file to reproduce the error

when:
- --gc-sections is enabled
- .data and .text are in 2 separate files, and
- .data is positioned first using -Tdata, and
- .text is positioned after using -Ttext,

then:
Thumb interworking code is zero

Author: Aaron D'souza (adsouzp)
Posted on:
Attached files:
  • t4 (1.7 KB, 243 downloads)

Rate this post
0 useful
not useful
hello Martin:

Aaron D'Souza wrote:
> i am still trying to reproduce the problem that i first observed and
> will post the code after that.

ATTACHMENT
Makefile, 2 assembly files, C file to prevent the error

when:
- --gc-sections is enabled
- .data and .text are in 2 separate files, and
- .text is positioned first using -Ttext, and
- .data is positioned after using -Tdata,

then:
Thumb interworking code is CORRECT!

Author: Aaron D'souza (adsouzp)
Posted on:
Attached files:
  • t1 (1.6 KB, 268 downloads)

Rate this post
0 useful
not useful
hello:

i was able to reproduce the ldlang 4275 problem also. it has been
reported
to GCC Bugzilla bug no. 6726.

http://sourceware.org/bugzilla/show_bug.cgi?id=6726

Aaron D'Souza wrote:
> as you can see, we get the error from ldlang.c line 4275. as soon as you
> remove -gc-sections, this error goes away.

the problem occurs:
- when --gc-sections is enabled
- when Thumb interworking is enabled
- only when the entry point is not defined

pls see the attachment for source and results

Aaron

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

Rate this post
0 useful
not useful
hello all:

Aaron D'souza wrote:
> i was able to reproduce the ldlang 4275 problem also. it has been
> reported to GCC Bugzilla bug no. 6726.
>
> http://sourceware.org/bugzilla/show_bug.cgi?id=6726

the problem is solved when you define the entry point _start or whatever
you use.

Aaron

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

Rate this post
0 useful
not useful
hello:

Aaron D'souza wrote:
> Thumb interworking code is CORRECT!

for the Thumb interworking code correctness, the problem has been
ported to GCC Bugzilla as bug no. 6727.

http://sourceware.org/bugzilla/show_bug.cgi?id=6727

Aaron

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

Rate this post
0 useful
not useful
here is a complete summary of the problem and an update from
Nick Clifton of RedHat. i have also informed Pablo Bleyer Kocik
of GNUARM since i am using GNUARM on Cygwin.

i have found 2 problems with the current GNUARM distribution, which Nick
Clifton has said are due to errors in binutils that have already been
fixed in
the latest version.

2 bugs have been filed with GCC and reports have been filed with
Comp.Arch.Embedded and Mikrocontroller.net Forum.

the problem was reproduced using simple, sample code and details have
been
added into the Sourceware BugZilla bug reports.

the information below is for your reference. kindly let me know if you
need any
more information.

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

- Comp.Arch.Embedded
  http://www.embeddedrelated.com/usenet/embedded/sho...

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
--
{
  the commotion causes more harm than help solve problems;
  and i cannot get them to stop interfering with personal
  problems that i can solve;
  there has to be something else also
}

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.