Re: Variable length arrays in debugger
Re: Variable length arrays in debugger
- Subject: Re: Variable length arrays in debugger
- From: Jim Ingham <email@hidden>
- Date: Wed, 1 Oct 2008 14:44:13 -0700
My simple example works when I rename the source file to .m. So it
isn't the ObjC front-end that's at fault.
When gcc emits stabs, it omits all reference to variable length
arrays. That's a never to be fixed bug in gcc 'cause nobody cares
that much about stabs anymore...
But in DWARF, the debug information should know the array's type. If
you can boil your case down to an example you don't mind putting in a
Radar, please do so and file a bug on this. Probably end up being
some bug in the compiler, not the debugger...
Thanks,
Jim
On Oct 1, 2008, at 12:56 PM, Tverdokhleb Andrey wrote:
Jim,
ptype in gdb doesn't work for this variable in my code (it's
Objective-C) - says "No symbol "array" in current context". Works
fine for all other local variables defined in the same scope though.
So apparently even size doesn't matter here ;) It's just not
preserved in debug info along with other locals (I tried stubs and
DWARF).
Andrey
On Oct 1, 2008, at 12:42 , Jim Ingham wrote:
I see this:
(gdb) list main
1 #include <stdio.h>
2
3 int
4 main (int argc, char **argv)
5 {
6 int array[argc];
7 int i;
8
9 for (i = 0; i < argc; i++)
10 {
(gdb)
11 array[i] = argv[i][0];
12 printf ("First char is %d\n", array[i]);
13 }
14
15 return 0;
16 }
(gdb) break 15
Breakpoint 1 at 0x1f7a: file variable.c, line 15.
(gdb) run foo bar baz
Starting program: /private/tmp/a.out foo bar baz
Reading symbols for shared libraries ++. done
First char is 47
First char is 102
First char is 98
First char is 98
Breakpoint 1, main (argc=4, argv=0xbffff2a8) at variable.c:15
15 return 0;
(gdb) ptype array
type = int [0]
(gdb) print array
$1 = 0xbffff240
(gdb) print array[0]
$2 = 47
(gdb) print array[1]
$3 = 102
(gdb) print *array@argc
$4 = {47, 102, 98, 98}
Do you see something different? gdb gets told this is an int array
of size 0. So if you ask Xcode to print the array, it can't since
it doesn't think it has any size. Xcode's error reporting for
variable evaluation is a bit weak, and it says "out of scope" for
pretty much any error. It should probably print "I don't know how
big this is" or something... But that seems like a minor bug since
even if you fixed this it still wouldn't be able to print the array.
Anyway, gdb knows the array type, and if you tell it to print
certain elements, or to print it as an array with the "@" syntax -
provided you know the size - that works fine. But only YOU know
how big it is, Xcode has no way to know this programmatically.
Are you seeing something different?
Jim
On Oct 1, 2008, at 12:16 PM, Tverdokhleb Andrey wrote:
Jim,
On Oct 1, 2008, at 11:41 , Jim Ingham wrote:
gcc doesn't emit any debug information that tells the size of
variable length arrays. If you think about it a bit, it would be
kind of hard to express, for instance you could do:
void
foo (int input)
{
int size
int array[size];
size += input;
// Now how do I figure out what the size of "array" is?
}
It's irrelevant what size it has as long as type is known. They
deal with this all the time when resolve pointers to heap
allocated arrays in debugger views - just display it as an
'unlimited' array.
&array also has to be available. Showing it as 'out of scope' is a
plain bug in my opinion and doesn't look like a tough one so far.
Andrey
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden