On Tue, 16 Apr 2002, Donn Terry wrote:
> Date: Tue, 16 Apr 2002 10:43:22 -0700
> From: Donn Terry <yyyyyy@xxxxxxxxxxxxx>
> To: Matt Seitz <yyyyyy@xxxxxxxxx>, yyyyyyyyyyyyyy@xxxxxxxxxxxxx
> Subject: [austin] RE: Return type of dlsym
> Resent-Date: 16 Apr 2002 17:44:38 -0000
> Resent-From: yyyyyyyyyyyyyy@xxxxxxxxxxxxx
> Resent-To: yyyyyyyyyyyyyy@xxxxxxxxxxxxx
>
> I'm not particularly disagreeing with anybody, but a couple of points:
>
> 1) The size of either type of pointer could be the larger. On a
> segment/offset machine,
> function pointers might have to be, say, 48 bits for a 16 bit segment
> and a 32 bit offset,
> but for data pointers a segment can be assumed and they need only be
> 32 bits.
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.
> On the other
> hand, "fat pointers" might be useful for data but not functions.
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. ;)
> 2) Even if pointers are the same size, again on a segment/offset
> architecture, the compiler
> may need to know which is which to scramble the bits appropriately.
> (E.g. 8+24 packing
> for function gets expanded to 16+32 (in the above 48 bit case).)
This divides into two possible implementations. In one implementation,
conversions between function and data pointers are simply bit copies.
So a data pointer object can transparently store and retrieve a
function pointer value, but does not actually point at the
function image. In this scenario, the dlsym function has to know what
kind of symbol it is dealing with, function or data, and prepare the
return value's bitwise representation accordingly.
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?) In this model,
when dlsym is dealing with a function symbol, it simply has to produce
a data pointer which points to the function image, so that the program
can convert that to a function pointer which refers to the function
image.
In neither model do you need special treatment of dlsym by the
compiler; the work can be done in dlsym so that the pointer conversion
performed by the program does the right thing.
--
Meta-CVS: solid version control tool with directory structure versioning.
http://users.footprints.net/~kaz/mcvs.html http://freshmeat.net/projects/mcvs
|