llvm dev - Nov 2011 - [LLVMdev] .debug_info section size in arm executable

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

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

On Nov 9, 2011, at 2:12 PM, Chris Lattner wrote:
> 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.
> 
In this case though it's not dead as long as there's a switch on the
enum with a default case :) i.e. "We should never get here, but yet we are,
what type that I'm not expecting did we get here with?"
>> 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. :)
The above :)

That said if we want to conditionalize this on flimit-debug-info that's
fine, however, I think that since the type is used all elements of the type are
used. Also, I doubt that (except for pathological cases) enum switch values are
our greatest worry for size of the string table :)

-eric