This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFA/PATCH]: sh64: Unnecessary use of datalabel operator


On Aug 12, 2002, "Clarke, Stephen" <stephen.clarke@superh.com> wrote:

> That wasn't really the intention ...  the intention was that labels
> be treated as code or data symbols and the STO_SH5_ISA32 attribute be
> given only to SHmedia code labels.  I think this is pretty much the
> same as thumb?

IIRC, Thumb code labels have to be explicitly declared as such (or
it's the other way round: non-code labels have to be explicitly
marked).

> But that scheme loses some expressiveness, because sometimes you
> really do want to treat a code label as an address rather than as a
> branch target (e.g. in the code sequence for a jump table), so we
> added the datalabel operator to override the adjustment for the
> STO_SH5_ISA32 attribute.

How about really wanting to treat some pointer to data like code (say,
a trampoline generated in a data section).


Section 4.2.4 of my copy of `SH-5/ST50 Common Assembly Language
Syntax' (Sept 5, 2000) seems to be in direct contradiction of the
intent, or at least it reads as such to me.  Is there any updated
version of this document that clarifies the intended behavior and
supports your description of it?

> However, the compiler explicitly marks i as data using

>   .type   _i,@object

> If gas were modified so that it did not give the STO_SH5_ISA32
> attribute to symbols declared as "object", then the example would
> work.

I see.  I suppose you're not concerned about cases like that of the
trampoline code above, in which you may have say a data and a code
labels aliased to the same address.  In a perfect world, referencing
the code symbol should cause it to get the ISA bit set should it be
translated in SHmedia mode, but referencing the data symbol should
cause it to not get the ISA bit set.  The only way I see to get this
effect is to use datalabel explicitly.  Trying to be smarter than that
would cause you to get one of the symbols wrong.

> Would you consider this modification to gas, if I prepared a patch
> for it?

If there is a newer version of the SH5 assembly documentation that
supports this change, and it doesn't introduce regressions in the
binutils testsuite (or fixes whatever differences such a change
exposes :-), I guess I'm ok with that.  The trampoline case is
probably sufficiently uncommon that we can afford having to fix it up
by hand.  I actually like the idea of using symbol types to tell
whether to set the ISA bit or not (at first, I had got the impression
it was going to be related with sections, which I disliked).  I'm
still unsure on how to handle untyped symbols, though.  Should their
type be inferred from the section name, from section flags, or what?
Whatever decisions are made regarding this should probably be
documented in the SH5 assembly manual, or perhaps even folded into the
GNU assembler manual.  Could SuperH contribute such documentation to
GNU binutils?

Thanks,

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]