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

[Alexandre Oliva <aoliva at redhat dot com>]

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

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

Thanks for the pointer.  For a moment, I was worried whether I should
have even mentioned the existence of the document I had.  Phew! :-D

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

Hmm...  I assumed a SHmedia symbol was supposed to be read as any
symbol defined while SHmedia mode was in effect.

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

And yet another case is that of jump tables, that IIRC your patch
doesn't modify either.

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

I think the former is better in the sense that, in the case of the
symbol definition and its use being in separate translation units, the
definer uses a single symbol, and the user uses only the one it's
interested in (but one of them gets to be more expensive because of
the need for datalabel).  The latter is pretty much a special case of
the former that requires the definer to always define two symbols.
So, as long as the need for datalabel is not too much of an overhead,
it should be ok.  It's not clear to me how expensive it actually is,
other than for additional assembly code.  Do you have any benchmarks
on how much savings you get, in terms of build time and object size,
after you install your patch?  (This is not meant as a requirement to
get the patch in, I'm just curious).

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

this is good, and I can easily agree with it.  However, I don't see
that it would help in avoiding uses of datalabel, since what we need
to know is whether the symbol *definition* is that of a SHmedia code
symbol or not to decide whether to use the datalabel modifier when
*referencing* the symbol.

However, we might as well somehow specify a set of defined cases and
rule that anything else invokes undefined behavior.  Or perhaps do it
the other way round.  Say, if you reference a external symbol assuming
it is a data symbol, but not using DATALABEL, and it turns out to be
untyped and part of an executable section, you lose.  This is already
true with the current implementation, but since we're relaxing the
rules about when you have to use datalabel, we'd better list at least
situations in which behavior may change if you omit datalabel.

But then, since behavior may change in situations the compiler can't
control, I think I'd rather still have the compiler emit datalabel all
over, even if redundant, just to make sure its code references symbols
the way it intends.  Of course, this doesn't stop us from making the
assembler smarter as to marking symbols as STO_SH5_ISA or not.  Does
this sound reasonable?

> SuperH can certainly contribute documentation to binutils.

Excellent.

> But for binutils, we can be much more specific as we can assume use
> of gas.

Certainly.

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

I think any special handling of symbols should be documented.
datalabel references and SHmedia code symbols are probably worth
documenting there.  I'm not sure it's necessary to document the
`macro' expansions that you get from the assembler when using wide or
symbolic constants in MOVI and PT, for example.  Other binutils
maintainers may differ, though.

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