Re: [Lldb-commits] [PATCH] D37923: Implement interactive command interruption

2017-09-20 Thread Zachary Turner via lldb-commits
On Tue, Sep 19, 2017 at 7:12 PM Jason Molenda wrote: > > > > On Sep 19, 2017, at 6:57 PM, Zachary Turner via lldb-commits < > lldb-commits@lists.llvm.org> wrote: > > > > > > > > After some additional thought, I stilled think testing below the sb api > layer is more appropriate. > > While Xcode

Re: [Lldb-commits] [lldb] r313655 - Re-land r313210 - Fix for bug 34532 - A few rough corners related to post-mortem debugging (core/minidump)

2017-09-20 Thread Ed Maste via lldb-commits
On 19 September 2017 at 14:07, Adrian McCarthy via lldb-commits wrote: > Author: amccarth > Date: Tue Sep 19 11:07:33 2017 > New Revision: 313655 > > URL: http://llvm.org/viewvc/llvm-project?rev=313655&view=rev > Log: > Re-land r313210 - Fix for bug 34532 - A few rough corners related to > post-m

Re: [Lldb-commits] [PATCH] D37923: Implement interactive command interruption

2017-09-20 Thread Jim Ingham via lldb-commits
One of the fundamental goals of lldb is that it be an extensible debugger. The extension mechanism for command line lldb all runs through the SB API through either Python or C++ (though most folks choose to use Python). We know first hand that many people take advantage this mechanism to add c

Re: [Lldb-commits] [PATCH] D37923: Implement interactive command interruption

2017-09-20 Thread Zachary Turner via lldb-commits
On Wed, Sep 20, 2017 at 10:33 AM Jim Ingham wrote: > One of the fundamental goals of lldb is that it be an extensible > debugger. The extension mechanism for command line lldb all runs through > the SB API through either Python or C++ (though most folks choose to use > Python). We know first ha

Re: [Lldb-commits] [PATCH] D37923: Implement interactive command interruption

2017-09-20 Thread Jim Ingham via lldb-commits
Directly WRT testing. I’m not against ALSO adding gtests when you add some functionality. But when your change is actually adding behaviors to lldb, one of the things you need to ask yourself is if this is functionality that extension developers for lldb will benefit from. If it is, then addi

Re: [Lldb-commits] [PATCH] D37923: Implement interactive command interruption

2017-09-20 Thread Zachary Turner via lldb-commits
On Wed, Sep 20, 2017 at 10:46 AM Jim Ingham wrote: > Directly WRT testing. I’m not against ALSO adding gtests when you add > some functionality. But when your change is actually adding behaviors to > lldb, one of the things you need to ask yourself is if this is > functionality that extension d

[Lldb-commits] [lldb] r313785 - Fix the SIGINT handlers

2017-09-20 Thread Adrian McCarthy via lldb-commits
Author: amccarth Date: Wed Sep 20 11:09:39 2017 New Revision: 313785 URL: http://llvm.org/viewvc/llvm-project?rev=313785&view=rev Log: Fix the SIGINT handlers 1. Fix a data race (g_interrupt_sent flag usage was not thread safe, signals can be handled on arbitrary threads) 2. exit() is not signal

[Lldb-commits] [PATCH] D37926: Fix the SIGINT handlers

2017-09-20 Thread Adrian McCarthy via Phabricator via lldb-commits
This revision was automatically updated to reflect the committed changes. Closed by commit rL313785: Fix the SIGINT handlers (authored by amccarth). Changed prior to commit: https://reviews.llvm.org/D37926?vs=115473&id=116035#toc Repository: rL LLVM https://reviews.llvm.org/D37926 Files:

Re: [Lldb-commits] [PATCH] D37923: Implement interactive command interruption

2017-09-20 Thread Jim Ingham via lldb-commits
I write lots of tests. I don’t really think that the SB API’s are really a barrier to writing tests. The lldbinline tests are trivial to write and can even be made just as a transcription of an lldb command line session, so the barrier to entry is trivial. That is surely the easiest way to wr

Re: [Lldb-commits] [PATCH] D37923: Implement interactive command interruption

2017-09-20 Thread Zachary Turner via lldb-commits
On Wed, Sep 20, 2017 at 11:14 AM Jim Ingham wrote: > > The amount of test coverage lldb has at present has much more to do with > the very aggressive schedules lldb has been driven by since its inception > than any difficulties with writing tests IMHBSEO. > This probably applies to the folks at

Re: [Lldb-commits] [PATCH] D37923: Implement interactive command interruption

2017-09-20 Thread Jim Ingham via lldb-commits
> On Sep 20, 2017, at 11:25 AM, Zachary Turner wrote: > > > > On Wed, Sep 20, 2017 at 11:14 AM Jim Ingham > wrote: > > The amount of test coverage lldb has at present has much more to do with the > very aggressive schedules lldb has been driven by since its incepti

[Lldb-commits] [lldb] r313799 - Fix warning caused by new clang::BuiltinType::Float16 added in r312794

2017-09-20 Thread Ted Woodward via lldb-commits
Author: ted Date: Wed Sep 20 12:16:53 2017 New Revision: 313799 URL: http://llvm.org/viewvc/llvm-project?rev=313799&view=rev Log: Fix warning caused by new clang::BuiltinType::Float16 added in r312794 Modified: lldb/trunk/source/Symbol/ClangASTContext.cpp Modified: lldb/trunk/source/Symbol/C

[Lldb-commits] [PATCH] D37923: Implement interactive command interruption

2017-09-20 Thread Leonard Mosescu via Phabricator via lldb-commits
lemo updated this revision to Diff 116074. lemo added a comment. 1. Added SB APIs (SBCommandInterpreter::WasInterrupted()). This allows python commands to query for interrupt requests. 2. I talked offline with Zach and decided that the line_iterator would require more tinkering to get it to wor

[Lldb-commits] [PATCH] D37923: Implement interactive command interruption

2017-09-20 Thread Zachary Turner via Phabricator via lldb-commits
zturner accepted this revision. zturner added a comment. This revision is now accepted and ready to land. seems fine to me, I agree with the point about non-determinism, due to the nature of signals and the fact this is only intended to provide a best-effort interruption. https://reviews.llvm.

[Lldb-commits] FreeBSD kernel debugging fixes

2017-09-20 Thread Koropoff, Brian via lldb-commits
Greetings. I'm submitting a few patches that resolve issues I encountered when using lldb to symbolicate FreeBSD kernel backtraces. The problems mostly centered around FreeBSD kernel modules actually being relocatable (.o) ELF Files. The major problems: - Relocations were not being applied to th

Re: [Lldb-commits] FreeBSD kernel debugging fixes

2017-09-20 Thread Jason Molenda via lldb-commits
Regarding the overlapping files -- when lldb first loads multiple binaries (but does not have a running process), it doesn't know where to set the load addresses of these binaries so they are all 0-based (or if they have a specified load address in the object file, at that address). We rely on

[Lldb-commits] [PATCH] D37923: Implement interactive command interruption

2017-09-20 Thread Jim Ingham via Phabricator via lldb-commits
jingham accepted this revision. jingham added a comment. I don't quite understand the comment about signals adding indeterminacy. No signal delivery is required to test this part. The lldb driver has a sigint handler that calls SBDebugger::DispatchInputInterrupt. But since you aren't testing

Re: [Lldb-commits] FreeBSD kernel debugging fixes

2017-09-20 Thread Koropoff, Brian via lldb-commits
Jason, I'm setting the load addresses appropriately for all sections in my script. The problem is that the symbol map is internally indexed by the "file address", which is the virtual address that the ELF section asks to be loaded at, regardless of what the actual load address turns out to be:

Re: [Lldb-commits] [PATCH] D37923: Implement interactive command interruption

2017-09-20 Thread Leonard Mosescu via lldb-commits
> > I don't quite understand the comment about signals adding indeterminacy. > No signal delivery is required to test this part. The lldb driver has a > sigint handler that calls SBDebugger::DispatchInputInterrupt. But since > you aren't testing whether SIGINT actually calls DispatchInputInterrup

Re: [Lldb-commits] FreeBSD kernel debugging fixes

2017-09-20 Thread Jason Molenda via lldb-commits
Right, we always record symbol addresses as the offset to the section that contains them. The Address class in lldb is used everywhere for this. The Target has a SectionLoadList which tells us where each Section is loaded in memory -- this is how you translate an Address object to a load addre

[Lldb-commits] [PATCH] D37923: Implement interactive command interruption

2017-09-20 Thread Adrian McCarthy via Phabricator via lldb-commits
amccarth accepted this revision. amccarth added a comment. LGTM. But just a thought: Is it worth doing all the work to scan for line endings for the interruption points? What if, instead, it just printed the next _n_ characters on each iteration until the entire buffer has been printed. Sure

Re: [Lldb-commits] [PATCH] D37923: Implement interactive command interruption

2017-09-20 Thread Leonard Mosescu via lldb-commits
Yes, using line endings as split points is somewhat arbitrary, anything that's a reasonable compromise between interruption responsiveness and low interrupt polling overhead would do. I feel that the lines are somewhat nicer since arbitrary splitting may lead to confusion and/or formatting ugliness

Re: [Lldb-commits] FreeBSD kernel debugging fixes

2017-09-20 Thread Koropoff, Brian via lldb-commits
Jason, I'm performing address to symbol resolution after setting load addresses for all sections. It correctly identifies the module and section where the address resides, and in many cases gives correct results. However, because it translates the load address to a file address before indexing

Re: [Lldb-commits] [PATCH] D37923: Implement interactive command interruption

2017-09-20 Thread Jim Ingham via lldb-commits
> On Sep 20, 2017, at 4:16 PM, Leonard Mosescu wrote: > > I don't quite understand the comment about signals adding indeterminacy. No > signal delivery is required to test this part. The lldb driver has a sigint > handler that calls SBDebugger::DispatchInputInterrupt. But since you aren't >