GCC 3.4 / libobjc / mframe issues

[David Ayers]

Hello everyone,

so here's my current scoop on the situation:

GCC encodes method signatures (objc_act.c:encode_method_prototype).  In
the FSF gcc < 3.4 these signatures included platform stack layout
information.  I believe this layout information was intended for our
mframe code.  Yet as the new Testing/nsmethodsignature test shows, gcc
and mframe don't always agree even for i686-pc-gnu-linux.  Even worse,
for some archs (hppa/linux) gcc < 3.4 could generate negative offsets in
the signature that certain parts of libobjc would bail out on with
objc_error->abort().  As of gcc 3.4 the signature does not have the
detailed layout information anymore and instead only indicates the sizes
of the types.

GNUstep hasn't been effected by this change (except for warnings)
because the libffi/ffcall code ignores the layout information provided
by the signature and only uses the types as libffi/ffcall figure out the
layout themselves.  -base's ./configure will bailout if both libffi and
ffcall are not available when DO is supposed to be supported, so the
fallback for mframe is actually currently not in use.

Now if there is any interest in reenabling mframe based DO, someone
should consider opening a bug report with gcc to reenable the layout
information in the signatures.  But beware that then libobjc will also
need to be able to support negative offsets and the mframe code should
match what gcc's layout (assuming gcc's layout information is
correct(ed)).  i.e. Testing/nsmethodsignature would need more tests and
they actually should be somehow converted into gcc's test suite which
seems like it would then need to contain the correct(ed) mframe code.

Instead, my suggestion is to s/NSWarnLog/NSDebugLog/ the warnings about
changed method signatures in -base before the release as these will pop
up sooner or later when more people mix gcc < 3.4 and 3.4+ code.  It's
already pestering folks who's mframe code doesn't match gcc signature
(e.g. hppa/linux, SPARC/Solaris).  (Actually I know of no platform where
it always matches, it just so happens to match most signatures on common
archs.  But I'd be interested in archs that actually pass the
Testing/nsmethodsignature test I committed this week.)

For platforms that have negative offsets (where libobjc will bailout),
I'd suggest updating to gcc 3.4.x.

After the release we should consider removing the mframe code and
signature manipulation, as any effort put into resurrecting mframe for a
given arch is probably better invested in libffi/ffcall support for that
arch.

I'll be gone for a week, but I'd appreciate if someone could update
those warnings before the release is made (and maybe remove some/all of
the deprecated functions at least in GSObjCRuntime).

For the curious, here is an example signature set (I chose one where gcc
< 3.4 and mframe have always disagreed):

-(MyLargeStruct)largeStruct_id:(id)_id
                          char:(char)_char
                         short:(short)_short
                           int:(int)_int
                          long:(long)_long
                         float:(float)_float
                        double:(double)_double
                   largeStruct:(MyLargeStruct)_lstr
                   smallStruct:(MySmallStruct)_sstr;

i686-pc-gnu-linux:
< 3.4
runtime:{??=dd}61@4:8@12c16s20i24l28f32d36{??=dd}44{??=c}60
mframe :{??=dd}65@4:8@12c16s20i24l28f32d40{??=dd}48{??=c}64
3.4
runtime:{??=dd}57@0:4@8c12s16i20l24f28d32{??=dd}40{??=c}56
mframe :{??=dd}65@4:8@12c16s20i24l28f32d40{??=dd}48{??=c}64

hppa-unknown-gnu-linux:
< 3.4
runtime:{??=dd}0@+20:+16@+12c+11s-18i-24l-28f-32d-40{??=dd}-44{??=c}-45
mframe :{??=dd}45@4:8@12c13s14i16l20f24d32{??=dd}40{??=c}44
3.4
runtime:{??=dd}57@0:4@8c12s16i20l24f28d32{??=dd}40{??=c}56
mframe :{??=dd}45@4:8@12c13s14i16l20f24d32{??=dd}40(??=c}44

PS: I've replaced {_MyLargeStruct=dd}  with {??=dd} and
{_MySmallStruct=c} with {??=c} to insure that mail doesn't wrap.