> Am 23.12.2017 um 12:15 schrieb Richard Frith-Macdonald > <[email protected]>: >> On 23 Dec 2017, at 09:42, Richard Frith-Macdonald >> <[email protected]> wrote: >>> On 23 Dec 2017, at 09:32, Richard Frith-Macdonald >>> <[email protected]> wrote: >>> >>> >>> So the difference between the offsets in the runtime (correct) and the >>> compiler (wrong) was 16 bytes, with the runtime thinking the strruct size >>> was 32 and trhe compiler thinking it was 16; >>> >>> It seems the compiler is sizing the structure as if it contained a pointer >>> and two integers when it should actually be two pointers and three integers; >> >> No, my mistake, that's rubbish ... on a 64bit processor the fieldds only >> occupy 28 bytes, so the 32 byte offset is produced by alignment rules >> rounding up to a 16byte boundery. >> In that case, the offsets calculated by the compiler would be consistent >> with it ignoring the two __unsafe_unretained pointers. Perhaps that is a >> clue? > > It occurs to me that this is not anything like that simple :-( > > While the compiler is getting the offset to _gcontext wrong, it's still > getting the offset to the next ivar (_runLoopInfo) correct, so it can't just > be that it's calcularing the size of the struct incorrectly.
First a thank you to both Josh and Richard for gathering so much information on this issue and to Richard for the quick workaround. I hope this lets simple GNUstep applications run on systems with non-fragile ivars. But it is definitely not the final solution for the issue. I was hoping for David to provide more insight into the working of the non-fragile code. When ever a class gets loaded the compiler or the runtime have to provide information about the ivar layout and this seems to be off for the case where the class comes from a different compilation unit and has a structure within. (or at least this is what the current findings suggest) Most likely this information comes from the compiler, as the runtime itself seems to have the correct information. But according to Josh’s finding this information isn’t just hard coded, it seems to change even without changes to the compilation unit. The decision we now have to make is whether this unresolved issue is bad enough to block a GNUstep base release? I would suggest to go ahead with that, but if anybody has a different view I am fine with that. _______________________________________________ Discuss-gnustep mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnustep
