Re: problem with gnustep on OpenBSD sparc64

[David Chisnall]

On 6 Jul 2011, at 19:35, Sebastian Reitenbach wrote:

> 
> On Wednesday, July 6, 2011 19:47 CEST, David Chisnall <theraven@sucs.org> 
> wrote: 
> 
>> The stuff around skip type qualifiers is irrelevant - there aren't any, this 
>> function is a no-op in this case, ignore it.
>> 
>> 
>> On 6 Jul 2011, at 18:38, Sebastian Reitenbach wrote:
>> 
>>> I added some more fprintf's to the functions that are involved, hope the 
>>> output also helps:
>>> $ ./a.out      
>>> parse_array: element_count: 3, type: [4i]]
>>> parse_array: element_count: 4, type: i]]
>> 
>> 
>> Well, this shows that it is finding the correct number of elements for each 
>> array.  So, there are two places where it could be going wrong:
>> 
>> - Calculating the size of int (line 161)
> I added two fprintfs before and after that line
> 
>> - Combining the size of the elements with the count (line 197)
> and another fprintf before that line, after the parse_array:
> 
> and another 2 fprintf in parse_array, before and after calling the callback.
> 
> $ ./a.out  
> parse_array: type: [4i]]
> parse_array: type: i]]
> ^^^ those lines are in parse_array before the callback

That's good.  The elements of the outer array are of type [4i], the elements of 
the inner array are of type i.

> sizeof_type: sizeof(typeName): 4
> sizeof_type: size: 32
> ^^^ those lines are around line 161

int is 32 bits, that looks sensible.  The size of the inner array is 32 bits 
(note: we work with bits internally because this code needs to handle 
bitfields, which are ugly and evil).

> parse_array: type: ]]
> ^^^ fprintf after calling callback

Okay, now it's coming back up.  

> element_size: 0, element_count: 4
> ^^^ this line is before line 197

Hmm, why is element_size 0 here?  It was 32 just now - somehow it got reset to 
0.  This looks like the bug. element_size should have been set to 32 on line 
161.  Can you check that the address of element_size passed in here is the same 
as the address of size on line 161?

> parse_array: type: ]
> ^^^ fprintf after calling callback
> 
> element_size: 0, element_count: 3
> ^^^ this line is before line 197
> 
> as far as I can see in line 194:
> 
>                        int element_size = 0;
>                        // FIXME: aligned size
>                        int element_count = parse_array(&t, 
> (type_parser)sizeof_type, &element_size);

That FIXME should go in the bin, it was fixed ages ago, so ignore that.

> element_size goes into parse_array with a value of 0, and it also gives 
> itself as the callback function, then in parse_array I see:
> 
> static int parse_array(const char **type, type_parser callback, void *context)
> {
>        // skip [
>        (*type)++;
>        int element_count = (int)strtol(*type, (char**)type, 10);
>        *type = callback(*type, context);
>        // skip ]
>        (*type)++;
>        return element_count;
> }

This is a generic visitor function for walking arrays.  There are similar ones 
for walking structures and unions.  All of the objc_{something}of_type() 
functions are implemented in terms of a simple case function that handles the 
primitive types and calls these to recursively visit complex types.

> I don't get it what the code is doing in the #define APPLY_TYPE, where the 
> switch statement checks for the case: i ????
> That #define is kind of puzzling me. It seems to detect the size of the "i" 
> correctly, sizeof(typeName): 4, but it somewhere gets lost in the 
> iterations...

Yup, that's just applying the macro defining the case for every one of the 
valid primitive type encodings.  The APPLY_TYPE() macro is instantiated once 
for each primitive type encoding by type_encoding_cases.h.  For the int case, 
it matches the case 'i', rounds up size to the alignment required bit int, and 
then adds the size of integer (the first bit is only relevant when visiting 
structures - we need to make sure that we the field in the right place).

> And I'm kind of lost too

Well, it seems to be getting lost returning the size up the stack...

David

--
This email complies with ISO 3103