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

[Nick Clifton <nickc at redhat dot com>]

Hi Greg,

: For bounded pointers (see http://gcc.gnu.org/projects/bp/main.html),
: gcc emits a reference to a symbol named `foo.high_bound' if it doesn't
: have enough information to determine the size of `foo'.  This happens
: often for extern arrays and extern instances of incomplete struct types.
: 
: At link time, I wish to synthesize definitions for symbols with a
: `.high_bound' suffix when the real size is known.  For ELF (and mostly
: what I care about), this is easy since all data & common symbol table
: entries have sizes.

Hmm, I am not entirely sure that synthesising new symbols is the right
way to go. As I see it there are a couple of problems:

  * They will grow the symbol table.  Although presumably enabling
    bounded pointer checking significantly grows the code being
    produced by gcc, so the extra overhead of more symbols in the
    symbol table is probably not that important.

  * It "feels" wrong.  Presumably foo.high_bound is meant to refer to
    the upper address of the space pointed to by symbol foo, so that
    you can generate code like:

	if (ptr > foo.high_bound)
            bound_check_abort ();

    foo.high_bound is not really a symbol in its own right, but rather
    a property of foo.  I think that the right way therefore would be
    to express foo.high_bound as a reloc based on the symbol foo.

    With this scheme the compiler would generate code like this:

       if (ptr > _high_bound (foo))
         bound_check_abort ();

    Which would translate into assembler like this:

       load_reg  r1, [.L0]
       comp_reg  r1, r2
       branch_le .L1
       call      bound_check_abort
     .L1:
       ....
     .L0:
       .word  _high_bound (foo)

    Where _high_bound() is an assembler pseudo op to generate a
    R_BFD_HIGH_BOUND reloc for the named symbol.
     
    Of course using relocs would involve changing both the assembler
    and linker (and probably involve target specific changes in almost
    all of the ELF based GAS targets) which would mean more
    opportunities for bugs to creep in, so you would have to consider
    whether this approach is worthwhile.

: What's the best time to do this?  Should I make a separate pass
: prior to ldwrite looking for undefined .high_bound symbols and
: create definitions for them.  Or, should I proceed with ldwrite, and
: create just-in-time definions for undefined .high_bound symbols.

If you are going to go with the symbol approach, then I think that
earlier is better.  All kinds of things depend upon the symbol tables
and their contents, so it would be best to synthesise new entries as
soon as possible.  Also I would recommend changing the name from
foo.high_bound to something that makes it more obvious that this is a
GNU extension, eg foo.gnu_bp_high_bound.

Cheers
	Nick