[RFC] Debuginfo: Add default value support for subprogram arguments

[Frédéric Riss]

> On 14 Aug 2014, at 19:22, David Blaikie <dblaikie at gmail.com> wrote:
> 
> On Thu, Aug 14, 2014 at 9:17 AM, Frédéric Riss <friss at apple.com <mailto:friss at apple.com>> wrote:
>> As you can see, this text limits us to emitting information about default
>> values being:
>> - simple constants (DW_FORM_data*)
>> - global variable (DW_FORM_ref*)
>> - calls to functions without arguments (DW_FORM_ref*)
>> 
>> I tried to go a bit further and implement a more complete solution that
>> adds:
>> - any link time constant (DW_FORM_block*): in this form, the block of data
>> represents the default value as it would be stored in the target memory
> 
> How does this differ from the "simple constant" case above? What sort
> of constants can't be expressed with DW_FORM_data* that can be
> expressed with DW_FORM_block*?

I had always thought that DW_FORM_data* represents only one value, but reading the description again, it can encode arbitrary data. The downside of it is that data that is over 8 bytes must be LEB128 encoded. And that just won’t work for some things, relocatable addresses come to mind. But yes, simple things that I currently put in DW_FORM_blocks could be put in DW_FORM_data* (e.g. _Complex float values), and still be standard conforming.

[…]
> Currently clang has no smarts for producing debug info for function
> declarations on demand (and replacing them with definitions when a
> definition appears later) - except for the special case of
> declarations of member functions.

Yeah, I’ve seen the SPCache that is handled differently. Would that be the right example to study to improve the DeclCache? Maybe we could even merge these?

[…]
>> - Relocatable address:
>> 
>> const char *me = “fred”;
>> void foo(const char *str = me);
>> 
>> the initialiser is a global address (function or data). The generated
>> metadata is alright. If I have clang dump assembly, it looks fine. However,
>> if I have clang emit the object file directly, it fails to relocate the
>> address of the initialiser in the debug information. The ObjectStreamer adds
>> fixups for the entries, but then nothing gets relocated. Any hints on how to
>> debug that kind of failure?
> 
> Harder for me to guess - you've mentioned the assembly looks fine, but
> have you tried assembling that assembly? Is the resulting object file
> correct? If so, you should be able to observe this as a difference
> between compiling with and without -fno-integrated-assembler.

The option is called -no-integrated-os, thanks for the tip! Unfortunately, I think it’s not supported on my platform, thus I can test that. I’m pretty confident that the assembly is correct though.

> If you observe a difference in behavior between the integrated and
> non-integrated assembler, then it's probably worth just exploring that
> as a bug with the integrated assembler, completely orthogonal to debug
> info.

For now I’d rather look for a bug in the way I feed the data to the AsmPrinter rather than a bug in the integrated assembler :-)

Thanks!
Fred
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140814/887cf0bf/attachment.html>