1. Home
  2. Embedded Programming
  3. GNU LD fails to generate correct ARM Thumb veneer

GNU LD fails to generate correct ARM Thumb veneer

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

--
{tel: +91-20-6526-7076; cell: +91-9970-591-079; fax: +1-800-450-5419}
Reply to
adsouzp
Loading thread data ...

adsouzp wrote: ...

... It is not analysis of your problem but maybe it will help a little. There is a special directive KEEP to prevent section removal by linker. Below fargment of my rom71x.ld linker file (for RAM placement KEEP works as well).

.text : { KEEP(*(.vectrom)) KEEP(*(.init)) *(.text .text.*) *(.gnu.linkonce.t.*) *(.glue_7t .glue_7) KEEP(*(.fini)) *(.gcc_except_table) } >CODE =0 . = ALIGN(4);

Regards,

--
Artur Lipowski
Reply to
Artur Lipowski

hello:

thank you, thank you.

i did a lot of research on the problem and filed bugs in GCC bugzilla as well as on Mikrocontroller.net.

pls see these links for more information:

- GCC Bugzilla Bug 6726

formatting link

- GCC Bugzilla Bug 6727

formatting link

- Mikrocontroller.net Forum

formatting link

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

Reply to
adsouzp

hello:

here is an update on the bugs that i encountered.

Nick Clifton of RedHat says that both bugs are old, known ones and have been fixed in the latest version of binutils.

pls see bug 6726 & 6727 bug reports for updates.

- GCC Bugzilla Bug 6726

formatting link

- GCC Bugzilla Bug 6727

formatting link

Aaron

-- { why discuss/expose needlessly and start a commotion? }

Reply to
adsouzp

hello:

here is an update on the bugs that i encountered.

Nick Clifton of RedHat says that both bugs are old, known ones and have been fixed in the latest version of binutils.

pls see bug 6726 & 6727 bug reports for updates.

- GCC Bugzilla Bug 6726

formatting link

- GCC Bugzilla Bug 6727

formatting link

Aaron

-- { why discuss/expose needlessly and start a commotion? }

Reply to
adsouzp

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.