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

[Bryan S Rosenburg]

Thanks, Livio.  That sounds like the option I was hoping for.  Donour, can 
you try it out?

- Bryan




Livio Soares <livio at eecg.toronto.edu> 
Sent by: k42-discussion-bounces+rosnbrg=us.ibm.com at ozlabs.org
10/04/2006 01:14 PM
Please respond to
Discussion about K42 <k42-discussion at ozlabs.org>


To
Discussion about K42 <k42-discussion at ozlabs.org>
cc

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






  Hi all,

Bryan S Rosenburg writes:
> 
> 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. 

  I completely agree with you. If  we have the symbol locations at compile 
time,
I don't see a benefit for the extra indirection overhead (it would cost at 
least
one cache-line due to a load, and  a branch whose target which looks 
pretty hard
to predict).  And it doesn't  look like K42  will need the flexibility  of 
being
able to overwrite/relocate code that is declared as 'extern "C"'. 

> 
> 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?

  I    browsed    through    GCC-4.1     code    for    a    bit,    and  
from
gcc/config/rs6000/ppc-asm.h, I see:

/*
 * Macros to begin and end a function written in assembler.  If 
-mcall-aixdesc
 * or -mcall-nt, create a function descriptor with the given name, and 
create
 * the real function with one or two leading periods respectively. 
 */

  So, trying it out with Donour's test program, I get:

$ g++-4.1 -mcall-aixdesc -c test.C
$ nm test.o
0000000000000000 T .foobar
                 U .printf
0000000000000000 V DW.ref.__gxx_personality_v0
                 U __gxx_personality_v0
0000000000000000 D foobar

  Interestingly, there is  still a 'foobar' symbol in the  data segment. I 
don't
know  what is  it's purpose.  Calling "foobar()"  from a  C++ function 
seems to
directly use the .foobar symbol addres. 

  Anyways,  I  have  no idea  if  there  are  further ramifications  when 
using
-mcall-aixdesc.  I  have not tried compiling K42  with it. As far  as my 
"rgrep"
went into the GCC-4.1 source  code, gcc/config/rs6000/ppc-asm.h is the 
only file
modified by -mcall-aixdesc. 

  In the  end, if -mcall-aixdesc breaks  K42 (or doesn't solve  the 
problem), it
doesn't seem that it would be extremely hard to change the ppc-asm.h to 
spit out
function descriptors in the TOC so that they are directly accessible as a 
symbol
in the text segment.

  Hope this helps,

                                                                 Livio
_______________________________________________
K42-discussion mailing list
K42-discussion at ozlabs.org
https://ozlabs.org/mailman/listinfo/k42-discussion

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ozlabs.org/pipermail/k42-discussion/attachments/20061004/352b07c6/attachment.htm