Re: [lldb-dev] How to get the error message while creating an invalid target?
The SBDebugger::CreateTarget() call take an "SBError &error" as the last
argument. The error will contain any error message:
lldb::SBTarget
CreateTarget (const char *filename,
const char *target_triple,
const char *platform_name,
bool add_dependent_modules,
lldb::SBError& error);
This function is the one that should be used. Any of the "const char *"
arguments can be NULL. But typically you want to specify at least the filename.
The triple is only really needed if you are debugging files that have more than
one architecture or if the file you are debugging doesn't completely specify
what you want to debug. The triple can be "x86_64" or more specific like
"x86_64-apple-ios". The platform name only needs to be specified if your
executable file (ELF file, mach-o file, or other exe format) doesn't have
enough information inside of it to extract the triple from the object file. ELF
has very sparse information inside of it to help us identify what platform it
can/should be used for. You will know if you need to specify the platform if
LLDB gets it wrong. To see what happens, try things out from the command line:
(lldb) target create /tmp/a.out
(lldb) target list
Current targets:
* target #0: /tmp/a.out ( arch=x86_64-apple-macosx, platform=host )
We see that the "host" platform was auto selected and the architecture was
extracted from the executable as "x86_64-apple-macosx".
To see a list of platform names you can do:
(lldb) platform select
Available completions:
remote-freebsd
remote-linux
remote-netbsd
remote-windows
kalimba
remote-android
remote-ios
remote-macosx
ios-simulator
darwin-kernel
tvos-simulator
watchos-simulator
remote-tvos
remote-watchos
remote-gdb-server
So if you have an iOS binary that was targeting a device (not a simulator), you
could create your target with:
lldb::SBError error;
lldb::SBTarget target = debugger.CreateTarget("/tmp/a.out", "armv7-apple-ios",
"remote-ios", false, error);
> On Mar 8, 2016, at 5:22 PM, Jeffrey Tan via lldb-dev
> wrote:
>
> Hi,
>
> In lldb, when I try to "target create [invalid_target]", I got some
> meaningful error message like:
> error: 'XXX' doesn't contain any 'host' platform architectures: x86_64h,
> x86_64, i386
>
> What is the python API to get this from? I tried to check SBTarget.IsValid()
> and then use SBTarget.GetDescription(eDescriptionLevelVerbose), but that does
> not return the error message.
>
> Thanks
> Jeffrey
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] How to get the error message while creating an invalid target?
Ah, I used CreateTargetWithFileAndArch() and missed this one. Feeling
embarrassed... Thank you!
On Wed, Mar 9, 2016 at 10:10 AM, Greg Clayton wrote:
> The SBDebugger::CreateTarget() call take an "SBError &error" as the last
> argument. The error will contain any error message:
>
> lldb::SBTarget
> CreateTarget (const char *filename,
> const char *target_triple,
> const char *platform_name,
> bool add_dependent_modules,
> lldb::SBError& error);
>
>
>
> This function is the one that should be used. Any of the "const char *"
> arguments can be NULL. But typically you want to specify at least the
> filename. The triple is only really needed if you are debugging files that
> have more than one architecture or if the file you are debugging doesn't
> completely specify what you want to debug. The triple can be "x86_64" or
> more specific like "x86_64-apple-ios". The platform name only needs to be
> specified if your executable file (ELF file, mach-o file, or other exe
> format) doesn't have enough information inside of it to extract the triple
> from the object file. ELF has very sparse information inside of it to help
> us identify what platform it can/should be used for. You will know if you
> need to specify the platform if LLDB gets it wrong. To see what happens,
> try things out from the command line:
>
>
> (lldb) target create /tmp/a.out
> (lldb) target list
> Current targets:
> * target #0: /tmp/a.out ( arch=x86_64-apple-macosx, platform=host )
>
> We see that the "host" platform was auto selected and the architecture was
> extracted from the executable as "x86_64-apple-macosx".
>
> To see a list of platform names you can do:
>
> (lldb) platform select
> Available completions:
> remote-freebsd
> remote-linux
> remote-netbsd
> remote-windows
> kalimba
> remote-android
> remote-ios
> remote-macosx
> ios-simulator
> darwin-kernel
> tvos-simulator
> watchos-simulator
> remote-tvos
> remote-watchos
> remote-gdb-server
>
> So if you have an iOS binary that was targeting a device (not a
> simulator), you could create your target with:
>
> lldb::SBError error;
> lldb::SBTarget target = debugger.CreateTarget("/tmp/a.out",
> "armv7-apple-ios", "remote-ios", false, error);
>
>
> > On Mar 8, 2016, at 5:22 PM, Jeffrey Tan via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> >
> > Hi,
> >
> > In lldb, when I try to "target create [invalid_target]", I got some
> meaningful error message like:
> > error: 'XXX' doesn't contain any 'host' platform architectures: x86_64h,
> x86_64, i386
> >
> > What is the python API to get this from? I tried to check
> SBTarget.IsValid() and then use
> SBTarget.GetDescription(eDescriptionLevelVerbose), but that does not return
> the error message.
> >
> > Thanks
> > Jeffrey
> > ___
> > lldb-dev mailing list
> > lldb-dev@lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] How to get the error message while creating an invalid target?
Yep, this is legacy API that must stay in because we had it in our API waaa
back when and we never remove API once it has made it into a build and someone
uses it. We might mark it as deprecated, which we should do to
CreateTargetWithFileAndArch and the other function, but we never remove it.
Greg Clayton
> On Mar 9, 2016, at 10:53 AM, Jeffrey Tan wrote:
>
> Ah, I used CreateTargetWithFileAndArch() and missed this one. Feeling
> embarrassed... Thank you!
>
> On Wed, Mar 9, 2016 at 10:10 AM, Greg Clayton wrote:
> The SBDebugger::CreateTarget() call take an "SBError &error" as the last
> argument. The error will contain any error message:
>
> lldb::SBTarget
> CreateTarget (const char *filename,
> const char *target_triple,
> const char *platform_name,
> bool add_dependent_modules,
> lldb::SBError& error);
>
>
>
> This function is the one that should be used. Any of the "const char *"
> arguments can be NULL. But typically you want to specify at least the
> filename. The triple is only really needed if you are debugging files that
> have more than one architecture or if the file you are debugging doesn't
> completely specify what you want to debug. The triple can be "x86_64" or more
> specific like "x86_64-apple-ios". The platform name only needs to be
> specified if your executable file (ELF file, mach-o file, or other exe
> format) doesn't have enough information inside of it to extract the triple
> from the object file. ELF has very sparse information inside of it to help us
> identify what platform it can/should be used for. You will know if you need
> to specify the platform if LLDB gets it wrong. To see what happens, try
> things out from the command line:
>
>
> (lldb) target create /tmp/a.out
> (lldb) target list
> Current targets:
> * target #0: /tmp/a.out ( arch=x86_64-apple-macosx, platform=host )
>
> We see that the "host" platform was auto selected and the architecture was
> extracted from the executable as "x86_64-apple-macosx".
>
> To see a list of platform names you can do:
>
> (lldb) platform select
> Available completions:
> remote-freebsd
> remote-linux
> remote-netbsd
> remote-windows
> kalimba
> remote-android
> remote-ios
> remote-macosx
> ios-simulator
> darwin-kernel
> tvos-simulator
> watchos-simulator
> remote-tvos
> remote-watchos
> remote-gdb-server
>
> So if you have an iOS binary that was targeting a device (not a simulator),
> you could create your target with:
>
> lldb::SBError error;
> lldb::SBTarget target = debugger.CreateTarget("/tmp/a.out",
> "armv7-apple-ios", "remote-ios", false, error);
>
>
> > On Mar 8, 2016, at 5:22 PM, Jeffrey Tan via lldb-dev
> > wrote:
> >
> > Hi,
> >
> > In lldb, when I try to "target create [invalid_target]", I got some
> > meaningful error message like:
> > error: 'XXX' doesn't contain any 'host' platform architectures: x86_64h,
> > x86_64, i386
> >
> > What is the python API to get this from? I tried to check
> > SBTarget.IsValid() and then use
> > SBTarget.GetDescription(eDescriptionLevelVerbose), but that does not return
> > the error message.
> >
> > Thanks
> > Jeffrey
> > ___
> > lldb-dev mailing list
> > lldb-dev@lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] LLDB + UE4 on Android
Hello, fellow developers! I’m trying to debug Unreal Engine 4 sample on Android with LLDB 3.8 build from source - Win32 x86 liblldb.dll and Android ARM lldb-server : it can’t match the stripped module libUE4.so running on the device with a full version which is available on a host. Unreal Build Tool don’t add the .note.gnu.build-id or .gnu_debuglink sections to ELF files – and it looks that only if the stripped ELF .so running on a target does have one of these than it could be matched with a full ELF module located on a host - is that true? My reasoning is based on examination of https://github.com/llvm-mirror/lldb/blob/release_38/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp#L4328 and https://github.com/llvm-mirror/lldb/blob/release_38/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp#L790 If so, I need to modify UBT to add the .build-id or .gnu_debuglink to a stripped libUE4.so --- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. --- ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] What's the purpose of the TestStarted-XXX and TestFinished-XXX files?
The test traces directory tends to accumulate thousands and thousands of TestStarted-XXX and TestFinished-XXX files. What purpose do they serve? I assume it's for trying to figure out why something went wrong. If you have a TestStarted-123 without a corresponding TestFinished-123, then you can know that a test crashes and by looking inside the file, you can see which test and what the command was. If that's the case, then wouldn't it be cleaner to delete the TestStarted file when the test finishes rather than writing a second file? Then you can simply search for TestStarted files to see the ones that didn't finish successfully without the noise of thousands of others that did. I suppose it's also possible that some other process is looking at these files in order to collect statistics. Is there such a beast and is it valuable? Adrian. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] What's the purpose of the TestStarted-XXX and TestFinished-XXX files?
I would be happy to see these files go away if no one is using them... > On Mar 9, 2016, at 2:32 PM, Adrian McCarthy via lldb-dev > wrote: > > The test traces directory tends to accumulate thousands and thousands of > TestStarted-XXX and TestFinished-XXX files. What purpose do they serve? > > I assume it's for trying to figure out why something went wrong. If you have > a TestStarted-123 without a corresponding TestFinished-123, then you can know > that a test crashes and by looking inside the file, you can see which test > and what the command was. > > If that's the case, then wouldn't it be cleaner to delete the TestStarted > file when the test finishes rather than writing a second file? Then you can > simply search for TestStarted files to see the ones that didn't finish > successfully without the noise of thousands of others that did. > > I suppose it's also possible that some other process is looking at these > files in order to collect statistics. Is there such a beast and is it > valuable? > > Adrian. > ___ > lldb-dev mailing list > lldb-dev@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] Better error message for attaching to a process already being debugged
Hi, My colleague is trying to use our lldb IDE attaching to app run/build from Xcode which failed. I can reproduce this with lldb console: jeffreytan-mbp:$ ps aux | grep iOSApp jeffreytan 61816 0.0 0.0 2432772676 s002 S+3:00PM 0:00.00 grep iOSApp jeffreytan 61806 0.0 0.2 2721120 38600 ?? SXs 3:00PM 0:00.24 /Users/jeffreytan/Library/Developer/CoreSimulator/Devices/EF17E202-3981-4DB0-87C9-2A9345C1E713/data/Containers/Bundle/Application/CAEBA7D7-D284-4489-8A53-A88E56F9BB04/iOSAppTest.app/iOSAppTest jeffreytan-mbp:$ lldb -p 61806 (lldb) process attach --pid 61806 *error: attach failed: attach failed: unable to attach* My theory is: 1. Xcode does not have the concept of run without debugger and run under debugger, so it always run app with debugger enabled.(Is this true?) 2. And you can't have two native debuggers debugging the same process on Mac(this is true on Windows, is it true for Mac or Linux?) If both are true, can we report meaningful message like "inferior is already being debugged" or something similar instead of the generic error message like "*attach failed: unable to attach*"? Btw: I found I can still use gdb to attach to the process(with a permission elevation dialog pop-up) and see the callstack. How does gdb do that? Jeffrey ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Better error message for attaching to a process already being debugged
Did you follow the instructions and you have made your "lldb_codesign" code signing certificate?: svn cat http://llvm.org/svn/llvm-project/lldb/trunk/docs/code-signing.txt If you don't do this, your debugserver won't have the ability to debug anything. If you don't want to do this, you can remove the "debugserver" binary from your LLDB.framework that you built and are running with, and then we will fall back to using the one that is installed inside /Applications/Xcode.app as that one is Apple code signed. Greg > On Mar 9, 2016, at 3:04 PM, Jeffrey Tan via lldb-dev > wrote: > > Hi, > > My colleague is trying to use our lldb IDE attaching to app run/build from > Xcode which failed. I can reproduce this with lldb console: > > jeffreytan-mbp:$ ps aux | grep iOSApp > jeffreytan 61816 0.0 0.0 2432772676 s002 S+3:00PM 0:00.00 > grep iOSApp > jeffreytan 61806 0.0 0.2 2721120 38600 ?? SXs 3:00PM 0:00.24 > /Users/jeffreytan/Library/Developer/CoreSimulator/Devices/EF17E202-3981-4DB0-87C9-2A9345C1E713/data/Containers/Bundle/Application/CAEBA7D7-D284-4489-8A53-A88E56F9BB04/iOSAppTest.app/iOSAppTest > jeffreytan-mbp:$ lldb -p 61806 > (lldb) process attach --pid 61806 > error: attach failed: attach failed: unable to attach > > My theory is: > 1. Xcode does not have the concept of run without debugger and run under > debugger, so it always run app with debugger enabled.(Is this true?) > 2. And you can't have two native debuggers debugging the same process on > Mac(this is true on Windows, is it true for Mac or Linux?) > > If both are true, can we report meaningful message like "inferior is already > being debugged" or something similar instead of the generic error message > like "attach failed: unable to attach"? > > Btw: I found I can still use gdb to attach to the process(with a permission > elevation dialog pop-up) and see the callstack. How does gdb do that? > > Jeffrey > ___ > lldb-dev mailing list > lldb-dev@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] DWARFASTParserClang and DW_TAG_typedef for anonymous structs
Hi All
I'm hoping that someone might be able to give me some direction
regarding `Type` resolution from DWARF informationfor functions taking
anonymous structs hidden behind a typedef
e.g.
```
typedef struct {
int i;
float f;
} my_untagged_struct;
void __attribute__((noinline)) myfunc(my_untagged_struct *s)
{
s->i = 0;
s->f = 3.14f;
}
int main()
{
my_untagged_struct s;
myfunc(&s);
return 0;
}
```
I [recently reported a
bug](https://llvm.org/bugs/show_bug.cgi?id=26790) relating to the
clang expression evaluator no longer being able to resolve calls to
functions with arguments to typedefed anonymous structs, after a cleanup
to the expression parsing code.
I was perfectly wrong in my assumptions about the cause of the bug, and
after some more digging, I think I've tracked it down to a section of
code in `DWARFASTParserClang::ParseTypeFromDWARF`.
(DWARFASTParserClang::ParseTypeFromDwarf:254)
```
switch (tag)
{
case DW_TAG_typedef:
// Try to parse a typedef from the DWO file first as modules
// can contain typedef'ed structures that have no names like:
//
// typedef struct { int a; } Foo;
//
// In this case we will have a structure with no name and a
// typedef named "Foo" that points to this unnamed structure.
// The name in the typedef is the only identifier for the
struct, // so always try to get typedefs from DWO files if possible.
//
// The type_sp returned will be empty if the typedef doesn't
exist // in a DWO file, so it is cheap to call this function just to
check. //
// If we don't do this we end up creating a TypeSP that says
this // is a typedef to type 0x123 (the DW_AT_type value would be 0x123
// in the DW_TAG_typedef), and this is the unnamed structure
type. // We will have a hard time tracking down an unnammed structure
// type in the module DWO file, so we make sure we don't get
into // this situation by always resolving typedefs from the DWO file.
type_sp = ParseTypeFromDWO(die, log);
if (type_sp)
return type_sp;
LLVM_FALLTHROUGH
```
In my case, the type information for the typedef is included within the
main executable's DWARF rather than an external .dwo file (snippet from
the DWARF included the end of this message), and therefore the `case`
for `DW_TAG_typedef` falls through as `ParseTypeFromDWO` returns a NULL
value.
As this is code I'm not familiar with, I'd appreciate if any one on the
list was able to give some guidance as to the best way to resolve this
issue, so that `ClangExpressionDeclMap::FindExternalVisibleDecls` can
correctly resolve calls to functions taking typedef names to anonymous
structs. I'm happy to take a whack at implementing this feature, but
I'm a bit stuck as to how to resolve this type given the current DIE
object.
Any help or guidance on where to start with this would be really
helpful.
All the best
Luke
This is a snippet from the output of llvm-dwarfdump on the above code
example.
`g++ -g main.cpp && llvm-dwarfdump a.out | grep DW_TAG_typedef -A 35`
0x005c: DW_TAG_typedef [6]
DW_AT_name [DW_FORM_strp]
( .debug_str[0x0069] = "my_untagged_struct") DW_AT_decl_file
[DW_FORM_data1] ("/home/luke/main.cpp") DW_AT_decl_line
[DW_FORM_data1] (4) DW_AT_type [DW_FORM_ref4] (cu +
0x002d => {0x002d})
0x0067: DW_TAG_subprogram [7] *
DW_AT_external [DW_FORM_flag_present] (true)
DW_AT_name [DW_FORM_strp]
( .debug_str[0x0006] = "myfunc") DW_AT_decl_file
[DW_FORM_data1] ("/home/luke/main.cpp") DW_AT_decl_line
[DW_FORM_data1] (6) DW_AT_linkage_name [DW_FORM_strp]
( .debug_str[0x005d] = "_Z6myfuncP18my_untagged_struct")
DW_AT_low_pc [DW_FORM_addr] (0x00400566) DW_AT_high_pc
[DW_FORM_data8] (0x0026) DW_AT_frame_base
[DW_FORM_exprloc] (<0x1> 9c ) DW_AT_Unknown_2117
[DW_FORM_flag_present] (true) DW_AT_sibling
[DW_FORM_ref4] (cu + 0x0095 => {0x0095})
0x0088: DW_TAG_formal_parameter [8]
DW_AT_name [DW_FORM_string] ("s")
DW_AT_decl_file [DW_FORM_data1]
("/home/luke/main.cpp") DW_AT_decl_line [DW_FORM_data1] (6)
DW_AT_type [DW_FORM_ref4] (cu + 0x0095 =>
{0x0095}) DW_AT_location [DW_FORM_exprloc] (<0x2> 91 68 )
0x0094: NULL
0x0095: DW_TAG_pointer_type [9]
DW_AT_byte_size [DW_FORM_data1] (0x08)
DW_AT_type [DW_FORM_ref4] (cu + 0x005c =>
{0x005c})
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] DWARFASTParserClang and DW_TAG_typedef for anonymous structs
So we ran into a problem where we had anonymous structs in modules. They have
no name, so we had no way to say "module A, please give me a struct named...
nothing in the namespace 'foo'". Obviously this doesn't work, so we always try
to make sure a typedef doesn't come from a module first, by asking us to get
the typedef from the DWO file:
type_sp = ParseTypeFromDWO(die, log);
If this fails, it just means we have the typedef in hand. If I compile your
example I end up with:
0x000b: TAG_compile_unit [1] *
AT_producer( "Apple LLVM version 8.0.0 (clang-800.0.5.3)" )
AT_language( DW_LANG_C99 )
AT_name( "main.c" )
AT_stmt_list( 0x )
AT_comp_dir( "/tmp" )
AT_low_pc( 0x00010f60 )
AT_high_pc( 0x00010fb0 )
0x002e: TAG_subprogram [2] *
AT_low_pc( 0x00010f60 )
AT_high_pc( 0x00010f85 )
AT_frame_base( rbp )
AT_name( "myfunc" )
AT_decl_file( "/private/tmp/main.c" )
AT_decl_line( 6 )
AT_prototyped( 0x01 )
AT_external( 0x01 )
0x0049: TAG_formal_parameter [3]
AT_location( fbreg -8 )
AT_name( "s" )
AT_decl_file( "/private/tmp/main.c" )
AT_decl_line( 6 )
AT_type( {0x008c} ( my_untagged_struct* ) )
0x0057: NULL
0x0058: TAG_subprogram [4] *
AT_low_pc( 0x00010f90 )
AT_high_pc( 0x00010fb0 )
AT_frame_base( rbp )
AT_name( "main" )
AT_decl_file( "/private/tmp/main.c" )
AT_decl_line( 12 )
AT_type( {0x0085} ( int ) )
AT_external( 0x01 )
0x0076: TAG_variable [5]
AT_location( fbreg -16 )
AT_name( "s" )
AT_decl_file( "/private/tmp/main.c" )
AT_decl_line( 14 )
AT_type( {0x0091} ( my_untagged_struct ) )
0x0084: NULL
0x0085: TAG_base_type [6]
AT_name( "int" )
AT_encoding( DW_ATE_signed )
AT_byte_size( 0x04 )
0x008c: TAG_pointer_type [7]
AT_type( {0x0091} ( my_untagged_struct ) )
0x0091: TAG_typedef [8]
AT_type( {0x009c} ( struct ) )
AT_name( "my_untagged_struct" )
AT_decl_file( "/private/tmp/main.c" )
AT_decl_line( 4 )
0x009c: TAG_structure_type [9] *
AT_byte_size( 0x08 )
AT_decl_file( "/private/tmp/main.c" )
AT_decl_line( 1 )
0x00a0: TAG_member [10]
AT_name( "i" )
AT_type( {0x0085} ( int ) )
AT_decl_file( "/private/tmp/main.c" )
AT_decl_line( 2 )
AT_data_member_location( +0 )
0x00ae: TAG_member [10]
AT_name( "f" )
AT_type( {0x00bd} ( float ) )
AT_decl_file( "/private/tmp/main.c" )
AT_decl_line( 3 )
AT_data_member_location( +4 )
0x00bc: NULL
0x00bd: TAG_base_type [6]
AT_name( "float" )
AT_encoding( DW_ATE_float )
AT_byte_size( 0x04 )
0x00c4: NULL
Note that the typedef is at 0x0091, and it is a typedef to 0x009c.
Also note that the DWARF DIE at 0x009c is a complete definition as it has
children describing its members and 0x009c doesn't have a
DW_AT_declaration(1) attribute. Is this how your DWARF looks for your stuff?
The DWARF you had looked like:
0x005c: DW_TAG_typedef [6]
DW_AT_name( "my_untagged_struct" )
DW_AT_decl_file("/home/luke/main.cpp")
DW_AT_decl_line(4)
DW_AT_type({0x002d})
What did the type at 0x002d look like? Similar to 0x009c in my DWARF I
presume?
The DWARFASTParserClang class is responsible for making up a clang type in the
clang::ASTContext for this typedef. What will happen in the code where the flow
falls through is the we will make a lldb_private::Type that says "I am a
typedef to type whose user ID is 0x002d (in your example)". A NULL pointer
should not be returned from the DWARFASTParserClang::ParseTypeFromDWARF()
function. If it is, please step through and figure out why. I compiled your
example and did the following:
% lldb a.out
(lldb) b main
(lldb) r
Process 89808 launched: '/private/tmp/a.out' (x86_64)
Process 89808 stopped
* thread #1: tid = 0xf7473, 0x00010fa3 a.out main + 19, stop reason =
breakpoint 1.1, q
Re: [lldb-dev] Better error message for attaching to a process already being debugged
Hi Greg, I am using the lldb(/usr/bin/lldb) installed by Xcode not self-built one. For example, I can use lldb to attach to chrome without any problem. And I can see the debugserver it uses is from "/Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Versions/A/Resources/debugserver". Do I still need to sign it? Only the app launched from Xcode IDE can't be attached from this lldb. On Wed, Mar 9, 2016 at 3:08 PM, Greg Clayton wrote: > Did you follow the instructions and you have made your "lldb_codesign" > code signing certificate?: > > svn cat http://llvm.org/svn/llvm-project/lldb/trunk/docs/code-signing.txt > > If you don't do this, your debugserver won't have the ability to debug > anything. If you don't want to do this, you can remove the "debugserver" > binary from your LLDB.framework that you built and are running with, and > then we will fall back to using the one that is installed inside > /Applications/Xcode.app as that one is Apple code signed. > > Greg > > > On Mar 9, 2016, at 3:04 PM, Jeffrey Tan via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > > > > Hi, > > > > My colleague is trying to use our lldb IDE attaching to app run/build > from Xcode which failed. I can reproduce this with lldb console: > > > > jeffreytan-mbp:$ ps aux | grep iOSApp > > jeffreytan 61816 0.0 0.0 2432772676 s002 S+3:00PM > 0:00.00 grep iOSApp > > jeffreytan 61806 0.0 0.2 2721120 38600 ?? SXs 3:00PM > 0:00.24 > /Users/jeffreytan/Library/Developer/CoreSimulator/Devices/EF17E202-3981-4DB0-87C9-2A9345C1E713/data/Containers/Bundle/Application/CAEBA7D7-D284-4489-8A53-A88E56F9BB04/iOSAppTest.app/iOSAppTest > > jeffreytan-mbp:$ lldb -p 61806 > > (lldb) process attach --pid 61806 > > error: attach failed: attach failed: unable to attach > > > > My theory is: > > 1. Xcode does not have the concept of run without debugger and run under > debugger, so it always run app with debugger enabled.(Is this true?) > > 2. And you can't have two native debuggers debugging the same process on > Mac(this is true on Windows, is it true for Mac or Linux?) > > > > If both are true, can we report meaningful message like "inferior is > already being debugged" or something similar instead of the generic error > message like "attach failed: unable to attach"? > > > > Btw: I found I can still use gdb to attach to the process(with a > permission elevation dialog pop-up) and see the callstack. How does gdb do > that? > > > > Jeffrey > > ___ > > lldb-dev mailing list > > lldb-dev@lists.llvm.org > > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > > ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Better error message for attaching to a process already being debugged
> On Mar 9, 2016, at 3:04 PM, Jeffrey Tan via lldb-dev > wrote: > > Hi, > > My colleague is trying to use our lldb IDE attaching to app run/build from > Xcode which failed. I can reproduce this with lldb console: > > jeffreytan-mbp:$ ps aux | grep iOSApp > jeffreytan 61816 0.0 0.0 2432772676 s002 S+3:00PM 0:00.00 > grep iOSApp > jeffreytan 61806 0.0 0.2 2721120 38600 ?? SXs 3:00PM 0:00.24 > /Users/jeffreytan/Library/Developer/CoreSimulator/Devices/EF17E202-3981-4DB0-87C9-2A9345C1E713/data/Containers/Bundle/Application/CAEBA7D7-D284-4489-8A53-A88E56F9BB04/iOSAppTest.app/iOSAppTest > jeffreytan-mbp:$ lldb -p 61806 > (lldb) process attach --pid 61806 > error: attach failed: attach failed: unable to attach > > My theory is: > 1. Xcode does not have the concept of run without debugger and run under > debugger, so it always run app with debugger enabled.(Is this true?) That is not true. In the Run Scheme, uncheck the "Debug Executable" checkbox. But running with the debugger is the default. Note, an X in the status field for ps means the app is being debugged. So in this case, the app you were trying to attach to WAS already being debugged. > 2. And you can't have two native debuggers debugging the same process on > Mac(this is true on Windows, is it true for Mac or Linux?) That is true for Mac, and in general for ptrace based debugging. I don't know much about procfs. > > If both are true, can we report meaningful message like "inferior is already > being debugged" or something similar instead of the generic error message > like "attach failed: unable to attach"? That should be possible, there's code to eliminate already debugged processes in the "Attach to process by name" functionality. So if you specify a PID and the attach fails, we could check after the fact and see if it is already being traced. Please file a bug for this, and/or take a whack at fixing it if you feel like it. > > Btw: I found I can still use gdb to attach to the process(with a permission > elevation dialog pop-up) and see the callstack. How does gdb do that? I haven't looked at the FSF gdb OS X support for years, so I can't really comment on it. But it is not possible to ptrace something that is already ptraced, so if gdb is still doing it this way, then it should also fail. Maybe it is only getting the mach task and exception ports and debugging just with them? You can have multiple readers for the task port, and you can steal the exception port from someone else. But if it did that, the other debugger should stop working. Jim > > Jeffrey > ___ > lldb-dev mailing list > lldb-dev@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Better error message for attaching to a process already being debugged
Thanks for the info Jim. That answers my questions. I will file a bug for lldb error message. On Wed, Mar 9, 2016 at 5:57 PM, Jim Ingham wrote: > > > On Mar 9, 2016, at 3:04 PM, Jeffrey Tan via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > > > > Hi, > > > > My colleague is trying to use our lldb IDE attaching to app run/build > from Xcode which failed. I can reproduce this with lldb console: > > > > jeffreytan-mbp:$ ps aux | grep iOSApp > > jeffreytan 61816 0.0 0.0 2432772676 s002 S+3:00PM > 0:00.00 grep iOSApp > > jeffreytan 61806 0.0 0.2 2721120 38600 ?? SXs 3:00PM > 0:00.24 > /Users/jeffreytan/Library/Developer/CoreSimulator/Devices/EF17E202-3981-4DB0-87C9-2A9345C1E713/data/Containers/Bundle/Application/CAEBA7D7-D284-4489-8A53-A88E56F9BB04/iOSAppTest.app/iOSAppTest > > jeffreytan-mbp:$ lldb -p 61806 > > (lldb) process attach --pid 61806 > > error: attach failed: attach failed: unable to attach > > > > My theory is: > > 1. Xcode does not have the concept of run without debugger and run under > debugger, so it always run app with debugger enabled.(Is this true?) > > That is not true. In the Run Scheme, uncheck the "Debug Executable" > checkbox. But running with the debugger is the default. > > Note, an X in the status field for ps means the app is being debugged. So > in this case, the app you were trying to attach to WAS already being > debugged. > > > 2. And you can't have two native debuggers debugging the same process on > Mac(this is true on Windows, is it true for Mac or Linux?) > > That is true for Mac, and in general for ptrace based debugging. I don't > know much about procfs. > > > > > If both are true, can we report meaningful message like "inferior is > already being debugged" or something similar instead of the generic error > message like "attach failed: unable to attach"? > > That should be possible, there's code to eliminate already debugged > processes in the "Attach to process by name" functionality. So if you > specify a PID and the attach fails, we could check after the fact and see > if it is already being traced. Please file a bug for this, and/or take a > whack at fixing it if you feel like it. > > > > > Btw: I found I can still use gdb to attach to the process(with a > permission elevation dialog pop-up) and see the callstack. How does gdb do > that? > > I haven't looked at the FSF gdb OS X support for years, so I can't really > comment on it. But it is not possible to ptrace something that is already > ptraced, so if gdb is still doing it this way, then it should also fail. > Maybe it is only getting the mach task and exception ports and debugging > just with them? You can have multiple readers for the task port, and you > can steal the exception port from someone else. But if it did that, the > other debugger should stop working. > > Jim > > > > > > Jeffrey > > ___ > > lldb-dev mailing list > > lldb-dev@lists.llvm.org > > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > > ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
