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: Jan Waclawek
Subject: Re: [avr-gcc-list] documenting pm() and gs() avr-as operators
Date: Sat, 22 May 2010 23:50:21 +0200

> If you don't know something, you can simply ask.

Okay.
What do pm() and gs() exactly do?

> Btw., as a stop-gap measure, we added it to the avr-libc documentation
> some time ago, 

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.

> The better it fits
> into the project (e.g.: include a "ChangeLog" snippet), the higher the
> probability it will go in.

I've browsed through the changelogs of gas, but found no mention of gs(). I 
doubt some random snippet of changelog would do the trick ;-)

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."

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).

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

---

> Not really, and I'm a little sorry there is no formal bug tracker
> available for Mfile, as it isn't really a standalone project of its
> own.  We used to host it in the WinAVR repository, but as Eric is
> going to transition WinAVR to another project (under the umbrella of
> Atmel), there's no longer a bug & patch tracker around.  As such, your
> suggestion simply sits in my inbox, hoping I'll find enough time and
> devotion to polish up Mfile again some day, and then going to remember
> there's still an email from you.

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

> 
> 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. There are 
"not-that-strictly-libc" things there anyway, at least in the docs, and I don't 
believe anybody would complain. The decision is, of course, all yours.

Thanks anyway.

Jan



reply via email to

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