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

[Livio Soares]

  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