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

[Clarke, Stephen]

> From: Alexandre Oliva [mailto:aoliva@redhat.com] 
> Sent: Monday, August 12, 2002 1:11 PM
> 
> 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).

Okay.  Sorry I'm not familiar with how arm gas sets symbol types.

> 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?

The most recent version of the document is available for download at

http://www.superh-software.com/tech_docs.php

but I don't think there are any editorial changes from the version
you had.

Looking over it again, that document talks about "SHmedia symbols",
i.e. symbols with the STO_SH5_ISA32 attribute, without ever defining
what an "SHmedia symbol" is.  I suppose the thinking was that the
ELF spec. would define when STO_SH5_ISA32 would be set, but looking
at the ELF spec., that isn't much help either.

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

A trampoline is one of the places I'd anticipate datalabel being used.
(My patch did not remove the use of datalabel in the trampoline
constructed for nested fn calls.)

Jörn's point about putting code in the GOT is another scenario
where you have data and code labels at the same address.

I see two solutions for these kinds of situations:
1/ Define a code label and qualify it's use with datalabel when
   you want the true address, which is how the nested fn trampoline
   is handled.
2/ Define both a code label and a data label at the same address
   and use the appropriate one, which is how I was suggesting you
   could handle Jõrn's code in the GOT.
Either should work, but depending on the situation, one or other may
be preferable.

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

Okay.  It will take a while to turn round a new version of that
document, as it will have to go through the usual SuperH internal
procedures.  Whilst we have the opportunity, please let me know if
there is anything else you can think of that would help the document.

> 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?

Here's my first attempt at writing down a rule for this for gas,
please let me know what you think.

"The STO_SH5_ISA bit is set for code symbols that are defined when
.mode SHmedia is in force, where a 'code symbol' is a symbol with
function type, or an untyped symbol defined in an executable section.
Similarly, a 'data symbol' is a symbol with object type, or an
untyped symbol defined in a non-executable section."

There is more that could be done here: for example, in ARM's
proprietary assembler, a label that precedes (the equivalent of) a
.long directive is a data label.  But then you have to try to
distinguish between a label marking the end of the previous
instruction and a label marking the start of the .long directive,
and then before you know it newlines becomes significant, and it
can get quite hairy.

> 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?

SuperH can certainly contribute documentation to binutils.

The document that we've been talking about, "SH-5 Common Assembly
Language Syntax", is intended to be independent of any particular
toolchain, so it has to leave a lot of details out ... for example
the particular directive necessary to give a symbol function type.
But for binutils, we can be much more specific as we can assume use
of gas.

If you have specific things that you want to be put in the
GNU assembler manual, send me a list.  Otherwise, I'll use my own
judgement.

Steve.