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

[Nick Clifton <nickc at redhat dot com>]

Hi Greg,

: >     With this scheme the compiler would generate code like this:
: > 
: >        if (ptr > _high_bound (foo))
: >          bound_check_abort ();
: 
: I understand that this is probably pseudo code, since you can't really
: mean that _high_bound is a function.

Yes.

: FYI, this could be expressed in concrete code like so:
: 
: 	if (ptr >= __ptrhigh &foo)
: 	  bound_check_abort ();

Ahh, thnaks.  My pseudo coding skills are not what they once were. :-)

: >        .word  _high_bound (foo)
: 
: This looks as though you're allocating initialized data with the value
: of the high bound.  That shouldn't be necessary.

Why not - you need the value somewhere, so that it can be loaded into
a register and then used in a comparison.  (This assumes that it is
not possible to place the value directly into an instruction, which is
certainly true of a lot of instruction sets).

: >     Where _high_bound() is an assembler pseudo op to generate a
: >     R_BFD_HIGH_BOUND reloc for the named symbol.
: 
: Cool.  Is there precedent for this syntax?  The gas manual lists
: only line-oriented `.<op>' style psuedos.

Some ports do make use of this kind of syntax.  The MIPS and v850 are
examples.  The define pseudo ops called _hi() and _lo() to get the top
and bottom 16 bits of a 32 bit value, since these instruction sets do
not have a single instruction to load a 32 bit value directly into a
register.

One other point, in cas eit was not clear - I just invented the name
R_BFD_HIGH_BOUND as an example for what this reloc could be called.

: >     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.
: 
: 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.  OK?

OK with me.

Cheers
	Nick