[LLVMdev] debug metadata incomplete for array arguments to functions?

[John McCall]

On Jul 17, 2011, at 4:43 AM, Frits van Bommel wrote:
> On 15 July 2011 06:35, Eli Bendersky <eliben at gmail.com> wrote:
>> 
>>>> 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?
> 
> Can't you just encode it as if it were a reference to a static array?
> In other words, generate debug info for
>  void bar(int arg_arr[42]) {
>  ...
>  }
> as if it said
>  void bar(int (&arg_arr)[42]) {
>  ...
>  }
> instead.

That would lead to &arg_arr having the wrong type and (furthermore)
would prevent users from calling the function with an array not of size 42.
You don't want to go down this road.

The interesting question here is whether there's any way to represent
the "written" type in DWARF.  If not, we could certainly introduce an
extension, and then hack various debuggers to support it, but I'm not
sure this problem really merits that.

John.