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

On Nov 9, 2011, at 10:43 AM, Eric Christopher wrote:
> 
> On Nov 9, 2011, at 10:35 AM, Chris Lattner wrote:
> 
>> 
>> On Nov 9, 2011, at 2:58 AM, Nick Lewycky wrote:
>> 
>>> 
>>> For one example, for enums clang will emit the names for all of the
enum
>>> cases. GCC only emits the ones that are used.
>> 
>> Is this a clang bug, or a feature?
> 
> IMO this is probably a feature. Thinking about it like this:
> 
> int foo(enum Bar x) {
> 	switch(x)
>           ...
> }
> 
> int baz (int a)
> {
>    foo(a);
> }
> 
> 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.

-Jim

On Nov 9, 2011, at 10:49 AM, Jim Grosbach wrote:
> 
> On Nov 9, 2011, at 10:43 AM, Eric Christopher wrote:
> 
>> 
>> On Nov 9, 2011, at 10:35 AM, Chris Lattner wrote:
>> 
>>> 
>>> On Nov 9, 2011, at 2:58 AM, Nick Lewycky wrote:
>>> 
>>>> 
>>>> For one example, for enums clang will emit the names for all of
the enum
>>>> cases. GCC only emits the ones that are used.
>>> 
>>> Is this a clang bug, or a feature?
>> 
>> IMO this is probably a feature. Thinking about it like this:
>> 
>> int foo(enum Bar x) {
>> 	switch(x)
>>          ...
>> }
>> 
>> int baz (int a)
>> {
>>   foo(a);
>> }
>> 
>> 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.

+1

In addition, what's the expected size reduction in such cases to offset this
inconvenience? Besides, is this an intentional gcc feature or accidental gcc
behavior ?

-
Devang

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.

-Chris

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