ARM/THUMB long calls stubs

Andy Green andy.green@oxsemi.com
Wed Aug 14 08:04:00 GMT 2002


I've been trying some hackware to workaround this stubs problem, and 
wondered if anyone (e.g. Nick/Richard!) could comment on the following:

I've coded some extra stubs in assembler, e.g.

  .section .ram_code

  .globl _call_ram2rom_via_r3
	.ALIGN 2
  .thumb_func
  _call_ram2rom_via_r3:
	BX	r3
	NOP


Then I perform a two-stage compile on the compilation units that are 
present in the .ram_code section (you'll love this...)

  # compile but don't assemble the cpp file, to get assembler source
  arm-elf-g++ $(FLAGS) -S -c cfile.cpp -o cfile.s
  # replace occurences of call_via_rX with my versions of the stubs
  sed -e s/call_via_r/call_ram2rom_via_r/ cfile.s > cfile.S
  # assemble the resultant file
  arm-elf-g++ $(FLAGS) -c cfile.S -o cfile.o

Then link it all together! I realise this is a bit of a bodge to say the 
least, but I can't think of any reason why it shouldn't work. However ld 
inserts invalid destinations on the BL instruction where it should BL 
call_ram2rom_via_rX. I tried compiling with and without the 
-mthumb-interwork flag. If I don't set the flag, the linker complains 
with the following message:

  /../arm-elf/bin/ld:
  output/libNoOS.a(ramcode_stubs.o)(_call_ram2rom_via_r3): warning:
  interworking not enabled.

  /../arm-elf/bin/ld:   first occurrence: output/app_entry_ramcode.o:
  thumb call to arm
  output/app_entry_ramcode.o(.ram_code+0x70): internal error: dangerous
  error


If I _do_ set the flag, there are no errors, but instead of a BL to my 
stub, I get a BL to hyperspace (round about the middle of my IRQ stack...)

I suspect this bodgery is causing the linker to fall over - any clues on 
how I might shoehorn it?

Andy





More information about the Gcc-bugs mailing list