rsturmer wrote:
> Oh crap, this kind of describes my issue:
>
> http://sourceware.org/ml/binutils/2009-02/msg00295.html

Hmmm... it does look like a toolchain problem.

I've never heard of the interwork patch you're using -- I have compiled
vanilla GCC 4.3.3 for arm-elf targeting LPC2xxx and STM32 (separately),
without encountering issues, but then I don't tend to use thumb1 or
interworking.

Is there any info on it? Google only gives me what look like old results.

Pete

--
Peter J. Vidler
Senior Systems Developer, TTE Systems Ltd
www.tte-systems.com
Start a New Thread

It's a patch to the configure script that for whatever reason doesn't
build interwork properly

diff -Nur gcc-4.3.2-orig/gcc/config/arm/t-arm-elf
gcc-4.3.2/gcc/config/arm/t-arm-elf
--- gcc-4.3.2-orig/gcc/config/arm/t-arm-elf 2004-09-01
07:14:21.000000000 -0400
+++ gcc-4.3.2/gcc/config/arm/t-arm-elf 2005-12-27 13:43:45.000000000 -0500
@@ -33,8 +33,8 @@
# MULTILIB_DIRNAMES += fpu soft
# MULTILIB_EXCEPTIONS += *mthumb/*mhard-float*
#
-# MULTILIB_OPTIONS += mno-thumb-interwork/mthumb-interwork
-# MULTILIB_DIRNAMES += normal interwork
+MULTILIB_OPTIONS += mno-thumb-interwork/mthumb-interwork
+MULTILIB_DIRNAMES += normal interwork
#
# MULTILIB_OPTIONS += fno-leading-underscore/fleading-underscore
# MULTILIB_DIRNAMES += elf under

--- In l..., Peter Vidler wrote:
>
> rsturmer wrote:
> > Oh crap, this kind of describes my issue:
> >
> > http://sourceware.org/ml/binutils/2009-02/msg00295.html
>
> Hmmm... it does look like a toolchain problem.
>
> I've never heard of the interwork patch you're using -- I have compiled
> vanilla GCC 4.3.3 for arm-elf targeting LPC2xxx and STM32 (separately),
> without encountering issues, but then I don't tend to use thumb1 or
> interworking.
>
> Is there any info on it? Google only gives me what look like old
results.
>
> Pete
>
> --
> Peter J. Vidler
> Senior Systems Developer, TTE Systems Ltd
> www.tte-systems.com
>

Start a New Thread

On 26 Feb 2009, at 18:03, rsturmer wrote:
> It's a patch to the configure script that for whatever reason doesn't
> build interwork properly

Ah, I see. Is that all the patch changes? Usually I include at least
these as well:

MULTILIB_OPTIONS += mcpu=arm7
MULTILIB_DIRNAMES += nofmult
MULTILIB_EXCEPTIONS += *mthumb*/*mcpu=arm7*

...along with a few other items. I think the yagarto toolchain comes
with some build scripts that might give a working example.

I should check that my toolchains don't have the same problems -- what
build options are you using (for your files, not GCC itself)?

Pete

Start a New Thread

Here's the output of my build script, you can see the options there.

What I don't understand is, why are patches to configure necessary at
all? Shouldn't we be able to just pass it options? It seems like
understanding this mystery is the only reason YAGARTO exists.

Btw, got the latest snapshot of binutils and redid my toolchain with
that. It links everything (apparently) correcty, but my startup code
now doesn't work. Still trying to sort that out. I get a data abort
when I'm trying to set up interrupt stack location for each mode. (Weird.)
-------- begin --------
mkdir -p ./obj
mkdir -p ./list
mkdir -p ./build
arm-elf-gcc (GCC) 4.3.3
Copyright (C) 2008 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.
Compiling C code (ARM-Mode): ./src/uartISR.c
----------------------------
arm-elf-gcc -c -mcpu=arm7tdmi -mthumb-interwork -I. -gdwarf-2
-DROM_RUN -O0 -Wall -Wstrict-prototypes -Wcast-align -Wcast-qual
-Wimplicit -Wmissing-declarations -Wmissing-prototypes
-Wnested-externs -Wpointer-arith -Wswitch -Wredundant-decls
-Wreturn-type -Wshadow -Wstrict-prototypes -Wunused -mthumb-interwork
-Wa, -I./src/include -std=gnu99 -MD -MP -MF .dep/uartISR.o.d
./src/uartISR.c -o obj/uartISR.o
In file included from ./src/include/uart.h:18,
from ./src/uartISR.c:15:
./src/include/config.h:71:2: warning: #warning

Compiling C code (ARM-Mode): ./src/armVIC.c
----------------------------
arm-elf-gcc -c -mcpu=arm7tdmi -mthumb-interwork -I. -gdwarf-2
-DROM_RUN -O0 -Wall -Wstrict-prototypes -Wcast-align -Wcast-qual
-Wimplicit -Wmissing-declarations -Wmissing-prototypes
-Wnested-externs -Wpointer-arith -Wswitch -Wredundant-decls
-Wreturn-type -Wshadow -Wstrict-prototypes -Wunused -mthumb-interwork
-Wa, -I./src/include -std=gnu99 -MD -MP -MF .dep/armVIC.o.d
./src/armVIC.c -o obj/armVIC.o

Compiling C code (ARM-Mode): ./src/timerISR.c
----------------------------
arm-elf-gcc -c -mcpu=arm7tdmi -mthumb-interwork -I. -gdwarf-2
-DROM_RUN -O0 -Wall -Wstrict-prototypes -Wcast-align -Wcast-qual
-Wimplicit -Wmissing-declarations -Wmissing-prototypes
-Wnested-externs -Wpointer-arith -Wswitch -Wredundant-decls
-Wreturn-type -Wshadow -Wstrict-prototypes -Wunused -mthumb-interwork
-Wa, -I./src/include -std=gnu99 -MD -MP -MF .dep/timerISR.o.d
./src/timerISR.c -o obj/timerISR.o

Compiling C code (ARM-Mode): ./src/timers.c
----------------------------
arm-elf-gcc -c -mcpu=arm7tdmi -mthumb-interwork -I. -gdwarf-2
-DROM_RUN -O0 -Wall -Wstrict-prototypes -Wcast-align -Wcast-qual
-Wimplicit -Wmissing-declarations -Wmissing-prototypes
-Wnested-externs -Wpointer-arith -Wswitch -Wredundant-decls
-Wreturn-type -Wshadow -Wstrict-prototypes -Wunused -mthumb-interwork
-Wa, -I./src/include -std=gnu99 -MD -MP -MF .dep/timers.o.d
./src/timers.c -o obj/timers.o
./src/timers.c: In function `release_timer':
./src/timers.c:42: warning: control reaches end of non-void function
./src/timers.c: In function `wait':
./src/timers.c:47: warning: array subscript has type `char'
./src/timers.c:48: warning: array subscript has type `char'

Compiling C code (ARM-Mode): ./src/spi.c
----------------------------
arm-elf-gcc -c -mcpu=arm7tdmi -mthumb-interwork -I. -gdwarf-2
-DROM_RUN -O0 -Wall -Wstrict-prototypes -Wcast-align -Wcast-qual
-Wimplicit -Wmissing-declarations -Wmissing-prototypes
-Wnested-externs -Wpointer-arith -Wswitch -Wredundant-decls
-Wreturn-type -Wshadow -Wstrict-prototypes -Wunused -mthumb-interwork
-Wa, -I./src/include -std=gnu99 -MD -MP -MF .dep/spi.o.d ./src/spi.c
-o obj/spi.o
In file included from ./src/spi.c:3:
./src/include/config.h:34: warning: redundant redeclaration of `abort'
In file included from ./src/spi.c:3:
./src/include/config.h:71:2: warning: #warning
./src/spi.c:11: warning: no previous prototype for `spi_init'
./src/spi.c:31: warning: no previous prototype for `spi_xmit'
./src/spi.c: In function `spi_xmit':
./src/spi.c:55: warning: control reaches end of non-void function

Compiling C code (ARM-Mode): ./src/sdcard.c
----------------------------
arm-elf-gcc -c -mcpu=arm7tdmi -mthumb-interwork -I. -gdwarf-2
-DROM_RUN -O0 -Wall -Wstrict-prototypes -Wcast-align -Wcast-qual
-Wimplicit -Wmissing-declarations -Wmissing-prototypes
-Wnested-externs -Wpointer-arith -Wswitch -Wredundant-decls
-Wreturn-type -Wshadow -Wstrict-prototypes -Wunused -mthumb-interwork
-Wa, -I./src/include -std=gnu99 -MD -MP -MF .dep/sdcard.o.d
./src/sdcard.c -o obj/sdcard.o
In file included from ./src/sdcard.c:1:
./src/include/sdcard.h:3: warning: function declaration isn't a prototype
./src/include/sdcard.h:9: warning: function declaration isn't a prototype
./src/include/sdcard.h:10: warning: function declaration isn't a prototype
./src/include/sdcard.h:17: warning: function declaration isn't a prototype
In file included from ./src/sdcard.c:2:
./src/include/config.h:71:2: warning: #warning
./src/sdcard.c:63: warning: function declaration isn't a prototype
./src/sdcard.c:69: warning: function declaration isn't a prototype
./src/sdcard.c:74: warning: function declaration isn't a prototype
./src/sdcard.c: In function `mmc_response':
./src/sdcard.c:76: warning: pointer targets in passing argument 3 of
`spi_xmit' differ in signedness
./src/sdcard.c: At top level:
./src/sdcard.c:80: warning: function declaration isn't a prototype
./src/sdcard.c: In function `mmc_init':
./src/sdcard.c:98: warning: pointer targets in passing argument 1 of
`spi_xmit' differ in signedness
./src/sdcard.c: In function `mmc_cmd':
./src/sdcard.c:140: warning: pointer targets in passing argument 1 of
`spi_xmit' differ in signedness
./src/sdcard.c:141: warning: control reaches end of non-void function
./src/sdcard.c: In function `mmc_read':
./src/sdcard.c:148: warning: pointer targets in passing argument 3 of
`spi_xmit' differ in signedness
./src/sdcard.c: In function `mmc_get_csd':
./src/sdcard.c:153: warning: unused variable `response'
./src/sdcard.c: In function `mmc_get_cid':
./src/sdcard.c:168: warning: unused variable `response'
./src/sdcard.c: In function `mmc_write_block':
./src/sdcard.c:207: warning: pointer targets in passing argument 1 of
`spi_xmit' differ in signedness
./src/sdcard.c:208: warning: pointer targets in passing argument 1 of
`spi_xmit' differ in signedness
./src/sdcard.c:210: warning: pointer targets in passing argument 1 of
`spi_xmit' differ in signedness
./src/sdcard.c:212: warning: pointer targets in passing argument 1 of
`spi_xmit' differ in signedness
./src/sdcard.c: In function `mmc_read_block':
./src/sdcard.c:263: warning: pointer targets in passing argument 1 of
`spi_xmit' differ in signedness
./src/sdcard.c:264: warning: pointer targets in passing argument 3 of
`spi_xmit' differ in signedness
./src/sdcard.c:244: warning: unused variable `retries'
./src/sdcard.c:243: warning: unused variable `i'
./src/sdcard.c:240: warning: unused variable `response'

Compiling C code (ARM-Mode): ./src/main.c
----------------------------
arm-elf-gcc -c -mcpu=arm7tdmi -mthumb-interwork -I. -gdwarf-2
-DROM_RUN -O0 -Wall -Wstrict-prototypes -Wcast-align -Wcast-qual
-Wimplicit -Wmissing-declarations -Wmissing-prototypes
-Wnested-externs -Wpointer-arith -Wswitch -Wredundant-decls
-Wreturn-type -Wshadow -Wstrict-prototypes -Wunused -mthumb-interwork
-Wa, -I./src/include -std=gnu99 -MD -MP -MF .dep/main.o.d ./src/main.c
-o obj/main.o
In file included from ./src/main.c:3:
./src/include/config.h:71:2: warning: #warning
In file included from ./src/main.c:7:
./src/include/sdcard.h:3: warning: function declaration isn't a prototype
./src/include/sdcard.h:9: warning: function declaration isn't a prototype
./src/include/sdcard.h:10: warning: function declaration isn't a prototype
./src/include/sdcard.h:17: warning: function declaration isn't a prototype
./src/main.c:76: warning: no previous prototype for `execute_uart_command'
./src/main.c: In function `execute_uart_command':
./src/main.c:102: warning: pointer targets in passing argument 1 of
`decodeCID' differ in signedness
./src/main.c:81: warning: unused variable `response'
./src/main.c:80: warning: unused variable `temp'
./src/main.c:79: warning: unused variable `data2'
./src/main.c:77: warning: unused variable `k'
./src/main.c:77: warning: unused variable `j'
./src/main.c: At top level:
./src/main.c:123: warning: no previous prototype for `service_uart'
./src/main.c: In function `service_uart':
./src/main.c:128: warning: array subscript has type `char'
./src/main.c:134: warning: array subscript has type `char'
./src/main.c: In function `main':
./src/main.c:143: warning: unused variable `c'

Assembling (ARM-Mode): ./src/crt0.S
----------------------
arm-elf-gcc -c -mcpu=arm7tdmi -mthumb-interwork -I. -x
assembler-with-cpp -DROM_RUN -mthumb-interwork -Wa,-gdwarf-2
./src/crt0.S -o obj/crt0.o

Compiling C code (THUMB-Mode): ./src/uart.c
------------------------------
arm-elf-gcc -mthumb -c -mcpu=arm7tdmi -mthumb-interwork -I. -gdwarf-2
-DROM_RUN -O0 -Wall -Wstrict-prototypes -Wcast-align -Wcast-qual
-Wimplicit -Wmissing-declarations -Wmissing-prototypes
-Wnested-externs -Wpointer-arith -Wswitch -Wredundant-decls
-Wreturn-type -Wshadow -Wstrict-prototypes -Wunused -mthumb-interwork
-Wa, -I./src/include -std=gnu99 -MD -MP -MF .dep/uart.o.d ./src/uart.c
-o obj/uart.o
In file included from ./src/include/uart.h:18,
from ./src/uart.c:16:
./src/include/config.h:71:2: warning: #warning
./src/uart.c: In function `uart0Getch':
./src/uart.c:321: warning: unused variable `ch'

Compiling C code (THUMB-Mode): ./src/printf.c
------------------------------
arm-elf-gcc -mthumb -c -mcpu=arm7tdmi -mthumb-interwork -I. -gdwarf-2
-DROM_RUN -O0 -Wall -Wstrict-prototypes -Wcast-align -Wcast-qual
-Wimplicit -Wmissing-declarations -Wmissing-prototypes
-Wnested-externs -Wpointer-arith -Wswitch -Wredundant-decls
-Wreturn-type -Wshadow -Wstrict-prototypes -Wunused -mthumb-interwork
-Wa, -I./src/include -std=gnu99 -MD -MP -MF .dep/printf.o.d
./src/printf.c -o obj/printf.o
In file included from ./src/include/uart.h:18,
from ./src/printf.c:1:
./src/include/config.h:71:2: warning: #warning
./src/printf.c: In function `printchar':
./src/printf.c:32: warning: nested extern declaration of `uart0Putch'
./src/printf.c:32: warning: redundant redeclaration of `uart0Putch'
./src/include/uart.h:131: warning: previous declaration of
`uart0Putch' was here

Linking: build/main.elf
--------
arm-elf-gcc -mthumb -mcpu=arm7tdmi -mthumb-interwork -I. -gdwarf-2
-DROM_RUN -O0 -Wall -Wstrict-prototypes -Wcast-align -Wcast-qual
-Wimplicit -Wmissing-declarations -Wmissing-prototypes
-Wnested-externs -Wpointer-arith -Wswitch -Wredundant-decls
-Wreturn-type -Wshadow -Wstrict-prototypes -Wunused -mthumb-interwork
-Wa, -I./src/include -std=gnu99 -MD -MP -MF .dep/main.elf.d
./obj/uartISR.o ./obj/armVIC.o ./obj/timerISR.o ./obj/timers.o
./obj/spi.o ./obj/sdcard.o ./obj/main.o ./obj/crt0.o ./obj/uart.o
./obj/printf.o --output build/main.elf -nostartfiles
-Wl,-Map=./build/main.map,--cref -lc -lm -lc -lgcc
-T./linker/LPC2103-ROM.ld -mthumb-interwork

Creating hex file: build/main.hex
arm-elf-objcopy -O ihex build/main.elf build/main.hex

Creating extended listing: build/main.lss
arm-elf-objdump -h -S build/main.elf > build/main.lss

Creating symbol table: build/main.sym
arm-elf-nm -n build/main.elf > build/main.sym

Size
LINKER MEMORY SECTIONS:
-----------------------
Section Origin Size
ROM 0x00000000 0x00008000
RAM 0x40000000 0x00002000

ELF FILE MEMORY SECTIONS:
-------------------------
Section Origin Size
.text 0x00000000 0x00002c58
.data 0x40000000 0x00000008
.bss 0x40000008 0x000004a4
.stack 0x40000500 0x00000400
.ARM.attributes 0x00000000 0x00000010
.comment 0x00000000 0x000000d8
.debug_aranges 0x00000000 0x000001e0
.debug_pubnames 0x00000000 0x000004ee
.debug_info 0x00000000 0x00003537
.debug_abbrev 0x00000000 0x00000b3d
.debug_line 0x00000000 0x00000ad7
.debug_frame 0x00000000 0x00000848
.debug_str 0x00000000 0x000008d8
.debug_loc 0x00000000 0x00000ce2
.debug_ranges 0x00000000 0x00000038

USAGE SUMMARY:
--------------
ROM : 41.57% Used
RAM : 27.10% Used

Errors: none
--------- end ---------
--- In l..., Peter Vidler wrote:
>
> On 26 Feb 2009, at 18:03, rsturmer wrote:
> > It's a patch to the configure script that for whatever reason doesn't
> > build interwork properly
>
> Ah, I see. Is that all the patch changes? Usually I include at least
> these as well:
>
> MULTILIB_OPTIONS += mcpu=arm7
> MULTILIB_DIRNAMES += nofmult
> MULTILIB_EXCEPTIONS += *mthumb*/*mcpu=arm7*
>
> ...along with a few other items. I think the yagarto toolchain comes
> with some build scripts that might give a working example.
>
> I should check that my toolchains don't have the same problems -- what
> build options are you using (for your files, not GCC itself)?
>
> Pete
>

Start a New Thread

rsturmer wrote:
> Here's the output of my build script, you can see the options there.

I was able to replicate the problem in my toolchain, and I couldn't
affect the location of the stub with the linker script (very annoying).
It is almost certainly a GCC bug, from what you said before they are
aware of it?

Can you switch to fully arm mode until it is fixed? The problem goes
away if nothing is compiled as thumb -- even if interworking is left
enabled (though it would be pointless to leave it on).

> What I don't understand is, why are patches to configure necessary at
> all? Shouldn't we be able to just pass it options? It seems like
> understanding this mystery is the only reason YAGARTO exists.

It just seems to be how multilib is configured. Most platforms I've
used already had the right options set, but arm-elf seems to have most
commented out by default, for some reason. Odd because all they do is
build different combinations of the libraries, which is usually harmless
unless you specify the associated linker option.

Perhaps because not all the options are compatible with the standard
libraries out there? I know that building newlib for Cortex-M3 was
tricky; it needed certain compiler options that were incompatible with
some of the multilib settings. Finding the right combination seems to
require trial and error (and a *lot* of patience).

Pete

--
Peter J. Vidler
Senior Systems Developer, TTE Systems Ltd
www.tte-systems.com
Start a New Thread

Peter Vidler schrieb:
> rsturmer wrote:
>> Here's the output of my build script, you can see the options there.
>
> I was able to replicate the problem in my toolchain, and I couldn't
> affect the location of the stub with the linker script (very annoying).
> It is almost certainly a GCC bug, from what you said before they are
> aware of it?

If, then not gcc but ld (binutils).
--
42Bastian

Note: SPAM-only account, direct mail to bs42@...
Start a New Thread

42Bastian wrote:
> If, then not gcc but ld (binutils).

Yeah, I always forget they are separate projects. Most of the time I
lump GDB in there as well :)

I found a way to work around the bug. The stub only seems to get added
to the '.text' section, so we can add the startup to a section of its
own (*before* '.text' in the script):

.startup :
{
KEEP(*(.startup))
. = ALIGN(0x100);
} >ROM

Obviously you should also remove the startup from '.text' (not that it
would make any difference, but it could cause confusion later on).

I had to add the alignment option because OpenOCD complained if I didn't
-- it seems to want 0x100 for some reason. Other than that it works
perfectly, at least in my brief testing.

Pete

--
Peter J. Vidler
Senior Systems Developer, TTE Systems Ltd
www.tte-systems.com
Start a New Thread

It's an ld thing. I was using the latest "stable release" of
binutils, which is 2.19.1, but the bug is fixed in the latest source
snapshot, which is 2.19.51, upgrading puts the stubs in the right place.

Since I've got your attention, does anyone have a clue why my program
might be data-aborting when it does? It never did this with the old
version of the tools. This upgrade is a nightmare... but I'm learning
a lot.

The startup code (when correctly linked) seems to execute fine until:

// Initialize Interrupt System
// - Set stack location for each mode
// - Leave in System Mode with Interrupts Disabled
// -----------
ldr r0,=_stack
msr CPSR_c,#MODE_UND|I_BIT|F_BIT // Undefined Instruction Mode
mov sp,r0

mov sp,r0 causes a data abort. (see my startup code above for the
whole thing)

Cheers!

-R

--- In l..., Peter Vidler wrote:
>
> 42Bastian wrote:
> > If, then not gcc but ld (binutils).
>
> Yeah, I always forget they are separate projects. Most of the time I
> lump GDB in there as well :)
>
> I found a way to work around the bug. The stub only seems to get added
> to the '.text' section, so we can add the startup to a section of its
> own (*before* '.text' in the script):
>
> .startup :
> {
> KEEP(*(.startup))
> . = ALIGN(0x100);
> } >ROM
>
> Obviously you should also remove the startup from '.text' (not that it
> would make any difference, but it could cause confusion later on).
>
> I had to add the alignment option because OpenOCD complained if I
didn't
> -- it seems to want 0x100 for some reason. Other than that it works
> perfectly, at least in my brief testing.
>
> Pete
>
> --
> Peter J. Vidler
> Senior Systems Developer, TTE Systems Ltd
> www.tte-systems.com
>

Start a New Thread

rsturmer wrote:
> It's an ld thing. I was using the latest "stable release" of
> binutils, which is 2.19.1, but the bug is fixed in the latest source
> snapshot, which is 2.19.51, upgrading puts the stubs in the right place.

The change I mentioned before works fine with 2.19.1.

I'm actually thinking of changing all my linker scripts in a similar
way, in case future changes to ld try to dump things at the start of the
text section.

> Since I've got your attention, does anyone have a clue why my program
> might be data-aborting when it does? It never did this with the old
> version of the tools. This upgrade is a nightmare... but I'm learning
> a lot.

Well, I tend to stay away from bleeding-edge builds; toolchain issues
are just too much hassle to track down. They probably have their own
mailing lists and bug tracking though -- you might try there if no-one
here can help.

(Not that I actually looked at the code -- it might just be a bug in
your startup).

Pete

--
Peter J. Vidler
Senior Systems Developer, TTE Systems Ltd
www.tte-systems.com
Start a New Thread

... I see now why they're called the "bleeding" edge builds...
--- In l..., Peter Vidler wrote:
>
> rsturmer wrote:
> > It's an ld thing. I was using the latest "stable release" of
> > binutils, which is 2.19.1, but the bug is fixed in the latest source
> > snapshot, which is 2.19.51, upgrading puts the stubs in the right
place.
>
> The change I mentioned before works fine with 2.19.1.
>
> I'm actually thinking of changing all my linker scripts in a similar
> way, in case future changes to ld try to dump things at the start of
the
> text section.
>
> > Since I've got your attention, does anyone have a clue why my program
> > might be data-aborting when it does? It never did this with the old
> > version of the tools. This upgrade is a nightmare... but I'm learning
> > a lot.
>
> Well, I tend to stay away from bleeding-edge builds; toolchain issues
> are just too much hassle to track down. They probably have their own
> mailing lists and bug tracking though -- you might try there if no-one
> here can help.
>
> (Not that I actually looked at the code -- it might just be a bug in
> your startup).
>
> Pete
>
> --
> Peter J. Vidler
> Senior Systems Developer, TTE Systems Ltd
> www.tte-systems.com
>

Start a New Thread