Re: Advice needed on when to synthesize <sym>.high_bound in ld

[Greg McGary <greg at mcgary dot org>]

I wrote:

> : It's a tough call.  I like the high_bound pseudo-op idea as
> : conceptually cleaner, but it touches more programs.  I don't like
> : faking symbols, but it's less trouble since only LD is involved.
> : Since you seem to appreciate the tradeoffs and haven't expressed
> : strong preference for either one, I guess I'll just pick the
> : easiest-to-implement one (fake `*.gnu_bp_high_bound' symbols).  If
> : there's compelling reason to shift to the _high_bound pseudo op we can
> : always do that later and phase out the fake symbols after a binutils
> : release cycle or two.

I began adding a pass called lang_set_high_bound in lang_process,
immediately before lang_set_startof.  It does this:

  if (! link_info.relocateable)
    bfd_link_hash_traverse (link_info.hash, lang_set_one_high_bound, (PTR) NULL);

lang_set_one_high_bound looks for an undefined symbol whose name has
the suffix ".gnu_bp_high_bound" and looks-up the base-name symbol.
It copies the u.def.section from the base symbol and sets the
high_bound symbol's type from undefined to defined.

The problematic part is how to set the value.  For common symbols,
it's easy: h->u.def.value = datum->u.def.value + datum->u.c.size; (h
is the high_bound symbol, and datum is the base-name symbol).  For an
initialized data symbol, it's not so easy since there's no size field
in the symbol table.  Are you aware of any convenient way out of this?

If there's no good way to define high_bound for data at link time, I
retain the code in gcc that emits a "foo.gnu_bp_high_bound" definition
for every public initialized aggregate.  I had hoped to drop that, but
there might be no better way.

Note that it's problemantic to deduce the high bound by finding the
address of the datum that is laid out at the next higher address in
memory since there might be some unknown amount of alignment padding
between the true high bound and the start of the next symbol.  Doing
it this way is not completely unacceptable, however.  It depends on
how strict you want to be.  A reference that falls beyond a datum and
into the alignment-padding region does violate bounds, but is
otherwise harmless since it hasn't encroached on the next datum.

Please advise.

Thanks,
Greg