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: Thu, 31 Aug 2000 15:58:49 -0700
- CC: binutils at sources dot 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