Kaz Kylheku said:
[...]
> In this model, the void * (and, consequently, char *) pointers can be
> 48 bits wide so that they can transparently record a function pointer
> value. Other data pointers can be represented in 32 bits.
[...]
> If data pointers are fatter than function ones, then there is no dlsym
> problem, since a fatter thing can transparently record and retrieve the
> representation of a skinnier thing. ;)
In both cases what you actually mean is "have enough bits to hold the
representation". There still may be issues.
For example, the hardware may require that all void * values have a valid
segment+offset structure, with hardware traps when they don't. Working
around this for function pointers may involve unacceptable tradeoffs.
Would it be acceptable if dlsym could return the same value for a given
data symbol and a (different) function symbol ?
> The other possible implementation is one which actually changes the
> value representation when a function pointer is converted to a data
> pointer and vice versa. In this implementation, when a function pointer
> is converted to a data pointer, that data pointer actually does point
> at the function image, albeit using its own encoding scheme. (Otherwise
> what would be the point of the representation change?)
All of which will require significant compiler support to fix. This isn't
going to be trivial.
> In neither model do you need special treatment of dlsym by the
> compiler;
But you *do* need special treatment of void * <-> function pointer
conversions. Special treatment added *ONLY* for dlsym.
--
Clive D.W. Feather | Work: <yyyyy@xxxxxxxxx> | Tel: +44 20 8371 1138
Internet Expert | Home: <yyyyy@xxxxxxxxxx> | Fax: +44 870 051 9937
Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646
Thus plc | | NOTE: fax number change
|