Re: problem with gnustep on OpenBSD sparc64

[David Chisnall]

On 6 Jul 2011, at 11:45, Sebastian Reitenbach wrote:

> 
> On Wednesday, July 6, 2011 12:14 CEST, David Chisnall <theraven@sucs.org> 
> wrote: 
> 
>> On 6 Jul 2011, at 11:02, David Chisnall wrote:
>> 
>>> On 6 Jul 2011, at 10:55, Sebastian Reitenbach wrote:
>>> 
>>>> Error: Instance variables in NSTextTable overlap superclass NSTextBlock.  
>>>> Offset of first instance variable, _layoutAlgorithm, is 196.  Last 
>>>> instance variable in superclass, _widthType, ends at offset 148.  This 
>>>> probably means that you are subclassing aclass from a library, which has 
>>>> changed in a binary-incompatibleway.
>>> 
>>> I think this is a bug in how libobjc2 is calculating sizes.  The last ivar 
>>> of NSTextBlock is an array of arrays, and my guess is that the runtime 
>>> thinks that it is smaller than it is.
>> 
>> Having said that, I can't actually reproduce this, and objc_sizeof_type() 
>> seems to return the same size as sizeof() for me when I copy the last ivar 
>> into a file and test it.  
>> 
>> Both of these numbers look a bit wrong.  For me, class_getInstanceSize() 
>> returns 172 for NSTextBlock, so unless you've got some very strict alignment 
>> requirements 196 looks too large.  The header doesn't seem to have been 
>> modified for a long time, so I'm not sure how it could happen.
> IIRC, the alignment is fairly strict on sparc64, but I'm not an expert ;)

Hmm, 196 might be correct for SPARC64.

>> Can you tell me from the debugger:
>> 
>> - What the type encoding of the last ivar is
>> - What the calculated size of the last ivar is
> Do you can give me a hint how I can figure this out? At which frame stack I 
> should potentially go, or where to set a breakpoint, and what to enter?

The stack frame that calls abort (objc_compute_ivar_offsets()).  It has a local 
variable called ivar, which is the last ivar in the superclass.  It uses this 
to calculate the size from the type.

David

-- Sent from my IBM 1620