On Mon, Apr 22, 2013 at 3:36 PM, Adrian Prantl <[email protected]> wrote:
>
> On Apr 19, 2013, at 3:05 PM, Eric Christopher <[email protected]> wrote:
>
>> On Fri, Apr 19, 2013 at 2:51 PM, Adrian Prantl <[email protected]> wrote:
>>> To briefly summarize a discussion in #llvm:
>>> The problem the patch addresses is that lldb displays negative enumerator
>>> values for fixed enums as unsigned values.
>>>
>>> This patch solves this by attaching the (optional) underlying type of the
>>> enum if there is one specified (for example NSInteger in the test case that
>>> comes with the patch). This is something we used to do for all scoped
>>> enums, and the patch extends this to all fixed enums.
>>>
>>> Eric points out that it should be sufficient to emit a negative
>>> DW_AT_const_value for the enumerator
>>> to let the debugger deduce that this is a signed data type. However, he
>>> also points out that darwin-gdb will probably not be able understand that.
>>>
>>
>> And that this ends up bloating the debug info (admittedly by a single
>> field, but...) when we don't need it to.
>
> True. One tag per fixed enum declaration.
Just to come back to this. It's not just a question of bloat, it's
just incorrect to put DW_AT_enum_class on an enum that's not an enum
class... classes with fixed underlying type aren't necessarily enum
classes:
enum x : int { }; // fixed underlying type, but not an enum class,
should not have DW_AT_enum_class
enum class x { }; // no fixed underlying type, but is an enum class
As for emitting the underlying type, fixed or not (it's not wrong to
put the underlying type on the enum class even if it's not a fixed
underlying type, I don't think - as it wouldn't be incorrect to put it
on an old enum either), I'm not sure what the right, good, or best
answer is. GCC doesn't put underlying types on any enum.
To fix the DW_AT_enum_class thing, we should probably just use a
separate bit in the flags to specify whether an enum is an enum class.
That way underlying types can be specified orthogonally to
enum-class-ness.
On a side/related note: http://llvm.org/bugs/show_bug.cgi?id=19712 -
LLVM depends on the signedness of a type to determine how to emit
constants of that type, this breaks for any enum we emit without an
underlying type (and where a constant of that type is ambiguous in
signedness in a 64 bit constant).
>>> Update: We actually do emit the enumerators as signed values
>>> (DW_FORM_sdata). But it’s not enough for lldb to deduce the signedness in
>>> all cases.
>>>
>>
>> Why not?
>
> I filed a bug report for lldb. I’ll follow up once I know more about it.
>
> --
> Adrian
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
