llvm dev - Jul 2011 - [LLVMdev] debug metadata incomplete for array arguments to functions?

Hello,

Consider the following two functions:

void foo(int* arg_ptr) {
...
}

void bar(int arg_arr[42]) {
...
}

------

According to the C standard, both arguments will be passed to the function
as pointers. However, in the debug information metadata generated in LLVM,
it appears that they are also equivalent.

More specifically, for both arg_ptr and arg_arr I get a derived type
descriptor with the DW_TAG_pointer_type tag, referencing 'int' as the
type
derived from, in argument 8 of the relevant MDNode. There is no way to know
arg_arr is in the user's eyes an array.

This reflects the compiler's view of things correctly, but is problematic
for a debugger. The debugger should know that arg_arr refers to a 42-element
array and isn't just a pointer into a buffer of unspecified length. This is
something the user would expect.
On the other hand, the debugger should also get the information that arg_arr
is actually a pointer, to be able to get to its values correctly.

Is there a way out?

Eli
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20110714/36fce55f/attachment.html>

On Jul 13, 2011, at 9:56 PM, Eli Bendersky wrote:
> Hello,
> 
> Consider the following two functions:
> 
> void foo(int* arg_ptr) {
> ...
> }
> 
> void bar(int arg_arr[42]) {
> ...
> }
> 
> ------
> 
> According to the C standard, both arguments will be passed to the function
as pointers. However, in the debug information metadata generated in LLVM, it
appears that they are also equivalent.
> 
> More specifically, for both arg_ptr and arg_arr I get a derived type
descriptor with the DW_TAG_pointer_type tag, referencing 'int' as the
type derived from, in argument 8 of the relevant MDNode. There is no way to know
arg_arr is in the user's eyes an array.
> 
> This reflects the compiler's view of things correctly, but is
problematic for a debugger. The debugger should know that arg_arr refers to a
42-element array and isn't just a pointer into a buffer of unspecified
length. This is something the user would expect.
> On the other hand, the debugger should also get the information that
arg_arr is actually a pointer, to be able to get to its values correctly.
> 
> Is there a way out?
The only way out is to figure out how to distinguish between these two in
front-end AST nodes while emitting LLVM IR. The part of front end that emits
debug info for an argument is seeing arg_arr as a pointer to int.

If you manually patch metadata in llvm IR then you'll get debug info as you
expect.
-
Devang

> > This reflects the compiler's view of things correctly, but is
problematic
> for a debugger. The debugger should know that arg_arr refers to a
42-element
> array and isn't just a pointer into a buffer of unspecified length.
This is
> something the user would expect.
> > On the other hand, the debugger should also get the information that
> arg_arr is actually a pointer, to be able to get to its values correctly.
> >
> > Is there a way out?
>
> The only way out is to figure out how to distinguish between these two in
> front-end AST nodes while emitting LLVM IR. The part of front end that
emits
> debug info for an argument is seeing arg_arr as a pointer to int.
>
> If you manually patch metadata in llvm IR then you'll get debug info as
you
> expect.
> -
>
Suppose one would start writing a patch to Clang to rectify this, how would
this information be encoded in the debug metadata, given the dual nature of
the arg_arr argument? Is there a mechanism to support it, or is an extension
required?

Thanks in advance
Eli
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20110715/be4db3d8/attachment.html>