avr-gcc-list
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avr-gcc-list] documenting pm() and gs() avr-as operators


From: Joerg Wunsch
Subject: Re: [avr-gcc-list] documenting pm() and gs() avr-as operators
Date: Sun, 23 May 2010 00:12:39 +0200
User-agent: Mutt/1.5.20 (2009-06-14)

As Jan Waclawek wrote:

> Could you please point me at it, I can't find it. I can find a
> mention of pm in
> http://www.nongnu.org/avr-libc/user-manual/assembler.html (although
> not its modifications documented in the as documentation); but I
> can't find explanation of gs.

You're right, the explanation of gs is missing.

> However, I did find this:
> http://gcc.gnu.org/ml/gcc-patches/2006-05/msg00534.html

> which says, among others:
> "In order to distinguish relocs where stubs should be generated and relocs
> where no stubs should be generated, there are now two new ldi-type PM relocs 
> that
> carry the GS suffix instead of PM. Gas now knows of the directives gs() that
> has the same functionality as pm(), only that it generates the GS relocs that
> force the linker to generate stubs."

OK, so you found all the documentation that we've got about it. :-/

(Now I even understand what "GS" stands for "generate stubs".)

> It is sort of Greek to me, though; not really something I would call
> user documentation (as I said, I do have a faint idea what those
> things do, but I like things to be straight and solid).

Did you understand the pm operator?  Basically, it's performing a
shift operation by one bit, which is needed since all the code
addresses in flash are meant to be in units of 16-bit words, while
everything else (including all the GNU tools) "think" in units of
8-bit bytes.

The pm operator works at the linker level, so it can accept
relocatable symbols (where the actual address is inserted by the
linker after resolving the relocation).  That's why it requires the
introduction of a relocation code within the object file, so the
assembler can transfer that information to the linker.  That's also
the reason why you cannot perform the bit shift directly in assembly
language: neither the ELF file format nor the GNU linker has any
method to transfer that bit shifting into the linker, as there is no
support for performing arbitrary arithmetics on relocational symbols.
(Well, the linker used on the PDP-11, running RSX-11 did have the
ability to do that.  But that's been 30 years ago. ;-)

For machines with <= 128 KiB of flash ROM, the gs operator works the
same.  For larger machines, it tells the linker to perform special
actions on the data labelled that way, so the linker can take care to
handle addresses beyond the current 128 KiB segment where a trampoline
entry is needed.  (Disclaimer: that's how *I* understood it.  Bjoern
might correct me here...)

> Btw., isn't Bjoern Haase subscribed to this forum? He seems to be
> the right person to be pestered for the proper docs...

Yes, he is, but I'm afraid he might have unsubscribed some time
ago. :-(

[Mfile]

> Oh, and we even provided the patch this time! ;-) Okay, not a formal
> one, but it's just inserting 3 lines anyway.

Appreciated, be sure.

> > I'm not quite satisfied with that situation, but Mfile is just
> > such a minor thing so I'm a little reluctant about pushing it up
> > into a full-blown savannah or sourceforge project of its own.

> I believe it could be simply sticked to avr-libc.

I already thought about that as on option, yes.  Might be a good
compromise, indeed.

-- 
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)



reply via email to

[Prev in Thread] Current Thread [Next in Thread]