Re: Link problems with section anchors

[Richard Sandiford <richard at codesourcery dot com>]

I wasn't really sure whether to reply to the gcc bug report or the
binutils thread.  As you can see, I chose here.

The gcc bug report (28598) seems a little confused to me.  It appears
to be saying "gcc should not use GOT relocs for anchor symbols", but how
else is it supposed to load the value of the symbol?  From an addressing
perspective, the anchor symbol is no different from any other local symbol.

Perhaps this was influenced by what Alan said:

Alan Modra <amodra@bigpond.net.au> writes:
> I'd say this is a gcc bug.  (The GOT reloc can't really use section
> anchors anyway because sym+off@got has rather useless semantics, so why
> can't gcc use the original symbol?)

...but we don't use sym+off@got for anchors.  Well, OK, I'll have
to equivocate that slightly, but first...

The point of -fsection-anchors is to access (hopefully) several nearby
objects from the same symbol, where "nearby" depends on the addressing
capabilities of the target.  On PPC "nearby" == "within a 32-bit signed
displacement".

We start out by modelling each access as follows: we load an anchor
symbol into a base register, then apply the relative offset of the
object to that base register.  We win if, by doing this, we can access
more than one object from the same symbol.  For example, when using
a GOT, we'll only have one GOT entry for the anchor symbol rather
than several entries for each object.

The equivocation is that, if an anchor is only used once, gcc may
optimise "load ANCHOR then add OFFSET" into "load (ANCHOR + OFFSET)".
But the backend will (should!) handle this load in the same way as it
would handle any another "load (LOCAL + OFFSET)" access.  There is
nothing special about the anchor symbol as far as the addressing
code goes.

In other words, we'd only use "ANCHOR+OFFSET@got" if an anchor is
only used once, and only then if we would also use "LOCAL+OFFSET@got".

> ld can't treat the local symbols in linkonce sections as if they were
> global because .LANCHOR0 in .gnu.linkonce.r.__strtol_ul_max_tab must
> be different from .LANCHOR0 in .gnu.linkonce.r.some_other_name.  Hmm,
> I suppose ld could create a new global name that incorporated the
> section name, and do the same for section groups, but twiddling relocs
> to use a different symbol is non-trivial.

Yes, it sounds like you have a testcase in which anchors are used to
access linkonce objects.  This Should Not Happen, and if it is happening,
is the real bug.  Link-once objects were supposed to be handled by:

static struct object_block *
get_block_for_decl (tree decl)
{
  section *sect;

  if (TREE_CODE (decl) == VAR_DECL)
    {
      [...]
      /* There's no point using object blocks for something that is
	 isolated by definition.  */
      if (DECL_ONE_ONLY (decl))
	return NULL;
    }
}

(In case the emphasis of the comment seems odd; this code is deciding
whether it's worthwhile grouping objects together.  That's a more
general question than "do we want to use anchors for this object"?
The hope is that we might want to group objects together for other
optimisations too, such choosing as a more cache-friendly layout.)

Could someone prepare a testcase?  Thanks.

Richard