Re: [lldb-dev] reply: reply?? lldb debug jit-compiled code with llvm on windows

[haifeng_q via lldb-dev]

Problem solved. JIT debugging can be performed On the windows.
  
 thank you very much!
  
  
  --  The original message --
  From: "Oleksiy Vyalov";;
 Data: 2015??12??3??AM 10:16
 Receive: " "; 
 Cc: "Zachary Turner"; "lldb-dev"; 
"Tamas Berghammer"; 
 Title: Re: [lldb-dev] reply: reply?? lldb debug jit-compiled code with llvm on 
windows

 

 Could you re-build lldb with http://reviews.llvm.org/D15172 and try to hit a 
breakpoint in jit code?  

 I'm using following setup to compile and run JIT code:
 ./build_release/bin/clang -c -O0 -g -emit-llvm ./jit_test.cpp  
./build_release/bin/lli -debugger-tune=lldb -jit-kind=mcjit 
~/projects/lldb/test/jit_test.bc


 
 On Mon, Nov 30, 2015 at 3:47 AM, Tamas Berghammer via lldb-dev 
 wrote:
  

  On Mon, Nov 30, 2015 at 10:18 AM haifeng_q  wrote:

  Question 1:
On the windows, I use the code implements a function (see debug_target.cpp) of 
JIT (see debug_target_process.cpp), but when generating debug information, no 
production .symtab section for information that leads LLDB get JIT debugging 
information .symtab failure , and then set a breakpoint to fail.
  LLDB command: lldb_result.txt
 JIT compilation results: debug_target.ll
  
  Question 2:
 How JIT debugging supported on Linux?
  
 I theory when a new function is JIT-ed then __jit_debug_register_code function 
is called where LLDB have a breakpoint set. When that breakpoint is hit then 
LLDB reads the JIT-ed elf file based on the information in 
__it_debug_descriptor and processes all debug info in it.
 

 In practice when I last tried JIT debugging with lldb and lli (few weeks ago) 
it get the notification for the new JIT-ed elf file but it processed only the 
eh_frame from it even though symtab and full debug info was also provided. Most 
likely there is some issue around the JIT breakpoint handling or around the elf 
file parsing code in LLDB what needs some investigation.
 
  thanks!

 

 -- The original message --
  From: "Zachary Turner";;
 Data: 2015??11??21?? AM 0:10
 Receive: "Tamas Berghammer"; " 
"; "lldb-dev"; 
 
 Title: Re: [lldb-dev] reply?? lldb debug jit-compiled code with llvm on windows

 

 Can you also try clang-cl and see if it works?

  On Fri, Nov 20, 2015 at 3:02 AM Tamas Berghammer via lldb-dev 
 wrote:

  I don't know how JIT debugging should work on WIndows with MSVC but I don't 
think LLDB support it in any way. What I wrote should be true on Linux (and on 
some related) systems. You might be able to get the same results on Windows if 
you use lli (LLVM based JIT runner) but I have no knowledge if it will work or 
not.

  On Fri, Nov 20, 2015 at 8:56 AM haifeng_q  wrote:

  My analysis of the code, the reasons are:
  
  Since the debugging process is MSVC compiler, there is no DWARF debugging 
information. So lldb get __jit_debug_register_code and __it_debug_descriptor 
symbol debugging process fails, and __jit_debug_register_code not support MSVC.

 I do not know whether correct?
 

 -- original message--
  From:"Tamas Berghammer";tbergham...@google.com;
 Date:2015??11??19?? PM 8:37
 receive: " "; "lldb-dev"; 
 
 Subject: Re: [lldb-dev] lldb debug jit-compiled code with llvm on windows

 

 In theory you don't have to do anything special to debug some JIT-ed code as 
everything should just work (based on the gdb jit interface). In practice I 
tried it out a few days ago and it wasn't working at all even in the case when 
the application is launched under LLDB (not with attach). LLDB was 
understanding the eh_frame for the JIT-ed code but didn't found the debug info 
for unknown reason. We should investigate it and try to fix it sometime. We 
(lldb for android developers) plan to do it sometime but if you are interested 
in it then please feel free to take a look and let us know if you have any 
question.  

 Tamas


  On Thu, Nov 19, 2015 at 8:40 AM haifeng_q via lldb-dev 
 wrote:

  hi,
 process A generate function Func1 code with llvm jit compiler, and calls 
Func1. modeled on "Kaleidoscope: Adding Debug Information" add debug 
information. how to use LLDB to attach process A to debug this function, add a 
breakpoint in the function?
  
 thanks!
___
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 

Re: [lldb-dev] New test summary results formatter

[Pavel Labath via lldb-dev]

There is already code that enforces unique names (see dotest.py:1255).
I added this a while back because we were getting test flakyness
because of that. I don't remember the exact reason but I think it had
something to do with the log file names clashes, as all logs are
placed in the same folder.

I agree that it is possible to have multiple test files with the same
name, and still have the names meaningful, but then we need to make
sure that the it actually works reliably.


As for the results formatter, I like the new output a lot. For me, the
inability to recognize crashes is a blocker for using it, but once
that works, I would definitely be in favor of making the default.


I would welcome shortening of the test names, but that is of secondary
significance for me.

great job,
pl


On 3 December 2015 at 06:20, Todd Fiala via lldb-dev
 wrote:
>
>
> On Wed, Dec 2, 2015 at 9:48 PM, Zachary Turner  wrote:
>>
>>
>>
>> On Wed, Dec 2, 2015 at 9:44 PM Todd Fiala  wrote:
>>>
>>>

 and the classname could be dropped (there's only one class per file
 anyway, so the classname is just wasted space)
>>>
>>>
>>> Part of the reason I included that is I've hit several times where copy
>>> and paste errors lead to the same class name, method name or even file name
>>> being used for a test.  I think, though, that most of those are addressed by
>>> having the path (relative is fine) to the python test file.  I think we can
>>> probably get by with classname.methodname (relative test path).  (From your
>>> other email, I think you nuke the classname and keep the module name, but
>>> I'd probably do the reverse, keeping the class name and getting rid of the
>>> module name since it can be derived from the filename).
>>
>> I don't think the filename can be the same anymore, as things will break
>> if two filenames are the same.
>
>
> Maybe, but that wasn't my experience as of fairly recently.  When tracking
> failures sometime within the last month, I tracked something down in a
> downstream branch with two same-named files that (with the legacy output)
> made it hard to track down what was actually failing given the limited info
> of the legacy test summary output.  Maybe that has changed since then, but
> I'm not aware of anything that would have prohibited that.
>
>>
>>   We could go one step further and enforce this in the part where it scans
>> for all the tests.
>
>
> I think I can come up with a valid counterargument to doing that.  I could
> imagine some python .py files being organized hierarchically, where some of
> the context of what is being tested clearly comes from the directory
> structure.
>
> Something like (I'm making this up):
>
> lang/c/const/TestConst.py
> lang/c++/const/TestConst.py
>
> where it seems totally reasonable to me to have things testing const support
> (in this example) but being very different things for C and C++, being
> totally uniqued by path rather than the .py file.  I'd prefer not to require
> something like this to say:
> lang/c/const/TestConstC.py
> lang/c++/const/TestConstC++.py
>
> as it is redundant (at least via the path hierarchy).
>
> The other reason I could see avoiding that
> unique-test-basenames-across-test-suite restriction is that it can become
> somewhat of an unnecessary burden on downstream branches.  Imagine somebody
> has a branch and has a test that happens to be running fine, then somebody
> in llvm.org lldb adds a test with the same name.  Downstream breaks.  We
> could choose to not care about that, but given that a lot of our tests will
> revolve around language features accessed/provided by the debugger, and a
> number of language features pull out of a limited set of feature names (e.g.
> const above), I could see us sometimes hitting this.
>
> Just one take on it.  I'm not particularly wedded to it (I probably would
> avoid the confusion by doing something exactly like what I said above with
> regards to tacking on the language to the test name), but I have hit this in
> similar form across different language tests.
>
>>
>>   If it finds two test files with the same name we could just generate an
>> error.  I think that's a good idea anyway, because if two test files have
>> the same name, then the tests inside must be similar enough to warrant
>> merging them into the same file.
>
>
> Maybe, but not in the real cases I saw across different languages.  I think
> for other areas of the debugger, this isn't an issue.  So maybe language
> feature tests just have to know to append their language (whether it be C,
> C++, ObjC, etc.)
>
>>
>>
>> If no two filenames are the same, and if there's only 1 class per file,
>> then filename + method name should uniquely identify a single test, and so
>> you could omit the class name and show a relative path to the filename.
>
>
> I think we currently have some tests that have multiple test classes in the
> test file.  We could certainly 

[lldb-dev] LLDB and Swift

[Todd Fiala via lldb-dev]

Hi all,

Earlier today, you may have heard that Swift went open source over at
swift.org.  I just wanted to take a moment to mention the Swift debugger
and REPL and how they relate to LLDB.

Swift’s Debugger and REPL are built on LLDB’s source-level plug-in
architecture.  As such, the Swift Debugger repository at
github.com/apple/swift-lldb naturally contains the LLDB source from llvm.org’s
LLDB repository, plus additions for Swift language support. We merge
regularly and make every attempt to minimize our differences with llvm.org’s
LLDB.  For more information on how we’re handling this, have a look at
swift.org/contributing/#llvm-and-swift.

As we’ve worked hard to make it straightforward to develop additive-only
language support in LLDB, the Swift support can readily be found by finding
the new files in the swift-lldb repository vs. those found at
llvm.org/svn/llvm-project/lldb/trunk.  For the rest of the LLDB files in
common, we do still have a small number of diffs in
github.com/apple/swift-lldb vs. llvm.org TOT.  We will work through
upstreaming these quickly.  I’ll touch on some of those differences briefly
here:

* Several minor places where full language abstraction hasn’t yet occurred,
where we’re explicitly checking for Swift-related details.  Abstracting out
those remaining places and providing the hooks in llvm.org LLDB will
benefit all languages.

* Printed-form version string handling.  The ‘lldb -v’ and ‘(lldb) version’
commands create a different version string in both Xcode and cmake-based
Swift LLDB.  We will work to incorporate this into llvm.org LLDB once the
language/component version support info is properly abstracted out.

* Test infrastructure.  There are a few places where Swift language support
(e.g. swift compiler flags, runtime support directories, etc.) are added in
order to enable building Swift-based test inferiors.  We may be able to
rearrange things to make those language-specific additions more readily
pluggable in the core LLDB test runner.

We look forward to upstreaming the differences in common files in the
coming days and weeks.

Please feel free to contact me if you have any questions.

Thanks!

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

Re: [lldb-dev] LLDB and Swift

[Kamil Rytarowski via lldb-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Very nice. Congrats on your release!

On 04.12.2015 00:03, Todd Fiala via lldb-dev wrote:
> Hi all,
> 
> Earlier today, you may have heard that Swift went open source over 
> at swift.org .  I just wanted to take a moment
> to mention the Swift debugger and REPL and how they relate to
> LLDB.
> 
> Swift’s Debugger and REPL are built on LLDB’s source-level plug-in 
> architecture.  As such, the Swift Debugger repository at
> github.com/apple/swift-lldb 
> naturally contains the LLDB source from llvm.org
> ’s LLDB repository, plus additions for Swift
> language support. We merge regularly and make every attempt to 
> minimize our differences with llvm.org ’s LLDB.
> For more information on how we’re handling this, have a look at
> swift.org/contributing/#llvm-and-swift 
> .
> 
> As we’ve worked hard to make it straightforward to develop
> additive-only language support in LLDB, the Swift support can
> readily be found by finding the new files in the swift-lldb
> repository vs. those found at llvm.org/svn/llvm-project/lldb/trunk 
> .  For the rest of
> the LLDB files in common, we do still have a small number of diffs 
> in github.com/apple/swift-lldb 
> vs. llvm.org  TOT.  We will work through
> upstreaming these quickly.  I’ll touch on some of those differences
> briefly here:
> 
> * Several minor places where full language abstraction hasn’t yet 
> occurred, where we’re explicitly checking for Swift-related
> details. Abstracting out those remaining places and providing the
> hooks in llvm.org  LLDB will benefit all
> languages.
> 
> * Printed-form version string handling.  The ‘lldb -v’ and ‘(lldb) 
> version’ commands create a different version string in both Xcode
> and cmake-based Swift LLDB.  We will work to incorporate this into
> llvm.org  LLDB once the language/component
> version support info is properly abstracted out.
> 
> * Test infrastructure.  There are a few places where Swift
> language support (e.g. swift compiler flags, runtime support
> directories, etc.) are added in order to enable building
> Swift-based test inferiors.  We may be able to rearrange things to
> make those language-specific additions more readily pluggable in
> the core LLDB test runner.
> 
> We look forward to upstreaming the differences in common files in
> the coming days and weeks.
> 
> Please feel free to contact me if you have any questions.
> 
> Thanks!
> 
> -Todd
> 
> 
> ___ lldb-dev mailing
> list lldb-dev@lists.llvm.org 
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> 

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWYOYqAAoJEEuzCOmwLnZsyVMP/0pC9Vahn0ErYFeBQoaXA3Qx
FFr7dAIMAyC+tH0Rb2virNLsrozgNXAnV06vfS2fdt1nB2sVwFDeZvtscjRCY0BC
w8v5N0joKb0Ao2RJcazCLJYOEihTc9thsBSQFDzQ3UIMJ5f5FIhykcSDecIh3OTQ
Hb2FGzTsFbdRLQvu6XwagaxT0n5PL3IG7BIRVLgQl988ICJvGNFDub7/7Ylee52b
oLtkxRhMMn9n2UXGPahQ6WozKfjc/l5s6isAp3bdkH4GEyTIv+D7/CKUmvLyZxaP
L75JS0g/bb++uMY+2naKzCrTYm7Se2hopIvbvgf7vkTIrLBUZt8JtJ7qkKkiwTL3
iW4oOiXUTz0pFQ6g2vdCGBM1263iPxS816JxLtW+aB4Gj/qhuzoTTseb7+KvFCVs
5PG87p7L6pm5TKswX+Cf6Di0O5fqyUFwk06hB9wuck6iCbT5dl4Zkty0OKsh/mnb
RSztbQn9BpCbMDiZe2wv5y8H8kaMvaNvnODqNdK6C94M4km6AD7YNx0WFMPkPrL5
IfLzGZau89ejrmJIU9SKW7HJRn+luIxjr2sa3BVGV+cZP4wUm9Z+d91Q6DPXwKv0
MBdb7ISPGqW13yYHYJ9dK/pKFjHiMFMjIzBsMvItqvN3Xy3GmHDIm80G6jzu7Wj0
VipucL5yeiHkTIJNccs8
=qRiS
-END PGP SIGNATURE-
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] LLDB and Swift

[Todd Fiala via lldb-dev]

Thanks, Kamil!

-Todd

> On Dec 3, 2015, at 5:02 PM, Kamil Rytarowski  wrote:
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Very nice. Congrats on your release!
> 
>> On 04.12.2015 00:03, Todd Fiala via lldb-dev wrote:
>> Hi all,
>> 
>> Earlier today, you may have heard that Swift went open source over 
>> at swift.org .  I just wanted to take a moment
>> to mention the Swift debugger and REPL and how they relate to
>> LLDB.
>> 
>> Swift’s Debugger and REPL are built on LLDB’s source-level plug-in 
>> architecture.  As such, the Swift Debugger repository at
>> github.com/apple/swift-lldb 
>> naturally contains the LLDB source from llvm.org
>> ’s LLDB repository, plus additions for Swift
>> language support. We merge regularly and make every attempt to 
>> minimize our differences with llvm.org ’s LLDB.
>> For more information on how we’re handling this, have a look at
>> swift.org/contributing/#llvm-and-swift 
>> .
>> 
>> As we’ve worked hard to make it straightforward to develop
>> additive-only language support in LLDB, the Swift support can
>> readily be found by finding the new files in the swift-lldb
>> repository vs. those found at llvm.org/svn/llvm-project/lldb/trunk 
>> .  For the rest of
>> the LLDB files in common, we do still have a small number of diffs 
>> in github.com/apple/swift-lldb 
>> vs. llvm.org  TOT.  We will work through
>> upstreaming these quickly.  I’ll touch on some of those differences
>> briefly here:
>> 
>> * Several minor places where full language abstraction hasn’t yet 
>> occurred, where we’re explicitly checking for Swift-related
>> details. Abstracting out those remaining places and providing the
>> hooks in llvm.org  LLDB will benefit all
>> languages.
>> 
>> * Printed-form version string handling.  The ‘lldb -v’ and ‘(lldb) 
>> version’ commands create a different version string in both Xcode
>> and cmake-based Swift LLDB.  We will work to incorporate this into
>> llvm.org  LLDB once the language/component
>> version support info is properly abstracted out.
>> 
>> * Test infrastructure.  There are a few places where Swift
>> language support (e.g. swift compiler flags, runtime support
>> directories, etc.) are added in order to enable building
>> Swift-based test inferiors.  We may be able to rearrange things to
>> make those language-specific additions more readily pluggable in
>> the core LLDB test runner.
>> 
>> We look forward to upstreaming the differences in common files in
>> the coming days and weeks.
>> 
>> Please feel free to contact me if you have any questions.
>> 
>> Thanks!
>> 
>> -Todd
>> 
>> 
>> ___ lldb-dev mailing
>> list lldb-dev@lists.llvm.org 
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> 
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2
> 
> iQIcBAEBCAAGBQJWYOYqAAoJEEuzCOmwLnZsyVMP/0pC9Vahn0ErYFeBQoaXA3Qx
> FFr7dAIMAyC+tH0Rb2virNLsrozgNXAnV06vfS2fdt1nB2sVwFDeZvtscjRCY0BC
> w8v5N0joKb0Ao2RJcazCLJYOEihTc9thsBSQFDzQ3UIMJ5f5FIhykcSDecIh3OTQ
> Hb2FGzTsFbdRLQvu6XwagaxT0n5PL3IG7BIRVLgQl988ICJvGNFDub7/7Ylee52b
> oLtkxRhMMn9n2UXGPahQ6WozKfjc/l5s6isAp3bdkH4GEyTIv+D7/CKUmvLyZxaP
> L75JS0g/bb++uMY+2naKzCrTYm7Se2hopIvbvgf7vkTIrLBUZt8JtJ7qkKkiwTL3
> iW4oOiXUTz0pFQ6g2vdCGBM1263iPxS816JxLtW+aB4Gj/qhuzoTTseb7+KvFCVs
> 5PG87p7L6pm5TKswX+Cf6Di0O5fqyUFwk06hB9wuck6iCbT5dl4Zkty0OKsh/mnb
> RSztbQn9BpCbMDiZe2wv5y8H8kaMvaNvnODqNdK6C94M4km6AD7YNx0WFMPkPrL5
> IfLzGZau89ejrmJIU9SKW7HJRn+luIxjr2sa3BVGV+cZP4wUm9Z+d91Q6DPXwKv0
> MBdb7ISPGqW13yYHYJ9dK/pKFjHiMFMjIzBsMvItqvN3Xy3GmHDIm80G6jzu7Wj0
> VipucL5yeiHkTIJNccs8
> =qRiS
> -END PGP SIGNATURE-
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] New test summary results formatter

[Zachary Turner via lldb-dev]

On Wed, Dec 2, 2015 at 10:20 PM Todd Fiala  wrote:

> On Wed, Dec 2, 2015 at 9:48 PM, Zachary Turner  wrote:
>
>>
>>
>> On Wed, Dec 2, 2015 at 9:44 PM Todd Fiala  wrote:
>>
>>>
>>>
 and the classname could be dropped (there's only one class per file
 anyway, so the classname is just wasted space)

>>>
>>> Part of the reason I included that is I've hit several times where copy
>>> and paste errors lead to the same class name, method name or even file name
>>> being used for a test.  I think, though, that most of those are addressed
>>> by having the path (relative is fine) to the python test file.  I think we
>>> can probably get by with classname.methodname (relative test path).  (From
>>> your other email, I think you nuke the classname and keep the module name,
>>> but I'd probably do the reverse, keeping the class name and getting rid of
>>> the module name since it can be derived from the filename).
>>>
>> I don't think the filename can be the same anymore, as things will break
>> if two filenames are the same.
>>
>
> Maybe, but that wasn't my experience as of fairly recently.  When tracking
> failures sometime within the last month, I tracked something down in a
> downstream branch with two same-named files that (with the legacy output)
> made it hard to track down what was actually failing given the limited info
> of the legacy test summary output.  Maybe that has changed since then, but
> I'm not aware of anything that would have prohibited that.
>
Well I only said "things" will break, not everything will break.  Most
likely you just didn't notice the problem or it didn't present itself in
your scenario.  There are definitely bugs surrounding multiple files with
the same name, because of some places where we use a dictionary keyed on
filename.


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

Re: [lldb-dev] New test summary results formatter

[Zachary Turner via lldb-dev]

Ahh I read further and see this was already mentioned by Pavel.

On Thu, Dec 3, 2015 at 10:06 AM Zachary Turner  wrote:

> On Wed, Dec 2, 2015 at 10:20 PM Todd Fiala  wrote:
>
>> On Wed, Dec 2, 2015 at 9:48 PM, Zachary Turner 
>> wrote:
>>
>>>
>>>
>>> On Wed, Dec 2, 2015 at 9:44 PM Todd Fiala  wrote:
>>>


> and the classname could be dropped (there's only one class per file
> anyway, so the classname is just wasted space)
>

 Part of the reason I included that is I've hit several times where copy
 and paste errors lead to the same class name, method name or even file name
 being used for a test.  I think, though, that most of those are addressed
 by having the path (relative is fine) to the python test file.  I think we
 can probably get by with classname.methodname (relative test path).  (From
 your other email, I think you nuke the classname and keep the module name,
 but I'd probably do the reverse, keeping the class name and getting rid of
 the module name since it can be derived from the filename).

>>> I don't think the filename can be the same anymore, as things will break
>>> if two filenames are the same.
>>>
>>
>> Maybe, but that wasn't my experience as of fairly recently.  When
>> tracking failures sometime within the last month, I tracked something down
>> in a downstream branch with two same-named files that (with the legacy
>> output) made it hard to track down what was actually failing given the
>> limited info of the legacy test summary output.  Maybe that has changed
>> since then, but I'm not aware of anything that would have prohibited that.
>>
> Well I only said "things" will break, not everything will break.  Most
> likely you just didn't notice the problem or it didn't present itself in
> your scenario.  There are definitely bugs surrounding multiple files with
> the same name, because of some places where we use a dictionary keyed on
> filename.
>
>
>>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev