<br><tt><font size=2>Patrick Bridges wrote on 10/03/2006 08:57:31 PM:<br>
> > As far as I can tell, this makes it impossible to call the function
<br>
> > from<br>
> > assembly. The only solution I see is to create a c wrapper for
each of<br>
> > these functions -- a real c wrapper -- but that seems like it
would <br>
> > add<br>
> > an undesirable amount of complexity. Ideas?<br>
> <br>
> Could we just change the call from assembly to load an address from
<br>
> the associated data section and do an indirect jump to it, if that's
<br>
> the linkage that's required?<br>
</font></tt>
<br><tt><font size=2>We certainly could change the assembly code to call
through function descriptors, but what a waste of cycles and cache lines!
I sure hope you can find a way to make the text address available
to the assembly code.</font></tt>
<br>
<br><tt><font size=2>This discussion is starting to intersect my "day"
job (implementing a "library OS" to support a JVM running on
a bare hypervisor partition). We recently discovered an outright
compilation bug when using gcc 4.0.1 to compile C++ code. I learned
that g++4.0.1 generates assembler that "calls" the function descriptor
for a function rather than the text address for the function. Somehow
the assembler and linker do the right thing for what looks like a branch
into the data segment, but in one particular case a bad relocation entry
is generated for a call to a static function, and the final code ends up
branching to the wrong place. I bring this up, because the change
to call the function descriptor rather than the text address may explain
why the compiler is no longer exporting a symbol for the text address.
But this seems like a serious and unnecessary omission. Is
there a compiler option of some sort to get back the old behavior?</font></tt>
<br>
<br><tt><font size=2>- Bryan</font></tt>
<br>
<br>