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

[Eli Bendersky]

On Fri, Jul 15, 2011 at 11:27, Renato Golin <renato.golin at arm.com> wrote:

> On 15 July 2011 05:35, Eli Bendersky <eliben at gmail.com> wrote:
> > 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?
>
> Hi Eli,
>
> The first thing is to make sure it actually makes any difference. I'd
> get an IR that is valid and can be debugged (but prints the wrong
> declaration) and start by changing manually the metadata in the IR
> until it achieves what you want (to work AND print the correct
> declaration). Only then I'd start changing Clang...
>
> Dwarf is too generic and debuggers' support is too ad-hoc for one to
> say "correct implementation". I wouldn't assume anything before seeing
> it working on a number of debuggers. Dwarf can be syntactically
> correct and not be understood by some debuggers, but it can't ever be
> syntactically incorrect, which I gather from your comment that it's
> not in your case.
>
> You can also see what other tool-chains generate from your example. It
> may be the quickest path to get the right answer.
>

Renato, I'm not sure I understand what you mean.
IIUC, debug metadata in IR is the source from which DWARF is eventually
generated. If the debug metatada format doesn't support such a construct
(providing an alternative "type view" for a pointer), there isn't much that
can be done to get this code-gened into DWARF. So I asked Devang if to his
knowledge such a mechanism exists in the current debug metadata format, or
could be implemented with existing fields.

If yes, all I need is to improve debug metadata generation from clang for
this case.

If not, then perhaps an extension to the debug metadata format is required
to support this.

Do you imply that DWARF doesn't support this construct, so the "cause is
lost"?

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