This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Better support for Objective-C



  In message <38BC5AC4.DB7539D9@doc.com>you write:
  > Hello, I hope in this long email to get more support/help/discussion
  > regarding Objective-C, GCC's long-lost little cousin to C and C++.
Objective-C certainly does not get the attention that C, C++ & Fortran
get.  Most of the GCC maintainers do not use Objective-C and thus we
rely almost exclusively on Ovidiu & friends to "do the right thing" for
Objective-C.


  > Currently this is accomplished in gcc using __builtin_apply and
  > related functions in gcc, which is broken on several
  > architectures. I've read all the gcc mailing-list emails about the
  > evils of __builtin_apply, so I'm fairly sure that there's nothing I
  > can do to get this fixed, so my current thoughts are to use a library
  > like libffi (or something similar). The problem with libffi currently
  > is it does not do frame decomposition (getting argument values from an
  > already constructed argument frame).
I'd be very leery of trying to integrate libffi or something like that into
GCC -- both from a technical and legal standpoint.


You're going to have a *very* difficult time implementing this -- it basically
means trying to shove all the code to perform function calls into the runtime
environment.   This is some of the hairiest code in GCC because there are so
many different sets of calling conventions it must support.
 
What about __builtin_apply is "broken on several architectures"?  Granted,
yes, it's a major pain to implement, but I thought we had it functional on
the main architectures (like how many people are doing Objective-C development
on the mn10200? :-)

Unfortunately, the example code didn't make any sense to me.  I'm neither an
Objective-C nor a C++ hacker.

  > There are several issues that need to be solved however. One issue
  > is saving the state of the registers and the relevant info on the stack
  > in a given memory location that's used by the invocation library. This
  > may involve some assembly language written for each target, although we
  > may also be able to take advantage of the __builtin_save_regs().
Basically __builtin_saveregs is designed to flush registers which contain
argument information to stack locations.  Often register parameters have
well defined stack homes and by flushing them to their stack homes it
becomes relatively easy to write varargs/stdarg support as all arguments are
contiguous on the stack.

  > Another issue is that we need to solve is a way to describe what is the
  > location of compound data in memory and/or registers and correspondingly
  > in the saved memory location I described above. This however should be a 
  > detail that is hidden from the programmer of the API anyway.
I wonder if this is similar to the RTTI support that was in the C++ front end.

jeff


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]