Re: problem with gnustep on OpenBSD sparc64

[David Chisnall]

On 6 Jul 2011, at 13:44, Sebastian Reitenbach wrote:

> running it in gdb, I see the following:

It helps me if you can tidy up the gdb traces a bit before sending them.  It's 
easy to miss important things in the middle of a load of list commands and 
frames in libc with no debugging info.

> Breakpoint 1, objc_sizeof_type (type=0x200c10 "[3[4i]]") at encoding2.c:319
> 319             sizeof_type(type, &size);

This is calling the real sizeof function, which calls itself recursively on 
subtypes.

> (gdb) print type
> $1 = 0x200c10 "[3[4i]]"
> (gdb) s
> sizeof_type (type=0x200c10 "[3[4i]]", size=0xfffffffffffdebd8) at 
> encoding2.c:152
> 152             type = objc_skip_type_qualifiers(type);

No type qualifiers on this, skip it.

> 0x0000000204d64c94 in objc_exception_throw () at encoding2.c:85

Well, that's wrong.  Looks like the debug info is mangled.  What did you 
compile libobjc2 with, and did you do a debug build?

> 85      static void parse_struct_or_union(const char **type, type_parser 
> callback, void *context, char endchar)

This is the generic visitor function that walks a structure or union type.  It 
can only be invoked via parse_struct() or parse_union(), and these are only 
invoked as a result of encountering { or ( in the input stream, so it shouldn't 
be there...  

> (gdb) s
> 0x0000000204d64c98      85      static void parse_struct_or_union(const char 
> **type, type_parser callback, void *context, char endchar)
> (gdb) s
> objc_skip_type_qualifiers (type=0x200c10 "[3[4i]]") at encoding2.c:20
> 20              while('\0' != *type && strchr(type_qualifiers, *type))
> (gdb) 

Ah, now we're back somewhere sensible...

> strchr (p=0x204e74c68 "rnNoORV", ch=91) at /usr/src/lib/libc/string/index.c:41
> 41      /usr/src/lib/libc/string/index.c: No such file or directory.
>        in /usr/src/lib/libc/string/index.c
> objc_skip_type_qualifiers (type=0x200c10 "[3[4i]]") at encoding2.c:20
> 20              while('\0' != *type && strchr(type_qualifiers, *type))
> (gdb) 
> 25      }
> (gdb) 

Okay, we've passed the (nonexistent) type qualifiers, now we're really parsing 
it.

> sizeof_type (type=0x200c10 "[3[4i]]", size=0xfffffffffffdebd8) at 
> encoding2.c:153
> 153             switch (*type)
> (gdb) 
> 196                             int element_count = parse_array(&t, 
> (type_parser)sizeof_type, &element_size);

First character is [, therefore this is an array type.  Parse it as an a array 
type.

> (gdb) print type
> $4 = 0x200c10 "[3[4i]]"

None of the input stream has been consumed yet.

> (gdb) s
> 193                             const char *t = type;
> (gdb) 
> 196                             int element_count = parse_array(&t, 
> (type_parser)sizeof_type, &element_size);
> (gdb) 
> 194                             int element_size = 0;

This will be set by the recursive call.

> (gdb) s
> 196                             int element_count = parse_array(&t, 
> (type_parser)sizeof_type, &element_size);
> (gdb) 
> parse_array (type=0xfffffffffffdeb08, callback=0x204d652a0 <sizeof_type>, 
> context=0xfffffffffffdeb00) at encoding2.c:77
> 77              (*type)++;
> (gdb) print type
> $5 = (const char **) 0xfffffffffffdeb08
> (gdb) print *type
> $6 = 0x200c10 "[3[4i]]"

In the array type.  The line after this, type will be "4[4i]]".  It's helpful 
if you print values after they've been modified...

> (gdb) s
> 78              int element_count = (int)strtol(*type, (char**)type, 10);

Array encodings start with the number of elements, parse it.

What was the result?

> (gdb) print *type
> $7 = 0x200c10 "[3[4i]]"

Well, that's wrong.  Might be incorrect debug info, or optimisation not 
actually committing the change until the end of the function.  Maybe add a 
printf() here?

> (gdb) s
> 75      {
> (gdb) print element_count
> No symbol "element_count" in current context.

Not so helpful - are you sure you did a debug build?

> (gdb) s
> 77              (*type)++;
> (gdb) 
> 78              int element_count = (int)strtol(*type, (char**)type, 10);

Optimisation stuff - reordered all of these expressions.

> (gdb) print type
> $8 = (const char **) 0xfffffffffffdeb08
> (gdb) print *type
> $9 = 0x200c10 "[3[4i]]"
> (gdb) s
> strtol (nptr=0x200c11 "3[4i]]", endptr=0xfffffffffffdeb08, base=10) at 
> ctype.h:133
> 133             return (c == -1 ? 0 : ((_ctype_ + 1)[(unsigned char)c] & _S));

Here we go.  *type is the correct value here.  strtol should return 3 (did it?) 
and set *type to "[4i]]" (did it?)

> (gdb) 
> parse_array (type=0xfffffffffffdeb08, callback=0x204d652a0 <sizeof_type>, 
> context=0xfffffffffffdeb00) at encoding2.c:79
> 79              *type = callback(*type, context);

Now we're calling sizeof_type() again, on the array element type.

Did you skip over that?  That should be parsing the element type "[4i]" as an 
array of 4 integers and returning the size.  

Unfortunately, you seem to have stepped over the bit that actually calculated 
the array element size, so I can't tell if it's doing anything sensible.

David

-- Sent from my Apple II