public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
* C99 variable length arrays
@ 2006-01-26 13:49 Igor Khavkine
  2006-01-26 15:08 ` Daniel Jacobowitz
  0 siblings, 1 reply; 5+ messages in thread
From: Igor Khavkine @ 2006-01-26 13:49 UTC (permalink / raw)
  To: gdb

[First posted to bug-gdb@gnu.org, but that list looks rather dead.]

I'm using GDB to debug some code that uses local variable length
arrays. This feature is available for C as of the C99 standard. GCC
has support for it.

Sadly, GDB doesn't seem to be smart enough to figure out the size of
the arrays at run time. This leads to things like 'print array[1][2]'
at the GDB prompt not printing the same value as would 'printf("%g\n",
array[1][2])' in the code. This is a problem for multidimensional
arrays especially. Needless to say, this makes the code more difficult
to debug.

The GDB bug database has PR 1796 [1] dedicated to this exact issue.
However, the report is over a year old and I couldn't find any work
done on it. If this problem is easy to fix for some GDB hacker, I hope
this email brings it to their attention. If not, and no-one else has
the time to look into it, I'm getting sufficiently annoyed by the bug
to try my own hand at fixing it. Unfortunately, I'm completely
unfamiliar with the internals of GDB and am not sure where to look in
the GDB source code or the debugging info generated by GCC. Any
pointers (no pun intended :-) would be appreciated.

Thanks in advance.

Igor

[1] http://sources.redhat.com/cgi-bin/gnatsweb.pl?cmd=view&pr=1796

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: C99 variable length arrays
  2006-01-26 13:49 C99 variable length arrays Igor Khavkine
@ 2006-01-26 15:08 ` Daniel Jacobowitz
  2006-01-26 23:33   ` Igor Khavkine
  0 siblings, 1 reply; 5+ messages in thread
From: Daniel Jacobowitz @ 2006-01-26 15:08 UTC (permalink / raw)
  To: Igor Khavkine; +Cc: gdb

On Thu, Jan 26, 2006 at 08:41:46AM -0500, Igor Khavkine wrote:
> [First posted to bug-gdb@gnu.org, but that list looks rather dead.]
> 
> I'm using GDB to debug some code that uses local variable length
> arrays. This feature is available for C as of the C99 standard. GCC
> has support for it.
> 
> Sadly, GDB doesn't seem to be smart enough to figure out the size of
> the arrays at run time. This leads to things like 'print array[1][2]'
> at the GDB prompt not printing the same value as would 'printf("%g\n",
> array[1][2])' in the code. This is a problem for multidimensional
> arrays especially. Needless to say, this makes the code more difficult
> to debug.

The first thing to do is to write a small testcase, and post the
testcase along with the debugging output that your GCC generates
for it.

-- 
Daniel Jacobowitz
CodeSourcery

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: C99 variable length arrays
  2006-01-26 15:08 ` Daniel Jacobowitz
@ 2006-01-26 23:33   ` Igor Khavkine
  2006-01-27  0:02     ` Daniel Jacobowitz
  0 siblings, 1 reply; 5+ messages in thread
From: Igor Khavkine @ 2006-01-26 23:33 UTC (permalink / raw)
  To: gdb, Daniel Jacobowitz

On 1/26/06, Daniel Jacobowitz <drow@false.org> wrote:
> On Thu, Jan 26, 2006 at 08:41:46AM -0500, Igor Khavkine wrote:

> > I'm using GDB to debug some code that uses local variable length
> > arrays. This feature is available for C as of the C99 standard. GCC
> > has support for it.
> >
> > Sadly, GDB doesn't seem to be smart enough to figure out the size of
> > the arrays at run time. This leads to things like 'print array[1][2]'
> > at the GDB prompt not printing the same value as would 'printf("%g\n",
> > array[1][2])' in the code. This is a problem for multidimensional
> > arrays especially. Needless to say, this makes the code more difficult
> > to debug.
>
> The first thing to do is to write a small testcase, and post the
> testcase along with the debugging output that your GCC generates
> for it.

There is a test case already in the GDB bug database (PR 1796, as I
mentioned in my first message). What kind of debugging output should I
post? Is there an option to make gcc dump the debugging info in human
readable form?

Thanks in advance.

Igor

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: C99 variable length arrays
  2006-01-26 23:33   ` Igor Khavkine
@ 2006-01-27  0:02     ` Daniel Jacobowitz
  2006-01-27  8:15       ` Igor Khavkine
  0 siblings, 1 reply; 5+ messages in thread
From: Daniel Jacobowitz @ 2006-01-27  0:02 UTC (permalink / raw)
  To: Igor Khavkine; +Cc: gdb

On Thu, Jan 26, 2006 at 06:30:56PM -0500, Igor Khavkine wrote:
> On 1/26/06, Daniel Jacobowitz <drow@false.org> wrote:
> > On Thu, Jan 26, 2006 at 08:41:46AM -0500, Igor Khavkine wrote:
> 
> > > I'm using GDB to debug some code that uses local variable length
> > > arrays. This feature is available for C as of the C99 standard. GCC
> > > has support for it.
> > >
> > > Sadly, GDB doesn't seem to be smart enough to figure out the size of
> > > the arrays at run time. This leads to things like 'print array[1][2]'
> > > at the GDB prompt not printing the same value as would 'printf("%g\n",
> > > array[1][2])' in the code. This is a problem for multidimensional
> > > arrays especially. Needless to say, this makes the code more difficult
> > > to debug.
> >
> > The first thing to do is to write a small testcase, and post the
> > testcase along with the debugging output that your GCC generates
> > for it.
> 
> There is a test case already in the GDB bug database (PR 1796, as I
> mentioned in my first message). What kind of debugging output should I
> post? Is there an option to make gcc dump the debugging info in human
> readable form?

Not really - but you can run readelf -wi on the resulting object file.
I recommend you do this after linking to make sure relocations are
resolved.

-- 
Daniel Jacobowitz
CodeSourcery

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: C99 variable length arrays
  2006-01-27  0:02     ` Daniel Jacobowitz
@ 2006-01-27  8:15       ` Igor Khavkine
  0 siblings, 0 replies; 5+ messages in thread
From: Igor Khavkine @ 2006-01-27  8:15 UTC (permalink / raw)
  To: gdb, Daniel Jacobowitz

[-- Attachment #1: Type: text/plain, Size: 1474 bytes --]

On 1/26/06, Daniel Jacobowitz <drow@false.org> wrote:
> On Thu, Jan 26, 2006 at 06:30:56PM -0500, Igor Khavkine wrote:
> > On 1/26/06, Daniel Jacobowitz <drow@false.org> wrote:

> > > The first thing to do is to write a small testcase, and post the
> > > testcase along with the debugging output that your GCC generates
> > > for it.
> >
> > There is a test case already in the GDB bug database (PR 1796, as I
> > mentioned in my first message). What kind of debugging output should I
> > post? Is there an option to make gcc dump the debugging info in human
> > readable form?
>
> Not really - but you can run readelf -wi on the resulting object file.
> I recommend you do this after linking to make sure relocations are
> resolved.

OK. I'm attaching a small test case, vla-bug.c. I compiled the object
with `gcc -g -c vla-bug.c' and the executable with `gcc -g -o vla-bug
vla-bug.c'. I then ran `readelf -wi' on the .o and the executable. I'm
attaching all the relevant files.

Note that I call the function test() with argument 3. This means that
the local variable length array will have size 3. However, when run
under GDB, GDB will think the array is only of size 2 (that's the size
it always seems to assume for VLA's). Unfortunately, I can glimpse
next to nothing from the readelf output. Can you tell whether GCC puts
enough debugging info into the compiled code for GDB to get the size
right at runtime?

Thanks in advance.

Igor

[-- Attachment #2: vla-bug.c --]
[-- Type: text/x-csrc, Size: 91 bytes --]

void test (int x)
{
	int arr[x];
	arr[0] = 1;
}

int main (void)
{
	test (3);
	return 0;
}

[-- Attachment #3: vla-bug.o.elf --]
[-- Type: application/octet-stream, Size: 2334 bytes --]

The section .debug_info contains:

  Compilation Unit @ 0:
   Length:        215
   Version:       2
   Abbrev Offset: 0
   Pointer Size:  4
 <0><b>: Abbrev Number: 1 (DW_TAG_compile_unit)
     DW_AT_stmt_list   : 0	
     DW_AT_high_pc     : 0x4c	
     DW_AT_low_pc      : 0	
     DW_AT_name        : vla-bug.c	
     DW_AT_comp_dir    : /home/igor/c/gdb-bug	
     DW_AT_producer    : GNU C 3.3.5 (Debian 1:3.3.5-13)	
     DW_AT_language    : 1	(ANSI C)
 <1><58>: Abbrev Number: 2 (DW_TAG_subprogram)
     DW_AT_sibling     : <93>	
     DW_AT_external    : 1	
     DW_AT_name        : test	
     DW_AT_decl_file   : 1	
     DW_AT_decl_line   : 2	
     DW_AT_prototyped  : 1	
     DW_AT_low_pc      : 0	
     DW_AT_high_pc     : 0x29	
     DW_AT_frame_base  : 1 byte block: 55 	(DW_OP_reg5)
 <2><70>: Abbrev Number: 3 (DW_TAG_formal_parameter)
     DW_AT_name        : x	
     DW_AT_decl_file   : 1	
     DW_AT_decl_line   : 1	
     DW_AT_type        : <93>	
     DW_AT_location    : 2 byte block: 91 8 	(DW_OP_fbreg: 8)
 <2><7c>: Abbrev Number: 4 (DW_TAG_variable)
     DW_AT_artificial  : 1	
     DW_AT_type        : <bd>	
     DW_AT_location    : 1 byte block: 50 	(DW_OP_reg0)
 <2><84>: Abbrev Number: 5 (DW_TAG_variable)
     DW_AT_name        : arr	
     DW_AT_decl_file   : 1	
     DW_AT_decl_line   : 3	
     DW_AT_type        : <9a>	
     DW_AT_location    : 2 byte block: 70 0 	(DW_OP_breg0: 0)
 <1><93>: Abbrev Number: 6 (DW_TAG_base_type)
     DW_AT_name        : int	
     DW_AT_byte_size   : 4	
     DW_AT_encoding    : 5	(signed)
 <1><9a>: Abbrev Number: 7 (DW_TAG_array_type)
     DW_AT_sibling     : <ad>	
     DW_AT_type        : <93>	
 <2><a3>: Abbrev Number: 8 (DW_TAG_subrange_type)
     DW_AT_type        : <ad>	
     DW_AT_upper_bound : <7c>	
 <1><ad>: Abbrev Number: 6 (DW_TAG_base_type)
     DW_AT_name        : unsigned int	
     DW_AT_byte_size   : 4	
     DW_AT_encoding    : 7	(unsigned)
 <1><bd>: Abbrev Number: 9 (DW_TAG_const_type)
     DW_AT_type        : <93>	
 <1><c2>: Abbrev Number: 10 (DW_TAG_subprogram)
     DW_AT_external    : 1	
     DW_AT_name        : main	
     DW_AT_decl_file   : 1	
     DW_AT_decl_line   : 8	
     DW_AT_prototyped  : 1	
     DW_AT_type        : <93>	
     DW_AT_low_pc      : 0x29	
     DW_AT_high_pc     : 0x4c	
     DW_AT_frame_base  : 1 byte block: 55 	(DW_OP_reg5)


[-- Attachment #4: vla-bug.elf.gz --]
[-- Type: application/x-gzip, Size: 5196 bytes --]

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2006-01-27  0:47 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2006-01-26 13:49 C99 variable length arrays Igor Khavkine
2006-01-26 15:08 ` Daniel Jacobowitz
2006-01-26 23:33   ` Igor Khavkine
2006-01-27  0:02     ` Daniel Jacobowitz
2006-01-27  8:15       ` Igor Khavkine

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).