[K42-discussion] c++ -> c calling conventions and assembly

[Bryan S Rosenburg]

Patrick Bridges wrote on 10/03/2006 08:57:31 PM:
> > As far as I can tell, this makes it impossible to call the function 
> > from
> > assembly. The only solution I see is to create a c wrapper for each of
> > these functions -- a real c wrapper -- but that seems like it would 
> > add
> > an undesirable amount of complexity. Ideas?
> 
> Could we just change the call from assembly to load an address from 
> the associated data section and do an indirect jump to it, if that's 
> the linkage that's required?

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.

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?

- Bryan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/k42-discussion/attachments/20061004/23eff706/attachment.htm>