This is the mail archive of the gcc-patches@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]
Other format: [Raw text]

RE?: [patch]: Sandro's GCJ on Darwin/i386 patc hes pt.2


> Which symbols would you use then? cpp -dM doesn't suggest more 
> meaningful predefined symbols.

ffi.h automatically defines @TARGET@.  You would need to define a new target, as it is done for X86_WIN32, and then turn:
 
#ifndef X86_WIN32 -> #ifdef X86
#ifdef X86_WIN32 -> #ifdef X86_WIN32
#if defined X86_WIN32 || defined __APPLE__ -> #ifndef X86
#ifdef __APPLE__ -> #ifdef X86_DARWIN

The idea is to separate the ABI from cc-defined symbols: in principle, nothing forbids from using an X86_WIN32 libffi on Darwin.  On the other hand, __APPLE__ has its use: all this
 
+#ifdef __APPLE__
+_ffi_closure_raw_SYSV:
+#else
ffi_closure_raw_SYSV:
+#endif

would keep __APPLE__ because it is not defining the ABI, but the characteristics of the system assembler.  It may be nice to change with a preprocessor macro though, like this:
 
/* Keep __APPLE__ here */
#ifdef __APPLE__
#define _sym(x) _##x
#else
#define _sym(x) x
#endif
 
...
    .globl _sym(ffi_closure_raw_SYSV)
...
_sym(ffi_closure_raw_SYSV):
 
Also, WRT to the sysv.S changes, what happens if a program was declaring a function to return char or short (excuse the possibly dumb question)?  Thanks for all your work!
 
Paolo
 


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