This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: Advice needed on when to synthesize <sym>.high_bound in ld
- To: greg at mcgary dot org
- Subject: Re: Advice needed on when to synthesize <sym>.high_bound in ld
- From: Nick Clifton <nickc at redhat dot com>
- Date: Wed, 30 Aug 2000 16:44:13 -0700
- CC: binutils at sources dot 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