[LLVMdev] .debug_info section size in arm executable

[Chris Lattner]

On Nov 9, 2011, at 1:08 PM, Jim Grosbach wrote:
>> On Nov 9, 2011, at 10:49 AM, Jim Grosbach wrote:
>>>> 
>>>> It's not good, but people do it. Also constructing enums via & and | etc. It'd be nice to be able to get the name of whatever it is that the code generator actually produced :)
>>>> 
>>> 
>>> Agreed. LLVM itself does this sort of thing pretty frequently, actually, and having the enum names and values available in the debugger is very nice.
>> 
>> Wouldn't it be better to emit the enumerators that are actually used in a translation unit, instead of emitting all of them?  If we're not emitting them when used, that would be a problem, but I don't see a reason to care about enumerators that are never used anywhere in a program.

> Say something is going wrong for value E of the enum because the default case doesn't work for it. I want to put a conditional breakpoint on the switch statement for 'a == E', but E isn't explicitly used anywhere in the program since the call to foo passes the value as an int, constructed in some arbitrary manner.

So long as E is used in another file, you'll be able to do this.  If E isn't used anywhere in your app, then it's dead and doesn't seem interesting.

> Also consider the case where the caller of foo() (which does explicitly use E) is in a dylib we haven't loaded yet, and thus haven't looked at the debug info for. I want to set that same breakpoint.

-flimit-debug-info=0.  The entire idea of -gused is that you're building (almost) all of your app with debug info.  It's the default because this matches the common scenario.

In short, I still don't understand why we'd want to emit all the enumerators just because an enum type is used. :)

-Chris