[LLVMdev] .debug_info section size in arm executable

[Jim Grosbach]

On Nov 9, 2011, at 12:52 PM, Chris Lattner 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.


Fleshing out Eric's example a bit:
enum bar {A, B, C, D, E, F, ...};

void foo(enum bar a) {
switch(a) {
default:
  // stuff
case B:
case C:
  // other stuff
}
// yet more stuff
}

void bar(int b) {
  //...
  foo(b);
  //...
}

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.

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.

Without the full range of enum values in the debug info for the translation unit in which foo resides, I can't reference the values.

Now, I can definitely see an argument for omitting the information (probably the entire type) if the enum itself is never referenced in the translation unit. I believe that's the current behaviour already(?)

-Jim