Re: [lldb-dev] LLDB + UE4 on Android

[Pavel Labath via lldb-dev]

Hi Mikhail,

Modifying the build tool to include the build ID would probably be the
easiest solution to your problem. Please not that both the stripped
AND unstripped versions of the module need to have the (same)
.note.gnu.build-id section. I am not familiar with the build tool, but
"fixing" this should be as simple as adding "-Wl,--build-id" to your
compiler arguments for building the full .so. The subsequent strip
step should not remove the build-id (unless the tool uses some very
aggressive strip arguments).

Other possible solution would be to fix lldb to work in a
build-id-less scenario. We have been discussing trying to support this
just yesterday, but it's not yet clear when/if will that happen. The
problem there is that currently LLDB (in the ObjectFileELF snippet you
posted) falls back to computing a CRC of the whole module as its
"identity" if it cannot find a build it, which is not really working
as the CRC changes during stripping. One possible solution would be to
just do a checksum of only the allocatable ELF sections of the module,
which should hopefully create a strip-resistible identifier. If you're
interested in making this work, I think this would be a nice
improvement to lldb in general, and it should fix your problem.

let me know if you have further questions,
pl

On 9 March 2016 at 21:33, Mikhail Filimonov  wrote:
> 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

Re: [lldb-dev] What's the purpose of the TestStarted-XXX and TestFinished-XXX files?

[Pavel Labath via lldb-dev]

I don't think anyone is relying on these. We should just stop creating
them altogether.

We are using the *.log files to track test results over time, but we
don't need these files there. You can detect crashing tests by the
fact that the log files don't have a "TestResult-" (Success, Failure,
Error, ...) prefix. We have a script for doing that here
,
but it's very specific to our buildbot setup, so it may not be very
useful to you...



On 9 March 2016 at 23:04, Greg Clayton via lldb-dev
 wrote:
> 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 mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] Not able to find process plugin for core file

[Bhushan Attarde via lldb-dev]

Hi All,

I am working on adding support for MIPS coredump file in LLDB.

I tried below command:

(lldb) target create "app_mips.elf" --core "core_mips"
error: Unable to find process plug-in for core file '/home/battarde/test/ 
core_mips'

Currently LLDB is not able to find a Process plugin for MIPS core file. I 
debugged this and found that while finding the process plugin, 
"ProcessElfCore::CanDebug" calls "ModuleList::GetSharedModule"
to create a Module for corefile. But Module constructor in Module.cpp has this:

// First extract all module specifications from the file using the local
// file path. If there are no specifications, then don't fill anything in
ModuleSpecList modules_specs;
if (ObjectFile::GetModuleSpecifications(module_spec.GetFileSpec(), 0, 0, 
modules_specs) == 0)
return;

The issue here is that the targets like MIPS depends on elf flags to determine 
the actual architecture but core file doesn't contain any arch information 
(header.e_flags is 0) so it can't decide the arch contained in core file.
As no specifications are found, Module constructor takes an early exit leaving 
its members uninitialized.

Going further, Module also fails to get the ObjectFile representation as it 
doesn't contain enough information (Module::m_file, Module::m_arch) required to 
get ObjectFile.

So, "ProcessElfCore::CanDebug" returns false and because of this LLDB gives 
error saying that it is unable to find process plug-in for core file.

I can make mipsVariantFromElfFlags() to return some default architecture (to 
ensure we always have valid arch when it can't be decided from elf flags) but 
this won't always work (core's default arch and executable_elf's arch may not 
"match" always).
What could be the proper fix to this issue?
___
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?

[Adrian McCarthy via lldb-dev]

Thanks.  I have a patch out that removes the files that I'll probably
submit today.

On Thu, Mar 10, 2016 at 1:44 AM, Pavel Labath  wrote:

> I don't think anyone is relying on these. We should just stop creating
> them altogether.
>
> We are using the *.log files to track test results over time, but we
> don't need these files there. You can detect crashing tests by the
> fact that the log files don't have a "TestResult-" (Success, Failure,
> Error, ...) prefix. We have a script for doing that here
> <
> https://android.googlesource.com/platform/external/lldb-utils/+/lldb-master-dev/buildbotScripts/logParser/doParse.py
> >,
> but it's very specific to our buildbot setup, so it may not be very
> useful to you...
>
>
>
> On 9 March 2016 at 23:04, Greg Clayton via lldb-dev
>  wrote:
> > 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 <
> lldb-dev@lists.llvm.org> 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 mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] LLDB + UE4 on Android

[Mikhail Filimonov via lldb-dev]

Well, after I've added .gnu_debuglink section to stripped libUE4.so LLDB 
managed to resolve the symbols.
But sometimes it asserts with the following message:
---
Microsoft Visual C++ Runtime Library
---
Assertion failed!
Program: ...ORPORATION\NSIGHT TEGRA\3.3.16035.4243\liblldb.dll
File: C:\wrk\llvm_git\tools\clang\lib\AST\Recor...tBuilder.cpp
Line: 82
Expression: FieldOffsets.count(FD) && "Field does not have an external offset"
For information on how your program can cause an assertion
failure, see the Visual C++ documentation on asserts
(Press Retry to debug the application - JIT must be enabled)
---
Abort   Retry   Ignore   
---
Any suggestions how to debug that?

Regards,
Mikhail

-Original Message-
From: Mikhail Filimonov 
Sent: Thursday, March 10, 2016 12:33 AM
To: lldb-dev@lists.llvm.org
Cc: Tamas Berghammer ; Pavel Labath 
Subject: 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

Re: [lldb-dev] DWARFASTParserClang and DW_TAG_typedef for anonymous structs

[Luke Drummond via lldb-dev]

Hi Greg

First of all thanks for taking the time to help out with this.

On 10/03/16 00:18, Greg Clayton wrote:

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?


In the case of C89/C99, yes, but regrettably when you compile my example 
as C++ or use __attribute__((overloadable)) the DWARF does not include 
the DW_AT_name for the typedef in the formal parameter[0] of myfunc


COMPILE_UNIT:
< 0><0x000b>  DW_TAG_compile_unit
DW_AT_producer  "GNU C++ 4.8.4 
-mtune=generic -march=x86-64 -g -fstack-protector"

DW_AT_language  DW_LANG_C_plus_plus
DW_AT_name  "main.cpp"
DW_AT_comp_dir

[lldb-dev] [Bug 26901] New: LLDB should report meaningful error message during SBTarget creation and launch/attach

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=26901

Bug ID: 26901
   Summary: LLDB should report meaningful error message during
SBTarget creation and launch/attach
   Product: lldb
   Version: 3.8
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: jeffrey.fu...@gmail.com
CC: llvm-b...@lists.llvm.org
Classification: Unclassified

1. Use lldb attaching to a process already being debugged by another lldb
shows:
error: attach failed: attach failed: unable to attach

Expected:
Inferior/process is already being debugged.

2. On Linux, try to attach a root account process shows:
error: attach failed: attach failed: unable to attach

Expected:
You do not have permission to attach target process.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] How to attach process under root/different user account?

[Jeffrey Tan via lldb-dev]

Hi,

As the title said, what is the recommended way to attach a process under
different user account?

On Mac OS, when I try to use python binding to attach a root process, I got
a dialog saying "python is trying to take control of a root process ...".
After inputing password into the dialog, I got failure:
"Problems with launching via XPC. XPC error: Connection interrupted"

For Linux scenario, our IDE runs on MacOS, while using a RPC framework
talking to a IDE server on Linux devserver. This IDE server will use lldb
python binding to attach target process on Linux.
Is there any good way to attach root process on Linux devserver without
running IDE server under root account?

I guess I may need a UI/channel to gather user credential and elevate lldb
python binding process in some way. But a bit vague in this part. Thanks
for any input!

Jeffrey
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] announcing an *early preview* of a cross-referencing code search website for LLVM

[Peter Collingbourne via lldb-dev]

Hi,

I've found that one of the most useful tools in the Chromium project is its
code search website, http://cs.chromium.org/

At http://llvm-cs.pcc.me.uk/ you will find something similar for llvm. You
can search the full text of the llvm/clang/lld/lldb repositories using
regular expressions, search for declarations (which are prioritized above
full-text results), and follow cross references between definitions and
references.

The code behind this website is based on kythe [1] (Kythe itself uses the
clang libraries to parse C++ code) and Russ Cox's codesearch [2] library.
I'm planning to open source it and contribute it to the kythe project.

Thanks,
-- 
Peter

[1] http://kythe.io/
[2] https://github.com/google/codesearch
___
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

[Greg Clayton via lldb-dev]

> On Mar 9, 2016, at 5:40 PM, Jeffrey Tan  wrote:
> 
> 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?

No, this one is code signed with an Apple certificate which is trusted by the 
system.

> Only the app launched from Xcode IDE can't be attached from this lldb.

Try using "xcrun lldb" instead of /usr/bin/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 
> >  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] Not able to find process plugin for core file

[Greg Clayton via lldb-dev]

> On Mar 10, 2016, at 4:34 AM, Bhushan Attarde via lldb-dev 
>  wrote:
> 
> Hi All,
>  
> I am working on adding support for MIPS coredump file in LLDB.
>  
> I tried below command:
>  
> (lldb) target create "app_mips.elf" --core "core_mips"
> error: Unable to find process plug-in for core file '/home/battarde/test/ 
> core_mips’
>  
> Currently LLDB is not able to find a Process plugin for MIPS core file. I 
> debugged this and found that while finding the process plugin, 
> "ProcessElfCore::CanDebug" calls "ModuleList::GetSharedModule"
> to create a Module for corefile. But Module constructor in Module.cpp has 
> this:
>  
> // First extract all module specifications from the file using the local
> // file path. If there are no specifications, then don't fill anything in
> ModuleSpecList modules_specs;
> if (ObjectFile::GetModuleSpecifications(module_spec.GetFileSpec(), 0, 0, 
> modules_specs) == 0)
> return;
> 
> The issue here is that the targets like MIPS depends on elf flags to 
> determine the actual architecture but core file doesn't contain any arch 
> information (header.e_flags is 0) so it can't decide the arch contained in 
> core file.
> As no specifications are found, Module constructor takes an early exit 
> leaving its members uninitialized.
>  
> Going further, Module also fails to get the ObjectFile representation as it 
> doesn't contain enough information (Module::m_file, Module::m_arch) required 
> to get ObjectFile.
>  
> So, "ProcessElfCore::CanDebug" returns false and because of this LLDB gives 
> error saying that it is unable to find process plug-in for core file.
>  
> I can make mipsVariantFromElfFlags() to return some default architecture (to 
> ensure we always have valid arch when it can't be decided from elf flags) but 
> this won't always work (core's default arch and executable_elf's arch may not 
> "match" always).
> What could be the proper fix to this issue?

Try specifying a full triple when creating the target:


(lldb) target create --arch=mips32-pc-linux "app_mips.elf" --core "core_mips"

If any ELF file is unable to figure out its file type, it should leave things 
generic so the triple for the core ELF file should be something like: 
"mips-*-*". If that is true, then this should match your more specific triple 
specified in the target of "mips32-pc-linux". 

Try out specifying the triple and let me know how that goes. 

Greg Clayton
___
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

[Greg Clayton via lldb-dev]

Thanks for the example, this is indeed a new regression. It used to work (Xcode 
7.2), but now with top of tree it doesn't. Sean Callanan recently pulled out a 
bunch of work around we used to have in the expression/JIT so that we can avoid 
certain issues that were caused by said work arounds, and those are causing 
problems now. I looked at the old expression parser and it will still making up 
the name _Z6myfuncP3$_0, but it would first try the mangled name, and if it 
didn't find that, then it would fall back to just looking for the demangled 
basename ("myfunc"). We removed this work around because now we are trying to 
be more correct, and that caused this regression. Sean Callanan will take a 
look at this and get a fix for it sometime soon. What is probably happening is 
we are removing the typedef sugar from the function arguments somewhere that we 
shouldn't be (like maybe in the clang::ASTImporter or our 
lldb_private::ClangASTImporter). We should be trying to lookup the mangle name 
"_Z6myfuncP18my_untagged_struct", but somehow when we go to lookup the type we 
lost the my_untagged_struct and are looking for an anonymous struct "$_0" 
instead.

Greg Clayton

> On Mar 10, 2016, at 10:20 AM, Luke Drummond  
> wrote:
> 
> Hi Greg
> 
> First of all thanks for taking the time to help out with this.
> 
> On 10/03/16 00:18, Greg Clayton wrote:
>> 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" )
>>  

Re: [lldb-dev] DWARFASTParserClang and DW_TAG_typedef for anonymous structs

[Greg Clayton via lldb-dev]

Please file a bug for this and I will relate it to our internal apple bug that 
tracks this issue.

> On Mar 10, 2016, at 2:03 PM, Greg Clayton via lldb-dev 
>  wrote:
> 
> Thanks for the example, this is indeed a new regression. It used to work 
> (Xcode 7.2), but now with top of tree it doesn't. Sean Callanan recently 
> pulled out a bunch of work around we used to have in the expression/JIT so 
> that we can avoid certain issues that were caused by said work arounds, and 
> those are causing problems now. I looked at the old expression parser and it 
> will still making up the name _Z6myfuncP3$_0, but it would first try the 
> mangled name, and if it didn't find that, then it would fall back to just 
> looking for the demangled basename ("myfunc"). We removed this work around 
> because now we are trying to be more correct, and that caused this 
> regression. Sean Callanan will take a look at this and get a fix for it 
> sometime soon. What is probably happening is we are removing the typedef 
> sugar from the function arguments somewhere that we shouldn't be (like maybe 
> in the clang::ASTImporter or our lldb_private::ClangASTImporter). We should 
> be trying to lookup the mangle name "_Z6myfuncP18my_untagged_struct", but 
> somehow when we go to lookup the type we lost the my_untagged_struct and are 
> looking for an anonymous struct "$_0" instead.
> 
> Greg Clayton
> 
>> On Mar 10, 2016, at 10:20 AM, Luke Drummond  
>> wrote:
>> 
>> Hi Greg
>> 
>> First of all thanks for taking the time to help out with this.
>> 
>> On 10/03/16 00:18, Greg Clayton wrote:
>>> 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 )
>>> A

Re: [lldb-dev] announcing an *early preview* of a cross-referencing code search website for LLVM

[Shahms King via lldb-dev]

Nice! Glad to see some work progressing on a UI :-)

--Shahms

On Thu, Mar 10, 2016 at 11:26 AM, Peter Collingbourne 
wrote:

> Hi,
>
> I've found that one of the most useful tools in the Chromium project is
> its code search website, http://cs.chromium.org/
>
> At http://llvm-cs.pcc.me.uk/ you will find something similar for llvm.
> You can search the full text of the llvm/clang/lld/lldb repositories using
> regular expressions, search for declarations (which are prioritized above
> full-text results), and follow cross references between definitions and
> references.
>
> The code behind this website is based on kythe [1] (Kythe itself uses the
> clang libraries to parse C++ code) and Russ Cox's codesearch [2] library.
> I'm planning to open source it and contribute it to the kythe project.
>
> Thanks,
> --
> Peter
>
> [1] http://kythe.io/
> [2] https://github.com/google/codesearch
>



-- 
:-P
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev