Why is there a chunk of 0's in my hex?

Go To Last Post
11 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi wizards,

I've noticed a big chunk of 0's (about 1200 bytes worth) in the generated code/hex file. It occurs where the "trampoline" starts, but there does not appear to be anything really residing there. The map in this area looks like:

.progmem.data  0x0000200a       0xe9 obj/CmdMfg.o
                0x000020f4                . = ALIGN (0x2)
 *fill*         0x000020f3        0x1 00
                0x000020f4                __trampolines_start = .
 *(.trampolines)
 .trampolines   0x000020f4        0x0 linker stubs
 *(.trampolines*)
                0x000020f4                __trampolines_end = .
 *(.jumptables)
 *(.jumptables*)
 *(.lowtext)
 *(.lowtext*)
                0x000020f4                __ctors_start = .
 *(.ctors)
                0x000020f4                __ctors_end = .
                0x000020f4                __dtors_start = .
 *(.dtors)
                0x000020f4                __dtors_end = .
 SORT(*)(.ctors)
 SORT(*)(.dtors)
 *(.init0)
 .init0         0x000025a4        0x0 c:/winavr/bin/../lib/gcc/avr/4.1.1/../../../../avr/lib/avr6/crtm2560.o
                0x000025a4                __init

So what is happening between 0x000020f4 and 0x000025a4? Can I get rid of it, or does it serve a purpose?

I'm using the latest toolset and building for the ATmega2560. The makefile was generated from Mfile, then expanded a little (yeah, yeah, sorry about that).

Thanks for pointers!

Stu

Engineering seems to boil down to: Cheap. Fast. Good. Choose two. Sometimes choose only one.

Newbie? Be sure to read the thread Newbie? Start here!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What does the LSS show to be located between 20F4 and 25A4 ?

Cliff

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The .lss shows the same thing that the .map (that I included above) does:

000020ed :
    20ed:	09 0a 0b 0c 0b 0c 00                                .......

000020f4 <__trampolines_start>:
	...

000025a4 <__ctors_end>:
    25a4:	11 24       	eor	r1, r1
    25a6:	1f be       	out	0x3f, r1	; 63
    25a8:	cf ef       	ldi	r28, 0xFF	; 255
    25aa:	d1 e2       	ldi	r29, 0x21	; 33
    25ac:	de bf       	out	0x3e, r29	; 62
    25ae:	cd bf       	out	0x3d, r28	; 61

So this is the trampoline section (which I had already deduced but decided to leave out of my request in case I had misinterpreted it).

So, perhaps my question should be: Is there some way to set the size of the trampolines? A section of 1200 bytes of 0 doesn't seem to be a real help to things.

(HMMMmm... or maybe it is... if ALL of the avr-libc functions call through the trampolines, then it might make sense. But then, why are they all zeros?)

Stu

Engineering seems to boil down to: Cheap. Fast. Good. Choose two. Sometimes choose only one.

Newbie? Be sure to read the thread Newbie? Start here!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Having read about trampolines:

http://en.wikipedia.org/wiki/Tra...(computers)
http://gcc.gnu.org/onlinedocs/gc...

it seems odd in a Harvard architecture that any part of the code space would be reserved for this at all? The fact is that an AVR cannot execute code created on the stack or anywhere dynamically (short of something that does SPMs!). So I don't see how there might be any usage of this in an AVR at all.

I know you said you modified the Mfile template - how exactly? Have you passed some additional compiler flag that isn't approriate for the AVR perhaps? (admittedly wild guess territory!)

Cliff

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Actually, being intrigued by something new, I kept googling and found this about trampolines:

http://www.technovelty.org/code/...

The implication of this is they occur when a function defintion is nested within another function definition (I know the other links referred to that but there's nowt quite like seeing an example to understand what it really means!)

I don't suppose you have any functions within functions do you?

Cliff

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I think that trampoline part is used for jump tables inserted by the
linker. This is to overcome the limitation of the JMP instruction to
only access at most 128 KiB of ROM without increasing any and all
pointers from 16 bits (which GCC currently uses for the AVR8) to 32
bits.

I have no idea how the size of that trampoline section is determined.
You might want to ask on avr-gcc-list (at nongnu.org), as that's where
Björn Haase, the author of that implementation, is listening (he
doesn't follow this forum here).

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Function within a function? Nope, I don't like that programming style.

My understanding of the use of trampolines, specific to the m2560, is that the gcc crew are using them to automagically allow the compiler to generate 17-bit-address-compatible code. The concept is that any references to routines in the second page of flash would be called through the trampoline (a table of EICALLs, I presume).

I'm guessing that they have allocated a table to allow the linker to fill on need, but the linker has no need, ergo all 0's.

I can't really complain, as it's a bit of clever programming that allows me to do my work. I'd hoped they would describe what they'd done, but I guess they're so busy doing the code that they haven't been able to document it. I never do that. (Yeah. Right. :oops: )

Joerg? Eric? Y'all listening? ;-)

Stu

PS: Sorry Joerg, I just missed your post. I will post on the mail list, as you suggest.

Engineering seems to boil down to: Cheap. Fast. Good. Choose two. Sometimes choose only one.

Newbie? Be sure to read the thread Newbie? Start here!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

But if this section was filled by the linker (and not at runtime) then (a) why would it be apparently blank in the .lss which is a dump of the final .elf and (b) why would it just be a block of zeros in the ultimate .hex file that is built?

Cliff

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Cliff,

That's why Joerg suggested asking on the avr-gcc-list mailing list, and specifically of Björn Haase, how this all this works. He's the original author of this part, and it was introduced specifically for the ATmega256x parts. Joerg and I haven't (yet) got into the details of this. We've just been applying his patch on our distros.

Eric

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have sent the request, although I forgot to single out Björn. I'll post the answer when I get it.

Stu

Engineering seems to boil down to: Cheap. Fast. Good. Choose two. Sometimes choose only one.

Newbie? Be sure to read the thread Newbie? Start here!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

For the curious (and as Stu is still asleep I think), here's Björn's reply:

http://lists.gnu.org/archive/htm...

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.