Given an SBValue (or it's type SBType) how do I find out what kind of type it is? (Like int32, int16, int8)
You can call:
SBType
SBValue::GetType();
SBType will describe the type itself. We recently added an enumeration call:
lldb::BasicType
SBType::GetBasicType();
This will return an enumeration that describes your type if is is a basic type (see the lldb::BasicType enumeration definition for details).
Op 15-10-2012 18:52, Greg Clayton schreef:
You can call:
SBType
SBValue::GetType();SBType will describe the type itself. We recently added an enumeration call:
lldb::BasicType
SBType::GetBasicType();This will return an enumeration that describes your type if is is a basic type (see the lldb::BasicType enumeration definition for details).
Cool. So I tried that and I get back a eBasicTypeBool for both types in the attached IR file. I emit it with DIBuilder and pass an DW_ATE_signed 32bits:
!9 = metadata !{i32 786468, null, metadata !"Integer", null, i32 0, i64 32, i64 32, i64 0, i32 0, i32 5} ; [ DW_TAG_base_type ] [Integer] [line 0, size 32, align 32, offset 0, enc DW_ATE_signed]
Is there something special I have to do here? (Integer is the internal name for this type in my language)
out.txt (4.37 KB)
Op 16-10-2012 15:33, Carlo Kok schreef:
Op 15-10-2012 18:52, Greg Clayton schreef:
You can call:
SBType
SBValue::GetType();SBType will describe the type itself. We recently added an enumeration
call:lldb::BasicType
SBType::GetBasicType();This will return an enumeration that describes your type if is is a
basic type (see the lldb::BasicType enumeration definition for details).Cool. So I tried that and I get back a eBasicTypeBool for both types in
the attached IR file. I emit it with DIBuilder and pass an DW_ATE_signed
32bits:!9 = metadata !{i32 786468, null, metadata !"Integer", null, i32 0, i64
32, i64 32, i64 0, i32 0, i32 5} ; [ DW_TAG_base_type ] [Integer] [line
0, size 32, align 32, offset 0, enc DW_ATE_signed]Is there something special I have to do here? (Integer is the internal
name for this type in my language)
Nevermind. This got fixed 1 lldb revision after I did my last up merge of the Windows branch.
Yes, that was a funny typo bug that I didn't catch where I had:
switch (a)
{
case a1:
switch b(b)
case b1:
base b2:
}
Not the missing {} on the second switch! After switching to a newer clang, we got the warning for unhandled switch statements and I fixed it asap.
Op 16-10-2012 18:53, Greg Clayton schreef:
Yes, that was a funny typo bug that I didn't catch where I had:
switch (a)
{
case a1:
switch b(b)
case b1:
base b2:
}Not the missing {} on the second switch! After switching to a newer clang, we got the warning for unhandled switch statements and I fixed it asap.
nice one yeah. So after playing with debugging for a while I noticed it's very "clang" oriented. While I don't really mind that, is there a way to store more custom language specific information? (I have control over both generation & lldb api) For example I have an array type that from the LLDB api looks like a pointer to it's sub type. There's a "length" field before it, and from the LLDB side I Want to look at the "length" and use it to display the sub entries, but then I have to store & know it from both side.
If it is a custom array type, you should look into writing a synthetic formatter for it so it can act just like an array should. We have many examples for std::vector, NSArray and more. Synthetic formatters are little python plug-ins that can create child objects for a given type, and also provide a summary string for the main type (like "3 objects" for an array).
Greg Clayton
Op 16-10-2012 22:15, Greg Clayton schreef:
Op 16-10-2012 18:53, Greg Clayton schreef:
Yes, that was a funny typo bug that I didn't catch where I had:
switch (a) { case a1: switch b(b) case b1: base b2: }
Not the missing {} on the second switch! After switching to a
newer clang, we got the warning for unhandled switch statements
and I fixed it asap.nice one yeah. So after playing with debugging for a while I
noticed it's very "clang" oriented. While I don't really mind that,
is there a way to store more custom language specific information?
(I have control over both generation & lldb api) For example I have
an array type that from the LLDB api looks like a pointer to it's
sub type. There's a "length" field before it, and from the LLDB
side I Want to look at the "length" and use it to display the sub
entries, but then I have to store & know it from both side.If it is a custom array type, you should look into writing a
synthetic formatter for it so it can act just like an array should.
We have many examples for std::vector, NSArray and more. Synthetic
formatters are little python plug-ins that can create child objects
for a given type, and also provide a summary string for the main type
(like "3 objects" for an array).
cool. I take it it does this based on the type names? If I put say a type called Integer in the dwarf debug info it ends up an "int", "word" becomes unsigned short, etc, if I read it on the LLDB side. (though the DWARF debug info did have integer). Is there a way to get that original name back in LLDB? (I see there's a field in dwarf debug info even for pointers, if I can insert a name there I can distingiush between different types on the debugger side).
Thanks,
Carlo Kok
Op 17-10-2012 21:51, Carlo Kok schreef:
Op 16-10-2012 22:15, Greg Clayton schreef:
Op 16-10-2012 18:53, Greg Clayton schreef:
Yes, that was a funny typo bug that I didn't catch where I had:
switch (a) { case a1: switch b(b) case b1: base b2: }
Not the missing {} on the second switch! After switching to a
newer clang, we got the warning for unhandled switch statements
and I fixed it asap.If it is a custom array type, you should look into writing a
synthetic formatter for it so it can act just like an array should.
We have many examples for std::vector, NSArray and more. Synthetic
formatters are little python plug-ins that can create child objects
for a given type, and also provide a summary string for the main type
(like "3 objects" for an array).cool. I take it it does this based on the type names? If I put say a
type called Integer in the dwarf debug info it ends up an "int", "word"
becomes unsigned short, etc, if I read it on the LLDB side. (though the
DWARF debug info did have integer). Is there a way to get that original
name back in LLDB? (I see there's a field in dwarf debug info even for
pointers, if I can insert a name there I can distingiush between
different types on the debugger side).
Maybe a way to access the dwarf debug info on Type/SBType?
I noticed that my 'Char' type, even though it's emitted as DW_ATE_unsigned_char size 16 ends up as an unsigned short.
(I use DW_ATE_signed/DW_ATE_unsigned for integer types and *char for actual character types to distingiush between the both).
Op 17-10-2012 22:23, Carlo Kok schreef:
Op 17-10-2012 21:51, Carlo Kok schreef:
Op 16-10-2012 22:15, Greg Clayton schreef:
Op 16-10-2012 18:53, Greg Clayton schreef:
Yes, that was a funny typo bug that I didn't catch where I had:
switch (a) { case a1: switch b(b) case b1: base b2: }
Not the missing {} on the second switch! After switching to a
newer clang, we got the warning for unhandled switch statements
and I fixed it asap.If it is a custom array type, you should look into writing a
synthetic formatter for it so it can act just like an array should.
We have many examples for std::vector, NSArray and more. Synthetic
formatters are little python plug-ins that can create child objects
for a given type, and also provide a summary string for the main type
(like "3 objects" for an array).cool. I take it it does this based on the type names? If I put say a
type called Integer in the dwarf debug info it ends up an "int", "word"
becomes unsigned short, etc, if I read it on the LLDB side. (though the
DWARF debug info did have integer). Is there a way to get that original
name back in LLDB? (I see there's a field in dwarf debug info even for
pointers, if I can insert a name there I can distingiush between
different types on the debugger side).Maybe a way to access the dwarf debug info on Type/SBType?
I noticed that my 'Char' type, even though it's emitted as
DW_ATE_unsigned_char size 16 ends up as an unsigned short.(I use DW_ATE_signed/DW_ATE_unsigned for integer types and *char for
actual character types to distingiush between the both).
I've got the same question for getting the current functions signature. (the real types, not the "c" version of them). I know they're in there somewhere.
Thanks,