Re: [lldb-dev] Attaching to a stopped (cored) process hangs lldb-server

[Jim Ingham via lldb-dev]

It's going to be quite difficult for lldb to do anything reasonable with the 
core file if we can't seek around in it.  So for practical purposes it is going 
to have to get stored somehow, either in a file or in some memory that lldb can 
do random access on.  So practically whoever is getting this stream will need 
to store it somewhere and hand the results to lldb.  So from lldb, adding an 
API that takes the core file from a chunk of memory seems fine.  But I'd leave 
it up to the clients to figure out how to cons up such a thing as they know 
their situation better (and most times just writing it to disk first is going 
to seem reasonable.)

BTW, if your platform has a network connection maybe you could stream the core 
out to a core server that has disk space. That would lessen the need for 
heroics on the lldb running on this limited resource platform?

Jim

> On Nov 4, 2015, at 10:14 AM, Mark Chandler via lldb-dev 
>  wrote:
> 
> Im not sure, but I assume that the kernel writes the core out as the process 
> reads it. Will need to dig into the kernel code to confirm.
> 
> 
> Mark Chandler
> Battle.Net Engineering Systems | Blizzard Entertainment
> (P) 949-955-1380 x15353
> 
> -Original Message-
> From: Greg Clayton [mailto:gclay...@apple.com] 
> Sent: Wednesday, November 04, 2015 10:13 AM
> To: Mark Chandler 
> Cc: Todd Fiala ; Pavel Labath ; 
> lldb-dev@lists.llvm.org
> Subject: Re: [lldb-dev] Attaching to a stopped (cored) process hangs 
> lldb-server
> 
> So the entire core file is in memory somehow and when it is read from STDIN 
> will be then be freed? Seems like a really lame way to pass the core file 
> around as it requires up to 2x the size of the core in memory. We could add a 
> new version of SBTarget::LoadCore() like:
> 
> SBProcess
> SBTarget::LoadCoreFromData(const void *data, uint64_t data_len);
> 
> But this will be a memory hog depending on if the memory from STDIN 
> containing the core file gets freed immediately after it is consumed, or if 
> the data is still around.
> 
> 
>> On Nov 4, 2015, at 10:05 AM, Mark Chandler  wrote:
>> 
>> The problem becomes when the core data on stdin is gigabytes in size and 
>> there is little to no diskspace or memory (as the process is still around) 
>> to store/process the data.
>> 
>> 
>> Mark Chandler
>> Battle.Net Engineering Systems | Blizzard Entertainment
>> (P) 949-955-1380 x15353
>> 
>> -Original Message-
>> From: Greg Clayton [mailto:gclay...@apple.com] 
>> Sent: Wednesday, November 04, 2015 10:01 AM
>> To: Todd Fiala 
>> Cc: Mark Chandler ; Pavel Labath 
>> ; lldb-dev@lists.llvm.org
>> Subject: Re: [lldb-dev] Attaching to a stopped (cored) process hangs 
>> lldb-server
>> 
>> 
>>> On Nov 4, 2015, at 9:47 AM, Todd Fiala  wrote:
>>> 
>>> Although doing any kind of waitpid() in the case of a core file doesn't 
>>> make sense.
>> 
>> The process is still around. The process is being handed the core file via 
>> STDIN, but the process is still around and this tool is attaching to that 
>> process and ignoring the core file data. I would vote to use the core file 
>> data if the tool is checked in, or at least provide an option to either 
>> attach to the process or use the core file data...
>> 
>> Greg
> 
> ___
> 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] Thread resumes with stale signal after executing InferiorCallMmap

[Jim Ingham via lldb-dev]

> On Oct 7, 2015, at 4:06 PM, Eugene Birukov  wrote:
> 
> Even on Linux call to InferiorCallMmap does not fail consistently. In many 
> cases it survives. I just happened to have 100% repro on this specific 
> breakpoint in my specific problem. I.e. the burden of investigation is on me, 
> since I cannot share my program. 
> 
> But I am not looking at this SIG_ILL yet. Whatever the problem is with mmap - 
> the client must not carry this signal past expression evaluation. I.e. I 
> believe that we can construct any arbitrary function that causes signal, call 
> it from evaluate expression, and then continue would fail. I suspect that 
> this problem might be applicable to any POSIX platform.

It doesn't happen on OS X, though when it comes to signal handling in the 
debugger OS X is an odd fish...

> 
> As it turned out, my initial analysis was incorrect. m_resume_signal is 
> calculated from StopInfo::m_value (now I wonder why do we need two fields for 
> that?).

The signal that you stop with is not necessarily the one you are going to 
resume with.  For instance, if you use "process handle SIG_SOMESIG -p 0" to 
tell lldb not to propagate the signal, then the resume signal will be nothing, 
even though the stop signal is SIG_SOMESIG.

> And after mmap call, m_stop_info on the thread is null. So, my current theory 
> is that there is an event with SIG_ILL that is stuck in the broadcaster and 
> is picked up and processed much later.

When the expression evaluation completes, the StopInfo from the last "natural" 
stop should be put back in place in the thread.  After all, if you hit a 
breakpoint, run an expression, then ask why that thread stopped, you want to 
see "hit a breakpoint" not "ran a function call".  Sounds like that is failing 
somehow.

Jim


> 
> > Subject: Re: [lldb-dev] Thread resumes with stale signal after executing 
> > InferiorCallMmap
> > From: jing...@apple.com
> > Date: Wed, 7 Oct 2015 15:08:18 -0700
> > CC: lldb-dev@lists.llvm.org
> > To: eugen...@hotmail.com
> > 
> > Does it only happen for InferiorCallMmap, or does an expression evaluation 
> > that crashes in general set a bad signal on resume? I don't see this 
> > behavior in either case on OS X, so it may be something in the Linux 
> > support. Be interesting to figure out why it behaves this way on Linux, so 
> > whatever we do we're implementing it consistently.
> > 
> > Jim
> > 
> > 
> > 
> > > On Oct 7, 2015, at 12:03 PM, Eugene Birukov via lldb-dev 
> > >  wrote:
> > > 
> > > Hi,
> > >  
> > > I am using LLDB 3.7.0 C++ API. My program stops at a certain breakpoint 
> > > and if I call SBFrame::EvaluateExpression() there, when I let it go it 
> > > terminates with SIG_ILL on an innocent thread. I dug up into this, and 
> > > there seems to be two independent problems there, this mail is about the 
> > > second one.
> > >  
> > > • EvaluateExpression() calls Process::CanJIT() which in turn executes 
> > > mmap() on the inferior. This mmap gets SIG_ILL because execution starts 
> > > at address which is 2 bytes before the very first mmap instruction. I am 
> > > still looking why LLDB server decided to do that - I am pretty sure that 
> > > the client asked to set the program counter to correct value.
> > > • So, the thread execution terminates and the signal is recorded on 
> > > Thread::m_resume_signal. This field is not cleared during 
> > > Thread::RestoreThreadStateFromCheckpoint() and fires when I resume the 
> > > program after breakpoint.
> > >  
> > > So, what would be the best way to deal with the situation? Should I add 
> > > "resume signal" field to ThreadStateCheckpoint? Or would StopInfo be a 
> > > better place for that? Or something else?
> > >  
> > > Thanks,
> > > Eugene
> > > ___
> > > 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] Accessing DWARF information from C++

[Jim Ingham via lldb-dev]

> On Oct 13, 2015, at 9:03 AM, Stefan Kratochwil via lldb-dev 
>  wrote:
> 
> Hi,
> 
> well, I found the llvm-dwarfdump tool in the tools directory *facepalm*...
> I'll use that as a reference.
> 
> That leaves the question about the two separate DWARF implementations.

Ideally it would be good to try to merge the two implementations.  However, 
lldb's usage patterns - doing focused queries, only unpacking as little of the 
DWARF as it can possibly manage to satisfy such queries, etc, are very 
different from those of a straight up dumper.  N.B. if you're not very careful 
how you handle debug information in the debugger you can get really dramatic 
performance problems particularly with large projects.  Since this is so 
crucial, we (mostly Greg) built lldb's DWARF reader as an experiment in 
supporting those patterns as efficiently as possible, rather than as a general 
purpose library.  So replacing the current implementation is not a task to be 
undertaken lightly.  To date, there hasn't been a compelling reason to do that 
work as opposed to all the other interesting stuff we could be doing.

Jim

> 
> Cheers,
> Stefan
> 
> On 10/13/2015 11:42 AM, Stefan Kratochwil via lldb-dev wrote:
>> Hi altogether,
>> 
>> I currently am developing an application where I need to access the
>> DWARF debugging information of my target process and its loaded .so files.
>> 
>> In more detail, I need to match type information of certain entities
>> within my code and its dynamically linked libraries.
>> 
>> 
>> I already use the lldb scripting bridge in my application, hence I would
>> like to use lldb's DWARF parsing capabilities in my application, too.
>> 
>> Now, there is no (obvious) way to extract DIEs using the C++ API, so I
>> need a few hints where to start. Does anyone have a minimal example for
>> simply dumping DWARF info in a 'readelf -w' manner?
>> 
>> 
>> I further  discovered another DWARF implementation within the llvm
>> sources. After some investigation I found this discussion on lldb-dev:
>> http://lists.cs.uiuc.edu/pipermail/lldb-dev/2014-June/004197.html
>> 
>> Does anybody know if there is already some effort made to implement a
>> lldwarf solution as a replacement for both mentioned implementations?
>> 
>> And, after going through the discussion, is it probably better for me to
>> use the llvm fork?
>> 
>> Thanks in advance!
>> 
>> 
>> Cheers,
>> Stefan
>> ___
>> 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 fails to hit breakpoint when line maps to multiple addresses

[Jim Ingham via lldb-dev]

> On Oct 7, 2015, at 5:07 PM, Jim Ingham  wrote:
> 
> Another way to do this - which I thought about originally but rejected as too 
> much delicate machinery for the desired effect - is to add the notion of 
> "clusters" of locations to the breakpoint.  Instead of eliding all the 
> segments with the same line number into one location, you'd make a location 
> per segment but treat them as a cluster, where a hit on one location in the 
> cluster would set a flag telling you to auto-continue the other locations in 
> the cluster till "something happened to reset the cluster".  You'd have to 
> figure out good heuristics for that "something happened".  You could probably 
> get away with "frame changed" and "hit the location that I hit the first time 
> I hit the cluster".  But I'd have to think a bit harder about this to assure 
> myself this was good enough.  And you'd have to keep a side table of history 
> for each breakpoint which you'd have to manage...  Nothing impossible, but it 
> didn't seem worth the effort at the time.
> 
> Anyway, if you are sufficiently motivated to give this a try, it would be a 
> more general solution to the problem without requiring user intervention - 
> either having to press continue some undetermined number of times, or create 
> the breakpoints with some special option.

BTW, Greg points out that one could teach the Thread Plans to treat step over a 
source line that has a breakpoint on it to do this job as well.  That will save 
you from having to store history information off to one side.  This approach 
might be worth pursuing, though I bet it will end up being trickier than it 
seems at first glance...

Jim


> 
>> 
>>> The motivation is that compilers in general and certainly clang in 
>>> particular love to put multiple line table entries in for a given line that 
>>> are either contiguous or interrupted by artificial book-keeping code.  So 
>>> if we didn???t coalesce these line entries, when you set a breakpoint on 
>>> such a line, you??d have to hit continue some unpredictable number of 
>>> times before you actually get past that line.  You could figure out how 
>>> many time by counting the number of locations, but nobody could be expected 
>>> to do that???  And if you are chasing multiple hits of the breakpoint 
>>> through code it was really a pain since one ???continue??? didn???t result 
>>> in one pass through the function containing the code. This happens very 
>>> frequently and was a font of bugs for lldb early on.
>> 
>> Understood - we get reports like this all the time, and I've also thought of
>> ways to workaround it, but for each idea I had, I could always find a way to
>> break it.  So now I tell users it "works as designed", and that it's better
>> to hit a BP a couple times than none at all.
>> 
>>> Note, this doesn???t affect the stepping algorithms, since when we step we 
>>> just look at where we land and if it has the same line number as we were 
>>> stepping through we keep going.  Of course, it also makes stepping over 
>>> such a line annoying for the same reason that it made continue annoying...
>> 
>> What about tail recursion?  You must at least check the stack ptr, no?
> 

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

Re: [lldb-dev] How does attach work on non-Windows?

[Jim Ingham via lldb-dev]

There is a way on OS X.  There is a sysctl that will give you information on 
the current process state, and one of the bits you get back says whether the 
process is being traced.  sysctl's are a generic UNIX thing, but I don't know 
if the bit OS X uses is shared with other Unix's.

Jim

 On Aug 26, 2015, at 2:20 PM, Zachary Turner via lldb-dev 
 lldb-dev@lists.llvm.org wrote:
 
 Slightly related, but do other platforms have a way to check from an inferior 
 if a debugger is present?
 
 We need to do this frequently from the test inferiors, and I see lots of 
 different approaches used in the test programs, none of which work correctly 
 on Windows.
 
 On Wed, Aug 26, 2015 at 2:09 PM Zachary Turner ztur...@google.com wrote:
 On Windows, when we attach to process, we basically invoke a system call 
 which tells the kernel to kick off the process necessary for a debugger to be 
 able to communicate with the process.
 
 The end result of all this is that eventually the OS itself will generate a 
 breakpoint in the inferior by injecting an additional thread into the 
 inferior and breaking on that thread.
 
 LLDB picks this up, and the result is that LLDB stops and waits for the user 
 to continue the inferior just as it would with any other breakpoint, and if 
 you were to get a backtrace you might see something like this:
 
 looking at: Stack traces for SBProcess: pid = 12588, state = stopped, threads 
 = 2, executable = test_with_dwarf_and_attach_to_process_with_id_api
 Stack trace for thread id=0x3428 name=None queue=None stop reason=none
   frame #0: 0x ntdll.dll`DbgBreakPoint + 1
 
 Stack trace for thread id=0x4314 name=None queue=None stop reason=none
   frame #0: 0x0077908c2c None`None + -18446744071703589843
 
 
 My question is: Do other platforms have this concept of an OS-generated 
 breakpoint?  Or when you attach to the process, would the first breakpoint 
 opcode encountered by the inferior be one which was created by the user 
 through some command from the debugger?
 
 This creates a problem for some of our tests, because we have this extra 
 breakpoint that is messing up the stack frame expectations unless we issue a 
 manual continue first to get past the initial breakpoitn and to the first 
 user breakpoint.
 ___
 lldb-dev mailing list
 lldb-dev@lists.llvm.org
 https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_lldb-2Ddevd=BQIGaQc=eEvniauFctOgLOKGJOplqwr=aTCVT7yw0RLKhx7ZXY2faboS3m1dhXpYF-Av4XoSGMUm=VvFNLC1Qe6kBmEoVqGF9NZIVrDnFQZBDYfsUdMRn1aEs=9o1ODu6v5nQisbSZVZpKU56ZDygZTcK6a_1juRJLhise=
  

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

Re: [lldb-dev] How does attach work on non-Windows?

[Jim Ingham via lldb-dev]

On OS X and most Unixes, you call ptrace(pid, PT_ATTACH) or some procfs call to 
initiate the attach, and then wait on the pid until it comes back with a 
SIGSTOP signal when the attach is completed.  How the wait is done differs from 
system to system, but this is the general model.  I have not heard of a UNIX 
that uses actual trap instructions placed by the kernel in the process to stop 
it.

Jim

 On Aug 26, 2015, at 2:09 PM, Zachary Turner via lldb-dev 
 lldb-dev@lists.llvm.org wrote:
 
 On Windows, when we attach to process, we basically invoke a system call 
 which tells the kernel to kick off the process necessary for a debugger to be 
 able to communicate with the process.
 
 The end result of all this is that eventually the OS itself will generate a 
 breakpoint in the inferior by injecting an additional thread into the 
 inferior and breaking on that thread.
 
 LLDB picks this up, and the result is that LLDB stops and waits for the user 
 to continue the inferior just as it would with any other breakpoint, and if 
 you were to get a backtrace you might see something like this:
 
 looking at: Stack traces for SBProcess: pid = 12588, state = stopped, threads 
 = 2, executable = test_with_dwarf_and_attach_to_process_with_id_api
 Stack trace for thread id=0x3428 name=None queue=None stop reason=none
   frame #0: 0x ntdll.dll`DbgBreakPoint + 1
 
 Stack trace for thread id=0x4314 name=None queue=None stop reason=none
   frame #0: 0x0077908c2c None`None + -18446744071703589843
 
 
 My question is: Do other platforms have this concept of an OS-generated 
 breakpoint?  Or when you attach to the process, would the first breakpoint 
 opcode encountered by the inferior be one which was created by the user 
 through some command from the debugger?
 
 This creates a problem for some of our tests, because we have this extra 
 breakpoint that is messing up the stack frame expectations unless we issue a 
 manual continue first to get past the initial breakpoitn and to the first 
 user breakpoint.
 ___
 lldb-dev mailing list
 lldb-dev@lists.llvm.org
 https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_lldb-2Ddevd=BQIGaQc=eEvniauFctOgLOKGJOplqwr=aTCVT7yw0RLKhx7ZXY2faboS3m1dhXpYF-Av4XoSGMUm=L-3KeVaOuHZA0PFZErpqOUVyPGhnBc0qTlAnlY2nL8As=dSTTA6Jqz1P1PNsAHJN-99X-FdcVufV3UTWsB3Defx0e=
  

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

Re: [lldb-dev] Test suite rebuilding test executables many times

[Jim Ingham via lldb-dev]

It is fairly common practice (at least it is for me) when figuring out why a 
test failed, or adding to a test case, or when looking for a good example file 
to poke at, etc, to go to some relevant test directory, do a make then poke 
around a bunch.  I don't generally remember to clean when I'm done.  If the 
test suite didn't do make clean before running the tests then I'd get whatever 
state I left the binaries in after that investigation.  So I prefer doing make 
clean the first time you run a test in a given directory, but I have no 
objection to trying not to do the clean on subsequent tests in the same 
directory.  Also we do dsym and then non-dsym builds in the same directory 
on OS X, so we'd have to make sure that we clean when switching back  forth 
between the two kinds of tests, or we will leave a dSYM around at some point 
and stop testing .o file debugging.  Now that support is coming in for dwo 
debugging on Linux, we probably should also add the ability to test normal  
dwo debugging there as well.  So this soon won't be just an OS X oddity...

Finally, there are some tests that rebuild the binaries on purpose - sadly I 
don't remember which ones.  If we're lucky they would fail if you switched the 
default and you could go fix them, but if you are unlucky they would succeed 
without actually testing what they were supposed to test.  So a little care 
would be needed to find these.

Jim

 On Aug 25, 2015, at 4:52 PM, Zachary Turner via lldb-dev 
 lldb-dev@lists.llvm.org wrote:
 
 Another possibility is changing the arguments to buildDwarf and buildDsym.  
 Currently they take a clean argument with a default value of True.  Does this 
 really need to be True?  If this were False by default it could drastically 
 speed up the test suite.  And I can't think of a reason why make clean would 
 need to run by default, because tear down is going to have to clean up the 
 files manually anyway
 
 On Tue, Aug 25, 2015 at 4:33 PM Zachary Turner ztur...@google.com wrote:
 While looking into a Windows-specific issue involving TestTargetAPI.py, I 
 noticed that we are building the exact same executable many times.  Every 
 single test has a line such as self.buildDwarf() or self.buildDsym().  Those 
 functions will first run make clean and then run make, essentially rebuilding 
 the exact same program.
 
 Is this necessary for some reason?  Each test suite already supports 
 suite-specific setup and tear down by implementing a suite-specific setUp and 
 tearDown function.  Any particular reason we can't build the executables a 
 single time in setUp and clean them a single time in tearDown?
 
 I don't think we need to retro-actively do this for every single test suite 
 as it would be churn, but in a couple of places it would actually fix test 
 failures on Windows, and improve performance of the test suite as a side 
 benefit (as a result of reducing the number of compilations that need to 
 happen)
 
 Thoughts?
 ___
 lldb-dev mailing list
 lldb-dev@lists.llvm.org
 https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_lldb-2Ddevd=BQIGaQc=eEvniauFctOgLOKGJOplqwr=aTCVT7yw0RLKhx7ZXY2faboS3m1dhXpYF-Av4XoSGMUm=Eycd1fp0-akP8p_gZ00FUIzJIUFwuS78MvYOL_c9s5ss=Xm3Muzt0_AVzEn-Y2pSy-gsnQsAbeNAmeo10Vr1VeT8e=

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

Re: [lldb-dev] Breakpoints on inlined functions described by DW_AT_ranges

[Jim Ingham via lldb-dev]

Ah, okay.  For a while the llvm-dsymutil folks were trying to make the output 
of dsymutil & llvm-dsymutil identical so that they could be sure llvm-dsymutil 
was doing the right thing, so I'm a little surprised the two differ in this 
regard.  But if it works with .o files & llvm-dsymutil I think that's all we 
really care about at this point.

Jim


> On Sep 4, 2015, at 7:03 PM, Keno Fischer  wrote:
> 
> Actually, it's not a clang bug either. The info is there in the .o file. This 
> only happens if lldb is looking in the .dSYM. If I delete that and let lldb 
> look in the .o files, it sets the breakpoint just fine, so I'll chalk this up 
> as a dsymutil bug. llvm-dsymutil works fine.
> 
> On Fri, Sep 4, 2015 at 9:41 PM, Keno Fischer  
> wrote:
> Hi Jim,
> 
> I tried to work on this, but everything there actually seemed correct. It now 
> seems to me like those functions are simply missing from .apple_names 
> (compiled with latest Clang trunk), so this might not be an LLDB bug after 
> all.
> 
> Keno
> 
> On Fri, Sep 4, 2015 at 3:20 PM, Jim Ingham  wrote:
> Certainly a bug.  This bit:
> 
> if (inlined_die)
> {
> Block _block = sc.function->GetBlock (true);
> sc.block = function_block.FindBlockByID (inlined_die.GetID());
> if (sc.block == NULL)
> sc.block = function_block.FindBlockByID 
> (inlined_die.GetOffset());
> if (sc.block == NULL || sc.block->GetStartAddress (addr) == false)
> addr.Clear();
> }
> 
> from SymbolFileDwarf::ResolveFunction is most likely responsible.  I don't 
> remember offhand how the blocks deal with the fact that this one die actually 
> represents multiple blocks, but it's going to be something related to that.
> 
> If you want to have a look, that would be great, otherwise file a bug and we 
> can take a look when we get some free time.
> 
> Jim
> 
> > On Sep 4, 2015, at 12:05 PM, Keno Fischer via lldb-dev 
> >  wrote:
> >
> > I'm trying to set a breakpoint (using `b jl_apply`) on a function 
> > (jl_apply) that is inlined in a number of places. This generally works 
> > fine, but I have noticed that in certain cases LLDB fails to set a 
> > breakpoint even though when I step through manually, it does know which 
> > function the code belongs to. Investigating further, I have found that the 
> > difference comes from whether the inlined subroutine is described via 
> > DW_AT_low_pc or via DW_AT_ranges, so e.g.
> >
> > 0xf6c8:   DW_TAG_inlined_subroutine [42] *
> > DW_AT_abstract_origin [DW_FORM_ref4](cu 
> > + 0x22e7 => {0xd394} "jl_apply")
> > DW_AT_low_pc [DW_FORM_addr] 
> > (0xf768)
> > DW_AT_high_pc [DW_FORM_addr]
> > (0xf776)
> > DW_AT_call_file [DW_FORM_data1] 
> > ("/Users/kfischer/Projects/julia-testpatch/src/gf.c")
> > DW_AT_call_line [DW_FORM_data1] (34)
> >
> > will get a  breakpoint while
> >
> > 0xf6ee: DW_TAG_inlined_subroutine [53] *
> >   DW_AT_abstract_origin [DW_FORM_ref4]  (cu + 
> > 0x22e7 => {0xd394} "jl_apply")
> >   DW_AT_ranges [DW_FORM_data4]  (0xb790
> >  [0xf785 - 0xf788)
> >  [0xf79c - 0xf7b8))
> >   DW_AT_call_file [DW_FORM_data1]   
> > ("/Users/kfischer/Projects/julia-testpatch/src/gf.c")
> >   DW_AT_call_line [DW_FORM_data2]   (1668)
> >
> > will not. Is this the intended behavior or a bug? If it's a bug, any ideas 
> > where to look to try to fix it?
> >
> > Thanks,
> > Keno
> > ___
> > 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] Testing through api vs. commands

[Jim Ingham via lldb-dev]

> On Sep 15, 2015, at 4:23 PM, d...@burble.org wrote:
> 
> I do still think we need some tests that verify commands run, but I think 
> those tests should focus not on doing complicated interactions with the 
> debugger, and instead just verifying that things parse correctly and the 
> command is configured correctly, with the underlying functionality being 
> tested by the api tests.
> 
> Thoughts?
> 
> I agree that we should have both testing methods - SB API *and* commands,
> because we should be testing the user command interface too!
> 
> Instead, to fix the Windows vs. other issue, I would suggest writing a
> sub-class that won't expect the missing params based on platform.
> 
> In any case, there's a lot I never could figure out how to do in the SB
> API that I could only do via commands.  For example, how do you test
> that a trailing space at the end of the expr --language option's argument
> is trimmed in the SB API?

I'm not quite sure I understand what you mean by this example?  It sounds like 
you are asking how to test peculiarities of the
Command Line language name option parser through the SB API.  Not sure that 
makes sense.

But if there's anything you can do with the lldb command line that you can't do 
with the SB API's that is a bug.  Please file bugs (or maybe ask "how would I 
do that" here first then file a bug if you get no answer.)

Note, you might have to do some work to marshall information in a way that 
looks like what some of the complex commands produce.  But even some of the 
complex printers like the frame & thread Status are available through the SB 
API's and anything else useful like that should also be exposed at some point.  

If we had much more time we might have built the Command Line on top of the SB 
API's, but that would have made it really hard to bootstrap the thing.  In 
theory, somebody could go back & re-implement the lldb command line on top of 
the SB API's - much like what was done with the MI commands.  In actuality that 
would be a lot of effort that could be better spent somewhere else.  But not 
doing it that way means we have to be careful not to add stuff to the command 
line without adding some way to get at it with the API's.

Jim


> 
> -Dawn

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

Re: [lldb-dev] Testing through api vs. commands

[Jim Ingham via lldb-dev]

> On Sep 11, 2015, at 11:47 AM, Zachary Turner  wrote:
> 
> We'll probably rewrite tests that we find are failing specifically as a 
> result of issues like this, but I agree it's not worth re-writing everything 
> else except on an as-needed basis.
> 
> To make the distinction explicit and enforce it kind of at an organnizational 
> level, would it be worth creating folders under lldb/test like 
> lldb/test/commands, and recommending that all HandleCommand tests to go there?
> 
> Possibly unrelated question: But in regards to this api test vs. 
> HandleCommand test situation, is that what the purpose of the 
> @python_api_test decorator is (and is this decorator even still useful)?

I think it might have had some utility back when the SB API's were new and we 
were shuffling them around a lot, though I never found a use for it.  I don't 
see any reason for it to exist any more.

Jim


> 
> On Fri, Sep 11, 2015 at 11:42 AM Jim Ingham  wrote:
> I have held from the beginning that the only tests that should be written 
> using HandleCommand are those that explicitly test command behavior, and if 
> it is possible to write a test using the SB API you should always do it that 
> way for the very reasons you cite.  Not everybody agreed with me at first, so 
> we ended up with a bunch of tests that do complex things using HandleCommand 
> where they really ought not to.  I'm not sure it is worth the time to go 
> rewrite all those tests, but we shouldn't write any new tests that way.
> 
> Jim
> 
> 
> > On Sep 11, 2015, at 11:33 AM, Zachary Turner via lldb-dev 
> >  wrote:
> >
> > The past few weeks I've spent a lot of time xfailing the rest of the 
> > failing tests on windows so we can enable tests to run on the bots.
> >
> > One thing I ran into more frequently than I would have liked is that the 
> > tests were failing not because the functionality is broken, but because the 
> > substrings being grepped for in the output had a slightly different format 
> > on Windows.  The pattern for tests is frequently something like:
> >
> > result = runCommand()
> > self.expect()
> >
> > A good example of this is that when you do a backtrace, on windows you 
> > might see a fully demangled function name such as a.out`void foo(int x), 
> > whereas on other platforms you might just see a.out`foo.
> >
> > I saw the reverse situation as well, where a test was passing but shouldn't 
> > have because it was actually broken, but due to the impreciseness of 
> > grepping output the grep was suceeding.  Specifically, this was happening 
> > on a test that verified function parameters.  it launched a program with 3 
> > arguments, and then looked for "(int)argc=3" in the frame info.  It was 
> > broken on Windows because argc was pointing to junk memory, so it was 
> > actually printing "(int)argc=3248902" in the output.  Test was passing, 
> > even though it was broken.
> >
> > Rather than make the regexes more complicated, I think the right fix here 
> > is to stop using the command system and grepping to write tests.  Just go 
> > through the api for everything, including verifying the result.  In the 
> > second case, for example, you launch the process, set the breakpoint, wait 
> > for it to stop, find the argument named argc, and verify that it's value is 
> > 3.
> >
> > I don't want to propose going back and rewriting every single test to do 
> > this, but I want to see how people feel about moving toward this model 
> > going forward as the default method of writing tests.
> >
> > I do still think we need some tests that verify commands run, but I think 
> > those tests should focus not on doing complicated interactions with the 
> > debugger, and instead just verifying that things parse correctly and the 
> > command is configured correctly, with the underlying functionality being 
> > tested by the api tests.
> >
> > Thoughts?
> >
> >
> > ___
> > 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] Testing through api vs. commands

[Jim Ingham via lldb-dev]

I have held from the beginning that the only tests that should be written using 
HandleCommand are those that explicitly test command behavior, and if it is 
possible to write a test using the SB API you should always do it that way for 
the very reasons you cite.  Not everybody agreed with me at first, so we ended 
up with a bunch of tests that do complex things using HandleCommand where they 
really ought not to.  I'm not sure it is worth the time to go rewrite all those 
tests, but we shouldn't write any new tests that way.

Jim


> On Sep 11, 2015, at 11:33 AM, Zachary Turner via lldb-dev 
>  wrote:
> 
> The past few weeks I've spent a lot of time xfailing the rest of the failing 
> tests on windows so we can enable tests to run on the bots.
> 
> One thing I ran into more frequently than I would have liked is that the 
> tests were failing not because the functionality is broken, but because the 
> substrings being grepped for in the output had a slightly different format on 
> Windows.  The pattern for tests is frequently something like:
> 
> result = runCommand()
> self.expect()
> 
> A good example of this is that when you do a backtrace, on windows you might 
> see a fully demangled function name such as a.out`void foo(int x), whereas on 
> other platforms you might just see a.out`foo.
> 
> I saw the reverse situation as well, where a test was passing but shouldn't 
> have because it was actually broken, but due to the impreciseness of grepping 
> output the grep was suceeding.  Specifically, this was happening on a test 
> that verified function parameters.  it launched a program with 3 arguments, 
> and then looked for "(int)argc=3" in the frame info.  It was broken on 
> Windows because argc was pointing to junk memory, so it was actually printing 
> "(int)argc=3248902" in the output.  Test was passing, even though it was 
> broken.
> 
> Rather than make the regexes more complicated, I think the right fix here is 
> to stop using the command system and grepping to write tests.  Just go 
> through the api for everything, including verifying the result.  In the 
> second case, for example, you launch the process, set the breakpoint, wait 
> for it to stop, find the argument named argc, and verify that it's value is 3.
> 
> I don't want to propose going back and rewriting every single test to do 
> this, but I want to see how people feel about moving toward this model going 
> forward as the default method of writing tests.
> 
> I do still think we need some tests that verify commands run, but I think 
> those tests should focus not on doing complicated interactions with the 
> debugger, and instead just verifying that things parse correctly and the 
> command is configured correctly, with the underlying functionality being 
> tested by the api tests.
> 
> Thoughts?
> 
> 
> ___
> 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 fails to hit breakpoint when line maps to multiple addresses

[Jim Ingham via lldb-dev]

> On Sep 23, 2015, at 6:39 PM, d...@burble.org wrote:
> 
> On Wed, Sep 23, 2015 at 11:44:41AM -0700, Greg Clayton wrote:
>> We currently coalesce breakpoints to avoid the user stopping multiple times 
>> on the same source line. This might have been done to avoid stepping issues 
>> we might have had in the past, but we have made many modifications to 
>> stepping such that the step thread plans now know how to step through two 
>> hits from the same source line. I would need Jim to confirm this, but he is 
>> out for 2 weeks.
> 
> I (think I) understand the intent, but it is wrong as written.  What I
> think the code is trying to do is remove duplicate lines within a basic
> block (or at least that's the only explanation I can come up with that
> makes any sense), but the code appears to assume Block == basic block,
> which is not true. 

The debugger doesn’t really know anything about basic blocks.  IIRC there is a 
way to specify this in the DWARF line tables but nobody sets it so we don’t try 
to use it.

Given that, the best lldb can do is use heuristics, and the best heuristic I 
had was Block == basic block…  

The motivation is that compilers in general and certainly clang in particular 
love to put multiple line table entries in for a given line that are either 
contiguous or interrupted by artificial book-keeping code.  So if we didn’t 
coalesce these line entries, when you set a breakpoint on such a line, you’’d 
have to hit continue some unpredictable number of times before you actually get 
past that line.  You could figure out how many time by counting the number of 
locations, but nobody could be expected to do that…  And if you are chasing 
multiple hits of the breakpoint through code it was really a pain since one 
“continue” didn’t result in one pass through the function containing the code. 
This happens very frequently and was a font of bugs for lldb early on.

Note, this doesn’t affect the stepping algorithms, since when we step we just 
look at where we land and if it has the same line number as we were stepping 
through we keep going.  Of course, it also makes stepping over such a line 
annoying for the same reason that it made continue annoying...

Note also that gdb plays the same trick with setting breakpoints on multiple 
line table entries (or at least it did last time I looked.)  This wasn’t 
something new in lldb.

I don’t think it will make people happy to turn this coalescing off by default, 
I would urge you not to do that.  Yours is the first report we’ve had where 
this causes trouble, whereas it makes general stepping work much more nicely.  
So if you have some specific reason to need it either (a) if there’s some 
better heuristic you can come up with that detects when you should not 
coalesce, that would be awesome or (b) if there’s no way lldb can tell, you’ll 
have to add an option.

Jim


> 
> As long as there is branching into/out of an address range, you can miss
> breakpoints, which is much worse than stepping to the same line twice,
> wouldn't you agree?  Note that this isn't even in optimized code - this
> issue will be far more common after the optimizer has played with it.
> 
> As you say, we might have to wait for Jim to hear the real answer. 
> If this turns out to be intentional, OK to add an option to control it?  
> 
>> So this is on purpose and is expected. Not sure what will happen if we 
>> disable this coalescing of locations that are contiguous. Feel free to try 
>> and disable it and run the test suite and see how things go. Don't check 
>> anything in, but you could try disabling it on your branch and see how 
>> things go. Then when Jim returns we can confirm with him what the right 
>> thing to do is.
> 
> Sure - will do.
> 
> Thanks!
> -Dawn

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

Re: [lldb-dev] Linux core dump doesn't show listing when loaded

[Jim Ingham via lldb-dev]

> On Dec 2, 2015, at 8:35 AM, Todd Fiala via lldb-dev  
> wrote:
> 
> Does our init file mechanism have the ability to do something conditionally 
> if it's a core file?  (i.e. do we already have a way to get Ted's desired 
> behavior via an inserted call to "thread backtrace all" that somehow gets 
> triggered by the init, but only when we're talking about a core file?)
> 
> Alternatively, Ted, you could have a wrapper script of some sort (think 
> lldb-core.{sh,bat} or something) that you call that sources an lldb 
> core-file-specific init file that sets up aliases and the like to start up 
> lldb how you want, maybe?

Seems to me, the question is, is "target create --core" the same as "target 
create" or is it "target create" followed by "attach".  In the latter case, for 
"real" processes, we always print the stop state.  Since you really are 
attaching to the core process when you load a core file, the behavior of 
printing the stop state feels more right to me.  As to how that prints, 
following this logic, that should be the same as any other stop printing, and 
is I think orthogonal to Ted's original question.

Jim


> 
> On Mon, Nov 30, 2015 at 9:32 AM, Greg Clayton via lldb-dev 
>  wrote:
> "thread list" should just list the threads and their stop reasons (no 
> backtraces). If you want backtraces just do "thread backtrace all".
> 
> 
> On Nov 24, 2015, at 1:09 PM, Ted Woodward via lldb-dev 
>  wrote:
> >
> > I’ve been working on an old rev that we’d released on; now I’m much closer 
> > to ToT as we move towards our next major Hexagon release.
> >
> > Core dumps on the old rev would print out a listing/disassembly for each 
> > thread in the core dump. Now it doesn’t.
> >
> > ToT does this, on x86 Linux:
> >
> > >bin/lldb ~/lldb_test/coredump/lincrash -c ~/lldb_test/coredump/lincore
> > (lldb) target create "/usr2/tedwood/lldb_test/coredump/lincrash" --core 
> > "/usr2/tedwood/lldb_test/coredump/lincore"
> > Core file '/usr2/tedwood/lldb_test/coredump/lincore' (x86_64) was loaded.
> > (lldb) thread list
> > Process 0 stopped
> > * thread #1: tid = 0, 0x00401190 lincrash`main + 16 at 
> > lincrash.c:5, name = 'lincrash', stop reason = signal SIGSEGV
> > (lldb)
> >
> > I can see the listing by going up and down the stack, but I’d like to see 
> > the listing on load. Is the no listing intended?
> >
> > Ted
> >
> > --
> > Qualcomm Innovation Center, Inc.
> > The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a 
> > Linux Foundation Collaborative Project
> >
> > ___
> > 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
> 
> 
> 
> -- 
> -Todd
> ___
> 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] Exclusively build and install LLDB?

[Jim Ingham via lldb-dev]

Todd is right, at runtime lldb does need to find some of the clang include 
files in order to build modules for its own purposes.  On an OS X install, 
these headers are put in:

LLDB.framework/Resources/Clang

and are:

 > ls
./  avx512vlbwintrin.h  lzcntintrin.h   
stdatomic.h
../ avx512vlintrin.hmm3dnow.h   
stdbool.h
Intrin.havxintrin.h mm_malloc.h stddef.h
__stddef_max_align_t.h  bmi2intrin.hmmintrin.h  stdint.h
__wmmintrin_aes.h   bmiintrin.h module.modulemap
stdnoreturn.h
__wmmintrin_pclmul.hcpuid.h nmmintrin.h 
tbmintrin.h
adxintrin.h emmintrin.h pmmintrin.h tgmath.h
altivec.h   f16cintrin.hpopcntintrin.h  
tmmintrin.h
ammintrin.h float.h prfchwintrin.h  unwind.h
arm_acle.h  fma4intrin.hrdseedintrin.h  vadefs.h
arm_neon.h  fmaintrin.h rtmintrin.h 
varargs.h
avx2intrin.hia32intrin.hshaintrin.h 
wmmintrin.h
avx512bwintrin.himmintrin.h smmintrin.h 
x86intrin.h
avx512erintrin.hiso646.hstdalign.h  
xmmintrin.h
avx512fintrin.h limits.hstdarg.h
xopintrin.h

Other than that, lldb shouldn't need to install any other clang bits for its 
own purposes - and on OS X at least lldb only installs itself and not any of 
the clang binaries, so in practice this can be made to work.

Also, building lldb requires a lot of clang/llvm headers that I don't think get 
installed in the normal course of things.  So I'm not sure how easy it is going 
to be to build lldb against an installed llvm/clang.  I couldn't tell for sure 
whether this was another of your goals, but it may take a fair bit of monkeying 
around if you want to do things this way.

Jim

> On Dec 2, 2015, at 8:19 AM, Todd Fiala via lldb-dev  
> wrote:
> 
> Sorry for being late the the party here.
> 
> Sean Callanan and some of the other members can comment more on this, but 
> LLDB's expression parser for C/C++ is going to need access to the clang 
> include headers, so somehow lldb has to be able to find them.  Out of tree 
> llvm/clang usage is certainly possible as others have pointed out.  Using 
> that as the one way it is done, though, is likely to lead to pain.  Parts of 
> lldb's source will adjust as needed when the API surface area of LLVM or 
> clang changes.  It may not be happening quite as frequently as it had say 2 
> or 3 years ago, but it definitely happens.  So my expectation would be that 
> if you decouple lldb from llvm/clang (i.e. let them drift), sooner or later 
> you will get bitten by that.  Particularly when things like clang modules and 
> whatnot come along and actually require different logic on the lldb side to 
> deal with content generated on the clang/llvm side.  Once expression 
> evaluation is potentially compromised (due to the drift), I suspect the lldb 
> experience will degrade significantly.
> 
> On Sun, Nov 29, 2015 at 9:28 PM, Kamil Rytarowski via lldb-dev 
>  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> On 27.11.2015 00:57, Kamil Rytarowski via lldb-dev wrote:
> > On 11/23/15 10:28, Pavel Labath wrote:
> >> I believe that for purposes of building distribution packages you
> >>  should use the out-of-tree mode of building lldb. This means,
> >> you build llvm and clang separately, and then point your LLDB
> >> build to their installation path with LLDB_PATH_TO_LLVM_BUILD and
> >>  LLDB_PATH_TO_CLANG_BUILD variables. This way you can avoid
> >> building llvm/clang twice, you can have a separate package for
> >> each logical component of llvm and you can make lldb optional for
> >> your users (e.g. have only clang installed normally, if user
> >> chooses to install lldb, it will automatically pull in clang if
> >> needed). In this mode "make install" should install only the lldb
> >> components, which should be correctly linked to the
> >> already-installed llvm libraries.
> >
> >> That said, I can't guarantee that this mode will work for you
> >> out-of-the-box. We occasionally get patches to fix it up, but I
> >> don't know anyone who is using it extensively. However, I think
> >> this would be the best way forward for you and I'm prepared yo
> >> help you out if you choose to go that way.
> >
> >> What do you think about that?
> >
> >> pl
> >
> >
> > Thank you for your note on this mode. I was trying to prototype a
> > set of packages with: sources of llvm and clang, build dirs of llvm
> > and clang and installations of llvm and clang.
> >
> > Badly this approach doesn't work with pkgsrc, as this framework
> > contains various checks against using 

Re: [lldb-dev] Running lldb tests?

[Jim Ingham via lldb-dev]

Should we change the name of lldb/packages/Python/lldbsuite/dotest.py to 
something else to avoid this confusion?

Jim

> On Dec 2, 2015, at 2:48 PM, Zachary Turner via lldb-dev 
>  wrote:
> 
> You shouldn't have to point it anywhere.  Just run lldb/test/dotest.py the 
> same way you're currently running it and it should work if you use the right 
> script.  That use_lldb_suite also adds the location of the test folder to 
> sys.path so it can find it.
> 
> The reason all this happened and everything was moved was to make a "real" 
> python package out of the core of the test suite, which allows lots of 
> functionality to be more easily reused both within the test suite itself, as 
> well as within other scripts that are not part of the test suite.
> 
> On Wed, Dec 2, 2015 at 2:43 PM Chuck Ries  wrote:
> I was confused because all the tests moved to the packages directory. Do I 
> need to run the dotest.py from the lldb/test/ directory but point it to the 
> individual tests within the packages directory?
> 
>  
> 
> From: Zachary Turner [mailto:ztur...@google.com] 
> Sent: Wednesday, December 2, 2015 2:41 PM
> To: Chuck Ries ; lldb-dev@lists.llvm.org
> Subject: Re: [lldb-dev] Running lldb tests?
> 
>  
> 
> Couple things:
> 
>  
> 
> 1) Python 2.7.10 is still the officially supported way to run tests for all 
> platforms
> 
> 2) Python 3 is only supported for Windows and it's experimental.  
> 
> 3) At some point I will drop support for 2.x on Windows, but 2.x will always 
> be the officially supported way to run tests on every other platform.
> 
>  
> 
> Are you running lldb/test/dotest.py or 
> lldb/packages/lldbsuite/test/dotest.py?  You should be running the former.  
> The `progress` module is located in lldb/third_party/Python/module/progress.  
> That should be in your `sys.path` because when you run `lldb/test/dotest.py` 
> the first line calls `import use_lldb_suite`, which modifies `sys.path` to 
> contain this and a few other directories.
> 
>  
> 
> Hopefully that gives you a starting point to diagnose what's wrong.
> 
>  
> 
> On Wed, Dec 2, 2015 at 2:35 PM Chuck Ries via lldb-dev 
>  wrote:
> 
> I am trying to run the lldb tests with dotest.py but it is failing with
> 
> chuckr-mac-build:test chuckr$ python ./dotest.py
> 
> Traceback (most recent call last):
> 
>   File "./dotest.py", line 30, in 
> 
> import progress
> 
> ImportError: No module named progress
> 
>  
> 
> It looks like some work was done to move to python 3 and I am using Python 
> 2.7.10. The info at http://lldb.llvm.org/test.html does not seem to be up to 
> date. Is there any fix to get the test script working?
> 
>  
> 
> ChuckR
> 
> ___
> 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] ThreadPlanStepOverBreakpoint behavior

[Jim Ingham via lldb-dev]

Eh, should probably actually say something, no...

Would it be sufficient to call 
ThreadPlanStepOverBreakpoint::ReenableBreakpointSite to reenable the breakpoint 
you were stepping over in ThreadPlanStepOverBreakpoint::WillPop?  It won't hurt 
to enable it twice, once in MischiefManaged and once in WillPop.  You might 
even get away with doing it only in WillPop and not in MischiefManaged, since 
no other thread plans are consulted between MischiefManaged and WillPop.  The 
fact that you've moved the re-enabling from MM to WP should not be detectable.  
And it seems wrong that you should be able to get rid of a "StepOverBreakpoint" 
plan without re-enabling the breakpoint, so this was clearly just an oversite.

BTW, you don't want to change the stop reason to trace.  Instruction single 
stepping onto a breakpoint, and actually hitting the breakpoint should look the 
same to the higher layers of the debugger.

Jim


> On Nov 30, 2015, at 5:24 PM, Jim Ingham via lldb-dev 
> <lldb-dev@lists.llvm.org> wrote:
> 
> 
>> On Nov 25, 2015, at 1:05 PM, Philippe Lavoie <philippe.lav...@octasic.com> 
>> wrote:
>> 
>> Sorry for the delay, I revisited the issue today.
>> 
>> It is causing a problem for our architecture which does not support single 
>> instruction stepping. We emulate it with breakpoints and a processor 
>> exception on branch taken.
>> 
>> For example:
>> 
>> When we step over a line with a breakpoint, our flavor of StepOverRange 
>> inserts a breakpoint at the next likely instruction and enables processor 
>> branch exception. LLDB will queue StepOverRange and StepOverBreakpoint plans.
>> 
>> The problem occurs when we stop on the breakpoint inserted by StepOverRange. 
>> ThreadPlanStepOverBreakpoint::DoPlanExplainsStop will see the stop reason is 
>> eStopReasonBreakpoint and ignore the breakpoint. Then StepOverRange's 
>> DoPlanExplainsStop will claim it and ThreadPlanStepOverBreakpoint gets 
>> discarded and does not reinsert the original breakpoint.
>> 
>> Is there a way to make our scenario fit in the default thread plans?
>> Maybe check the breakpoint kind of all 'step' breakpoints and set the 
>> thread's StopReason to Trace?
>> 
>> -Philippe
>> 
>> From: jing...@apple.com [jing...@apple.com]
>> Sent: Monday, October 05, 2015 5:26 PM
>> To: Philippe Lavoie
>> Cc: lldb-dev@lists.llvm.org
>> Subject: Re: [lldb-dev] ThreadPlanStepOverBreakpoint behavior
>> 
>> That is intended behavior.  MischiefManaged is called when an stop 
>> propagates to that plan, and it needs to decide whether it is done or not.  
>> That’s not what happens when somebody decides to discard the plan.  WillPop 
>> will get called if you need to do some cleanup when the plan gets popped.
>> 
>> Was this causing some problem?
>> 
>> Jim
>> 
>>> On Sep 25, 2015, at 1:51 PM, Philippe Lavoie via lldb-dev 
>>> <lldb-dev@lists.llvm.org> wrote:
>>> 
>>> 
>>> I noticed that when a ThreadPlanStepOverBreakpoint is discarded (as opposed 
>>> to being popped from the stack), MischiefManaged() is not called and the 
>>> disabled breakpoint is not re-enabled.
>>> 
>>> Is this the intended behavior ?
>>> 
>>> -Philippe
>>> ___
>>> 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] bindings as service idea

[Jim Ingham via lldb-dev]

The server is sending back code.  I'd want to know I can trust whoever is 
sending me back code that I plan to build and run locally.

Jim

> On Nov 19, 2015, at 11:40 AM, Zachary Turner via lldb-dev 
>  wrote:
> 
> 
> 
> On Thu, Nov 19, 2015 at 10:28 AM Todd Fiala  wrote:
> Some other points we need to consider on the bindings-as-service idea:
> 
> * The service should be exposed via secure connection (https/ssl/etc.)  This 
> might already be guaranteed on the Google end by virtue of the endpoint, but 
> we'll want to make sure we can have a secure connection.  (This will be a 
> non-issue for standing up a custom server, but the official one should have 
> this taken care of).
>  
> If the only thing we're sending from client -> server is packaged up source 
> code which is already available on the open source repository, and the server 
> doesn't require authentication, is this necessary?
> 
> If so, does this mean everyone needs to generate a cert locally?
> ___
> 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] Stop IDs for individual thread

[Jim Ingham via lldb-dev]

> On Jun 3, 2016, at 2:22 AM, Abhishek Aggarwal via lldb-dev 
>  wrote:
> 
> Hi everyone
> 
> While debugging an inferior with LLDB, for every stop event a new StopID is 
> generated and this ID can be extracted from SBProcess::GetStopID() API. This 
> ID indicates change in the state of the process between two stop events.
> 
> As per my knowledge, in case of a multithreaded process this stop ID can't be 
> used to exactly pin point the thread(s) of the process that suffered change 
> in their states between two stop events. Is there a way to find out this 
> information?

That's not something the debugger tracks actively - when the process is running 
we try to interfere with it as little as possible.  But on systems that have a 
way of getting per thread activity accounting, you could keep track of that 
information each time we stop and use that information to figure this out.

debugserver on OS X does some reporting of CPU activity, but I don't think that 
is per thread.  You can fetch that with Process::GetAsyncProfileData(), but at 
present that's just a pass-through (used by Xcode), lldb itself doesn't do 
anything with this information.

Jim  

> 
> - Abhishek
> ___
> 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] Stop IDs for individual thread

[Jim Ingham via lldb-dev]

Note that we do know when we've actively suspended threads, but in an average 
step, you will spend a fair bit of the time allowing all threads to run.  So 
that wouldn't allow a very accurate accounting.

Jim 

> On Jun 3, 2016, at 8:42 AM, Jim Ingham via lldb-dev <lldb-dev@lists.llvm.org> 
> wrote:
> 
> 
>> On Jun 3, 2016, at 2:22 AM, Abhishek Aggarwal via lldb-dev 
>> <lldb-dev@lists.llvm.org> wrote:
>> 
>> Hi everyone
>> 
>> While debugging an inferior with LLDB, for every stop event a new StopID is 
>> generated and this ID can be extracted from SBProcess::GetStopID() API. This 
>> ID indicates change in the state of the process between two stop events.
>> 
>> As per my knowledge, in case of a multithreaded process this stop ID can't 
>> be used to exactly pin point the thread(s) of the process that suffered 
>> change in their states between two stop events. Is there a way to find out 
>> this information?
> 
> That's not something the debugger tracks actively - when the process is 
> running we try to interfere with it as little as possible.  But on systems 
> that have a way of getting per thread activity accounting, you could keep 
> track of that information each time we stop and use that information to 
> figure this out.
> 
> debugserver on OS X does some reporting of CPU activity, but I don't think 
> that is per thread.  You can fetch that with Process::GetAsyncProfileData(), 
> but at present that's just a pass-through (used by Xcode), lldb itself 
> doesn't do anything with this information.
> 
> Jim  
> 
>> 
>> - Abhishek
>> ___
>> 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] Using control+left/right arrow to jump between words in the prompt

[Jim Ingham via lldb-dev]

On OS X Ctrl left & right arrow are taken over by the system to move between 
virtual desktops.  Instead, option left & right are the equivalent gesture for 
move by word on OS X, and in the OS X lldb, option left & right do indeed move 
by word.

LLDB doesn't do most of this stuff by hand, it lets editline handle it, and so 
Ctrl-Arrow may be an optional feature you need to enable.  I'd have no 
objection to turning this on for Linux and Windows if that is appropriate.  The 
appropriate equivalent already works for OS X so this seems only fair.

Jim

> On Jan 11, 2016, at 2:50 AM, Ori Avtalion via lldb-dev 
>  wrote:
> 
> On Mon, Jan 11, 2016 at 11:40 AM, Pavel Labath  wrote:
>>> Is it a feature that would be welcome?
>> Is this an offer to implement the feature? ;)
>> If so, I know a couple of people, who would be very pleased by that. :)
> 
> I'm willing to implement it (or at least try :P), but first I wanted to
> gauge interest and get approval, as I don't know how the project decides
> on new features.
> ___
> 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] Get source-map from python API?

[Jim Ingham via lldb-dev]

There is currently no API to access the settings.  You have to cons up commands 
and use SBCommandInterpreter::HandleCommand to execute them.

This is one of the remaining holes in the SB API.

Jim

> On Jan 14, 2016, at 2:41 PM, Jeffrey Tan via lldb-dev 
>  wrote:
> 
> Hi,
> 
> We are building an IDE debugger on top of lldb python API. In order to get 
> the source remapping work(the source path embedded in the symbol may be 
> different from the real source path), user needs to use "settings set 
> target.source-map" command to remap the source. 
> 
> I would like users to do similar thing from our IDE debugger. However, I 
> could not find a python API to specify the source remapping, and more 
> important a way to access the remapping functionality. The SBSourceManager 
> class only exposes a single DisplaySourceLinesWithLineNumbers() method which 
> displays the source in console output. Ideally it should expose an API in 
> SBSourceManager for us to provide the old FileSpec and get back a new 
> remapped FileSpec.
> 
> Is this not exposed in Python API? Do I need to re-do the remapping logic in 
> our IDE UI code? How is other IDE handling the source remapping?
> 
> 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] Why is storing SBTarget in a private field causing random crash?

[Jim Ingham via lldb-dev]

The broadcasters and listeners depend mutually on one another.  The listener 
keeps a list of the broadcasters it is listening to, and the broadcaster a list 
of the listeners it is broadcasting to.  When the broadcaster goes down it 
removes the listeners from its list and ditto for the listeners and their 
broadcaster list. And these lists are protected by mutexes, so they should keep 
each other out of trouble.  But it looks like there's some way that we can get 
a listener destroyed but not removed from the broadcaster's list by the point 
where the broadcaster goes to remove it.  I've seen reports of this but not 
reproducible ones.  If you have a case that reproduces easily, I would love to 
take a look at it.

Jim



> On Feb 12, 2016, at 9:50 AM, Greg Clayton via lldb-dev 
>  wrote:
> 
> This is a clear bug in LLDB. If you have a repro case, please file a bug and 
> attach the instructions on how to make this happen. Our API must be able to 
> handle things like this.
> 
> SBTarget has a shared pointer to a lldb_private::Target. If you have a 
> reference to a target, it should keep that target alive and it shouldn't 
> crash later when it is actually freed. 
> 
> So please file a bug and we'll get it fixed. For a work around for now, yes, 
> setting all SB references to None should help you work around the issue.
> 
> Greg
> 
>> On Feb 7, 2016, at 10:41 PM, Jeffrey Tan via lldb-dev 
>>  wrote:
>> 
>> Hi,
>> 
>> I have been spending long time troubleshooting a race condition in our lldb 
>> python test. I finally narrowed down to one code change that caused the 
>> race: basically, whenever I store SBTarget in DebuggerTestCase's self.target 
>> field lldb will randomly crash during destruction(see below). 
>> 
>> In the code, if I modify the two "self.target" to local variable "target" 
>> the random crash will disappear. 
>> 
>> I am not a python expert. Why is holding SBTarget will cause the test to 
>> random crash? Do I have to set every SBXXX fields to None before calling 
>> SBDebugger.Destroy()?
>> 
>> 
>> ==Crash Stack==
>> Crashed Thread:0  Dispatch queue: com.apple.main-thread
>> 
>> Exception Type:EXC_BAD_ACCESS (SIGSEGV)
>> Exception Codes:   KERN_INVALID_ADDRESS at 0x0010
>> 
>> VM Regions Near 0x10:
>> --> 
>>__TEXT 00010d145000-00010d146000 [4K] r-x/rwx 
>> SM=COW  
>> /System/Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python
>> 
>> Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
>> 0   com.apple.LLDB.framework 0x0001101c037d 
>> lldb_private::Listener::BroadcasterWillDestruct(lldb_private::Broadcaster*) 
>> + 95
>> 1   com.apple.LLDB.framework 0x0001101a0da2 
>> lldb_private::Broadcaster::Clear() + 50
>> 2   com.apple.LLDB.framework 0x0001101a0ced 
>> lldb_private::Broadcaster::~Broadcaster() + 75
>> 3   com.apple.LLDB.framework 0x0001103d6879 
>> lldb_private::Target::~Target() + 741
>> 4   com.apple.LLDB.framework 0x0001103d6c20 
>> lldb_private::Target::~Target() + 14
>> 5   libc++.1.dylib   0x7fff896448a6 
>> std::__1::__shared_weak_count::__release_shared() + 44
>> 6   com.apple.LLDB.framework 0x00010e560664 
>> _wrap_delete_SBTarget(_object*, _object*) + 123
>> 7   org.python.python0x00010d15a50a PyObject_Call + 99
>> 
>> 
>> ==Code==
>> from find_lldb import lldb
>> from simplest_event_thread import LLDBListenerThread
>> import unittest
>> import threading
>> 
>> running_signal = threading.Event()
>> stopped_signal = threading.Event()
>> 
>> def launch_debugging(debugger, stop_at_entry):
>>error = lldb.SBError()
>>listener = lldb.SBListener('Chrome Dev Tools Listener')
>>target = debugger.GetSelectedTarget()
>>process = target.Launch (listener,
>>None,  # argv
>>None,  # envp
>>None,  # stdin_path
>>None,  # stdout_path
>>None,  # stderr_path
>>None,  # working directory
>>0, # launch flags
>>stop_at_entry,  # Stop at entry
>>error) # error
>>print 'Launch result: %s' % str(error)
>> 
>>event_thread = LLDBListenerThread(debugger, running_signal, 
>> stopped_signal)
>>event_thread.start()
>> 
>>running_signal.set()
>>return event_thread
>> 
>> class DebuggerTestCase:
>> 
>>def wait_for_process_stop(self):
>>running_signal.wait()
>>running_signal.clear()
>>stopped_signal.wait()
>>stopped_signal.clear()
>> 
>>def test_breakpoint_at_line(self):
>>debugger = lldb.SBDebugger.Create()
>>debugger.SetAsync(True)

Re: [lldb-dev] Clang macro debug info

[Jim Ingham via lldb-dev]

You should ask on a clang list for a 100% correct answer, but I am pretty sure 
clang does not support macro information.  You can get somewhat the same result 
by building clang modules and importing them into lldb.  But you can't build 
modules for C++ yet, so you can only do this for C & ObjC programs.

Jim


> On Feb 9, 2016, at 9:08 AM, Ewan Crawford via lldb-dev 
>  wrote:
> 
> Hiya everyone,
> 
> I was wondering if anyone knows about the status of inspecting macros for 
> objects compiled with clang.
> Using either the DWARF 5 .debug_macro section or DWARF 4 .debug_macinfo 
> section.
> 
> We can debug macros from gcc with -g3, but I can't seem to get clang to emit 
> anything lldb can use.
> Neither -gdwarf-4 or -gdwarf-5 look like they emit the necessary debug info.
> 
> Am I just compiling incorrectly or is clang(or lldb) missing some 
> functionality?
> 
> Cheers,
> Ewan
> 
> -- 
> Ewan Crawford
> Software Engineer
> Codeplay Software Ltd
> Level C, Argyle House
> 3 Lady Lawson Street, Edinburgh, EH3 9DR
> Tel: 0131 466 0503
> Fax: 0131 557 6600
> Website: http://www.codeplay.com
> Twitter: https://twitter.com/codeplaysoft
> 
> This email and any attachments may contain confidential and /or privileged 
> information and is for use by the addressee only. If you are not the intended 
> recipient, please notify Codeplay Software Ltd immediately and delete the 
> message from your computer. You may not copy or forward it,or use or disclose 
> its contents to any other person. Any views or other information in this 
> message which do not relate to our business are not authorized by Codeplay 
> software Ltd, nor does this message form part of any contract unless so 
> stated.
> As internet communications are capable of data corruption Codeplay Software 
> Ltd does not accept any responsibility for any changes made to this message 
> after it was sent. Please note that Codeplay Software Ltd does not accept any 
> liability or responsibility for viruses and it is your responsibility to scan 
> any attachments.
> Company registered in England and Wales, number: 04567874
> Registered office: 81 Linkfield Street, Redhill RH1 6BY
> 
> ___
> 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] Listening for thread events

[Jim Ingham via lldb-dev]

It’s unclear to me why it would be a problem to listen to every thread object?  
They aren’t terribly chatty or anything, and you can listen to all of them with 
one listener.

Note, you don’t have to sign up individually for every thread object’s 
broadcaster.  That would be really annoying.  In lldb, you can listen to 
individual broadcasters or “broadcaster event classes”.  You want to do the 
latter.

You get the event class name with the GetBroadcasterClassName method on the 
class you are interested in (SBThread in this case) and then on your listener 
call 

SBListener::StartListeningForEventClass

If you do that, the debugger will sign your listener up for the objects of that 
broadcaster class as they come and go.  That makes listening to events on all 
the threads in your process quite straightforward.

Hope this helps.

Jim


> On Jan 29, 2016, at 2:32 PM, John Lindal via lldb-dev 
>  wrote:
> 
> I'm building an X11 UI on top of LLDB, and I'm stuck trying to listen for 
> thread events.
> 
> lldb_private::Thread is a Broadcaster, but lldb::SBThread doesn't expose a 
> GetBroadcaster() event the way SBProcess does.
> 
> I wouldn't really want to have to listen to every SBThread object, but when 
> the program stops, I could listen to the selected thread.  (Getting the 
> events from SBProcess would also work, if Process relayed them.)
> 
> Is this a feature that has not yet been implemented?  I couldn't find any 
> related tickets in Bugzilla.
> 
> Thanks,
> John Lindal
> ___
> 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] Understanding debugger launch events sequence

[Jim Ingham via lldb-dev]

I don’t think we can change this behavior, since other clients are relying on 
the way it is now.

In any case, attach won't return till it is successful, and presumably you know 
you are attaching, so I don’t think there’s any ambiguity about what is going 
on, even if you don’t get a stop event.

Jim

> On Jan 29, 2016, at 11:50 AM, Jeffrey Tan  wrote:
> 
> Jim/Pavel, my toy code works reliably after using SBListener with 
> SBTarget.Launch/Attach. 
> One thing I noticed is:
> If I set "stop_at_entry=True" for SBTarget.Launch(), I will get a stop event 
> of eStopReasonSignal at loader breakpoint. However SBTarget.AttachXXX() will 
> pause the target process without a stop event. Is this expected? This may 
> cause a bit state issue in our IDE since we rely on the stop event from 
> debugger to update UI in IDE. Is there any way to tell lldb to emit a stop 
> event during attach? 
> 
> 
> On Fri, Jan 29, 2016 at 11:22 AM, Jim Ingham  > wrote:
> I can’t comment on Windows, I don’t know what requirements the Windows API’s 
> place on the debugger.  
> 
> Its been a while since I’ve worked on Linux, but I don’t remember anything 
> that would privilege one thread over another.
> 
> lldb supports running multiple targets and processes in one debugger, and 
> also supports multiple debuggers running each one target or any combination.  
> Since each Debugger gets a separate script interpreter (and all its state) by 
> running multiple processes in one SBDebugger you could offer users the 
> possibility of having scripted commands to control a set of processes (e.g. 
> hitting a breakpoint in one process could trigger actions in the other.)  It 
> might be possible to do some interesting things that way.  
> 
> OTOH, keeping to one process per debugger is a much simpler programming 
> model.  So if you were planning to have YOUR code that runs the debugger 
> handle the possible interactions among processes, then it is probably going 
> to be easier to manage doing it that way.
> 
> Jim
> 
> 
> 
>> On Jan 29, 2016, at 10:43 AM, Jeffrey Tan > > wrote:
>> 
>> Thanks Jim. Is this true for other platforms? Our IDE is going to support 
>> Mac and Linux and may extend to Windows some time later. 
>> Just curious, why does Xcode create multiple SBDebuggers assuming it is 
>> debugging a single process? Are you talking about multiple-processes 
>> scenario(One SBDebugger for one process)? 
>> 
>> 
>> On Fri, Jan 29, 2016 at 9:21 AM, Jim Ingham > > wrote:
>> There is no requirement that the lldb API’s be called on a particular thread 
>> on OS X.  LLDB tries to be robust against being called from multiple threads 
>> simultaneously for the same debugger, but you can still make it fall over if 
>> you try hard, particularly if you allow multiple threads to restart the 
>> process you are debugging.  Running multiple SBDebuggers on separate threads 
>> works fine, that’s the mode Xcode uses, and we haven’t had problems with 
>> this in quite a while.
>> 
>> Jim
>> 
>> > On Jan 29, 2016, at 8:54 AM, Jeffrey.fudan via lldb-dev 
>> > > wrote:
>> >
>> > Great, this is very helpful, will give a try.
>> > Btw: is there any threading requirement of lldb API? For example, are all 
>> > the Apis must be called on the event thread or they are free to be called 
>> > on any thread? I know windows debug API has some limitation on this.
>> >
>> > Sent from my iPad
>> >
>> >> On Jan 29, 2016, at 2:59 AM, Pavel Labath > >> > wrote:
>> >>
>> >> Hi Jeffrey,
>> >>
>> >> I see a couple of problems with the way you are using the lldb's API.
>> >> The main problem is you are launching the target via the command-line
>> >> API, which does not allow you to specify the listener upon creation.
>> >> When you start it this way all events go to the default debugger
>> >> listener (debugger.GetListener()), and by the time you connect your
>> >> own listener, some of these events have already been broadcast, and
>> >> that is why you get nondeterministic behavior. You should use the
>> >> SBTarget.Launch function to specify the listener from the start.
>> >>
>> >> The second problem is the handling of the Stopped events. Sometimes
>> >> LLDB needs to stop the inferior do to some internal work, but this the
>> >> program is immediately resumed. This event is broadcast as a "stopped"
>> >> event with a special "restarted" bit set (see
>> >> SBProcess.GetRestartedFromEvent, and
>> >> > >> >)
>> >>
>> >> hope that helps,
>> >> pl
>> >>
>> >>
>> >>
>> >> On 29 January 2016 at 03:53, Jeffrey Tan via lldb-dev
>> >> 

Re: [lldb-dev] Understanding debugger launch events sequence

[Jim Ingham via lldb-dev]

I can’t comment on Windows, I don’t know what requirements the Windows API’s 
place on the debugger.  

Its been a while since I’ve worked on Linux, but I don’t remember anything that 
would privilege one thread over another.

lldb supports running multiple targets and processes in one debugger, and also 
supports multiple debuggers running each one target or any combination.  Since 
each Debugger gets a separate script interpreter (and all its state) by running 
multiple processes in one SBDebugger you could offer users the possibility of 
having scripted commands to control a set of processes (e.g. hitting a 
breakpoint in one process could trigger actions in the other.)  It might be 
possible to do some interesting things that way.  

OTOH, keeping to one process per debugger is a much simpler programming model.  
So if you were planning to have YOUR code that runs the debugger handle the 
possible interactions among processes, then it is probably going to be easier 
to manage doing it that way.

Jim



> On Jan 29, 2016, at 10:43 AM, Jeffrey Tan  wrote:
> 
> Thanks Jim. Is this true for other platforms? Our IDE is going to support Mac 
> and Linux and may extend to Windows some time later. 
> Just curious, why does Xcode create multiple SBDebuggers assuming it is 
> debugging a single process? Are you talking about multiple-processes 
> scenario(One SBDebugger for one process)? 
> 
> 
> On Fri, Jan 29, 2016 at 9:21 AM, Jim Ingham  > wrote:
> There is no requirement that the lldb API’s be called on a particular thread 
> on OS X.  LLDB tries to be robust against being called from multiple threads 
> simultaneously for the same debugger, but you can still make it fall over if 
> you try hard, particularly if you allow multiple threads to restart the 
> process you are debugging.  Running multiple SBDebuggers on separate threads 
> works fine, that’s the mode Xcode uses, and we haven’t had problems with this 
> in quite a while.
> 
> Jim
> 
> > On Jan 29, 2016, at 8:54 AM, Jeffrey.fudan via lldb-dev 
> > > wrote:
> >
> > Great, this is very helpful, will give a try.
> > Btw: is there any threading requirement of lldb API? For example, are all 
> > the Apis must be called on the event thread or they are free to be called 
> > on any thread? I know windows debug API has some limitation on this.
> >
> > Sent from my iPad
> >
> >> On Jan 29, 2016, at 2:59 AM, Pavel Labath  >> > wrote:
> >>
> >> Hi Jeffrey,
> >>
> >> I see a couple of problems with the way you are using the lldb's API.
> >> The main problem is you are launching the target via the command-line
> >> API, which does not allow you to specify the listener upon creation.
> >> When you start it this way all events go to the default debugger
> >> listener (debugger.GetListener()), and by the time you connect your
> >> own listener, some of these events have already been broadcast, and
> >> that is why you get nondeterministic behavior. You should use the
> >> SBTarget.Launch function to specify the listener from the start.
> >>
> >> The second problem is the handling of the Stopped events. Sometimes
> >> LLDB needs to stop the inferior do to some internal work, but this the
> >> program is immediately resumed. This event is broadcast as a "stopped"
> >> event with a special "restarted" bit set (see
> >> SBProcess.GetRestartedFromEvent, and
> >>  >> >)
> >>
> >> hope that helps,
> >> pl
> >>
> >>
> >>
> >> On 29 January 2016 at 03:53, Jeffrey Tan via lldb-dev
> >> > wrote:
> >>> Hi,
> >>>
> >>> On mac OS, I am having difficulty understanding the launch debugger events
> >>> sequence of lldb. I used the following code to play around LLDB. I found,
> >>> for some binaries, debugger will enter stopped/paused mode, waiting for my
> >>> further input, print stack shows:
> >>> dbg> bt
> >>> * thread #1: tid = 0x15153e, 0x7fff5fc0d2af
> >>> dyld`gdb_image_notifier(dyld_image_mode, unsigned int, dyld_image_info
> >>> const*) + 1
> >>> * frame #0: 0x7fff5fc0d2af dyld`gdb_image_notifier(dyld_image_mode,
> >>> unsigned int, dyld_image_info const*) + 1
> >>>   frame #1: 0x401d
> >>>
> >>> But some other binaries, it just print "Process event: stopped, reason: 1"
> >>> and inferior just exits immediately without waiting for debugger's further
> >>> input.
> >>>
> >>> Questions:
> >>> 1. When I launch a binary, is there supposed to be a loader breakpoint
> >>> waiting for debugger continue? Any other debug events do I expect to get 
> >>> and
> >>> continue?
> >>> 2. What about attach?
> >>> 3. What is the dyld`gdb_image_notifier() debugger break above? Why does it
> >>> happen for 

Re: [lldb-dev] How to get SBTarget before AttachToProcessWithID?

[Jim Ingham via lldb-dev]

Often when attaching, you know the executable you are planning to attach to.  
So the "normal" workflow is to create a target, then attach to the process with 
that target's executable.  This is particularly useful for remote debugging, 
since having a local copy of the binary will mean less data lldb has to ship 
over the remote connection.  It also means you can prep the target with 
breakpoints & settings prior to attach.

The case where you don't know the binary before you attach is a degenerate case 
of this, and so the sensible thing is to create an empty target, and use that 
to attach.  Then attaching will fill in this empty target. 

That makes more sense to me than having the debugger - which is the only thing 
above the target - support "Attach to anonymous app" but the target do "attach 
to known app".

BTW, the most straightforward way to create an empty target is to call 
SBDebugger.CreateTarget("").  I added a note to this effect in the SBDebugger 
help preamble.

Jim

> On Feb 1, 2016, at 2:02 AM, Pavel Labath via lldb-dev 
>  wrote:
> 
> Hi,
> 
> it's a bit un-intuitive, but you should be able to create a target
> with a null pointer for the executable, and use that to attach (see
> CommandObjectProcessAttach::DoExecute).
> 
> BTW, if you find the existing API documentation too vague, we'd be
> happy to accept any improvements.
> 
> cheers,
> pl
> 
> 
> On 30 January 2016 at 05:42, Jeffrey Tan via lldb-dev
>  wrote:
>> Hi,
>> 
>> Normally if you want to attach to a process you only have the pid/name of
>> the process. How do you get SBTarget? Am I supposed to call
>> SBDebugger.CreateTargetWithFileAndArch() against a dummy executable? Why do
>> we require a dummy SBTarget before attaching? This seems to be a wrong
>> design to me... 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 mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] How to use the C++ API? No useful documentation?

[Jim Ingham via lldb-dev]

The Python API is pretty much a mirror of the C++ API's.  The process_events.py 
example: 
http://llvm.org/svn/llvm-project/lldb/trunk/examples/python/process_events.py 
should give you a sense of how the broadcasters & listeners are used.  
Translating that from Python to C++ is quite straightforward.  There is some 
documentation in the SB API header files which can be helpful, though that is 
not complete.  There have been discussions on some of these issues on the 
mailing list previously that also might be of some help.

But you are right, we don't have a how-to manual for writing a debugger with 
the SB API's.  It would be great if somebody who was trying to use them for 
this purpose would draft up such a thing as they were going.  I am sure the 
folks on this list would be happy to help out and suggest better ways to do 
things, etc.

Jim

> On Feb 20, 2016, at 3:04 PM, Paul Peet via lldb-dev  
> wrote:
> 
> Hello,
> 
> I am currently working on an IDE for C++ and I would like to integrate lldb 
> as a debugger using the C++ API but it has been difficult for me to 
> understand the architecture because there is no documentation available 
> (except doxygen which isn't helpful at all).
> I am at the point understanding the Event system? How are Events created?
> How can I use SBListener and SBBroadcaster? (What's the function of 
> SBBroadvaster).
> 
> My current code looks something like this:
> 
> SBListener listener;
> SBProcess process = target.Launch(listener, args, env, nullptr, nullptr,
>   nullptr, "/home/cynecx/dev/helloWorld",
>   0, true, error);
> 
> process.Continue();
> 
> StateType state = process.GetState(); // is stopped
> 
> SBEvent event;
> 
> while(true) {
>   if(listener.WaitForEvent(0x, event)) {
> // This branch is never hit
> SBStream stream;
> event.GetDescription(stream);
> std::cout << stream.GetData() << std::endl;
>   } else {
> break;
>   }
> }
> 
> It would help developers (IDE) a lot if there might be some 
> tutorials/documentation on how to use the API.
> 
> Regards,
> Paul
> ___
> 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] No stopping event during launch(stop_at_entry=True) on Linux?

[Jim Ingham via lldb-dev]

If the linux side is not obeying "stop_at_entry" then that is a bug.

Jim


> On Feb 23, 2016, at 1:49 PM, Jeffrey Tan via lldb-dev 
>  wrote:
> 
> Hi,
> 
> I have got lldb launch working fine on my macbook for sometime. But when I 
> try the same code on Linux, it failed to emit any stopping events during 
> initial launch. 
> 
> When I run the reproduce code(listed at the end), I got the following 
> different results:
> 
> The key difference is that Macbook will emit a stopped event which caused our 
> IDE UI to enter break mode, while Linux violates this assumption. Is this a 
> bug?
> 
> ==Mac==
> lldb_pythonpath: 
> /Applications/Xcode.app/Contents/Developer/../SharedFrameworks/LLDB.framework/Resources/Python
> Launch result: success
>  Listening Thread ID: 4610625536
> dbg> Target event: ModulesLoaded
> Process event: StateChanged, Stopped
> Stop reason: 5
> dbg> bt
> * thread #1: tid = 0x101f01d, 0x7fff6401a000 dyld`_dyld_start, stop 
> reason = signal SIGSTOP
>   * frame #0: 0x7fff6401a000 dyld`_dyld_start
> ==Mac==
> 
> ==Linux==
> python linux_launch.py
> find_lldb:  '/home/jeffreytan/project/llvm-bin/Debug+Asserts/lib/python2.7/site-packages/lldb/__init__.pyc'>
> Launch result: success
>  Listening Thread ID: 140316621375232
> dbg> bt
> * thread #1: tid = 2794520, 0x7f6165b7bb00, name = 'foo', stop reason = 
> signal SIGSTOP
>   * frame #0: 0x7f6165b7bb00
> ==Linux==
> 
> Repro main.py
> # Should be first for LLDB package to be added to search path.
> from find_lldb import lldb
> import sys
> import os
> import time
> from sys import stdin, stdout
> from event_thread import LLDBListenerThread
> import threading
> 
> 
> def interctive_loop(debugger):
> while (True):
> stdout.write('dbg> ')
> command = stdin.readline().rstrip()
> if len(command) == 0:
> continue
> if command == 'q':
> return
> debugger.HandleCommand(command)
> 
> def do_test():
> debugger = lldb.SBDebugger.Create()
> debugger.SetAsync(True)
> executable_path = '~/Personal/compiler/CompilerConstruction/code/compiler'
> target = debugger.CreateTargetWithFileAndArch(executable_path, 
> lldb.LLDB_ARCH_DEFAULT)
> 
> listener = lldb.SBListener('Event Listener')
> error = lldb.SBError()
> process = target.Launch (listener,
>  None,  # argv
>  None,  # envp
>  None,  # stdin_path
>  None,  # stdout_path
>  None,  # stderr_path
>  None,  # working directory
>  0, # launch flags
>  True, # Stop at entry
>  error) # error
> print 'Launch result: %s' % str(error)
> 
> running_signal = threading.Event()
> stopped_signal = threading.Event()
> event_thread = LLDBListenerThread(debugger, running_signal, 
> stopped_signal)
> event_thread.start()
> 
> interctive_loop(debugger)
> 
> event_thread.should_quit = True
> event_thread.join()
> 
> lldb.SBDebugger.Destroy(debugger)
> return debugger
> 
> def main():
> debugger = do_test()
> 
> if __name__ == '__main__':
> main()
> 
> Event_thread
> class LLDBListenerThread(Thread):
> should_quit = False
> 
> def __init__(self, debugger, running_signal=None, stopped_sigal=None):
>   Thread.__init__(self)
>   self._running_signal = running_signal
>   self._stopped_sigal = stopped_sigal
>   process = debugger.GetSelectedTarget().process
>   self.listener = debugger.GetListener()
>   self._add_listener_to_process(process)
>   self._add_listener_to_target(process.target)
> 
> 
> def _add_listener_to_target(self, target):
> # Listen for breakpoint/watchpoint events 
> (Added/Removed/Disabled/etc).
> broadcaster = target.GetBroadcaster()
> mask = lldb.SBTarget.eBroadcastBitBreakpointChanged | 
> lldb.SBTarget.eBroadcastBitWatchpointChanged | 
> lldb.SBTarget.eBroadcastBitModulesLoaded
> broadcaster.AddListener(self.listener, mask)
> 
> def _add_listener_to_process(self, process):
> # Listen for process events (Start/Stop/Interrupt/etc).
> broadcaster = process.GetBroadcaster()
> mask = lldb.SBProcess.eBroadcastBitStateChanged | 
> lldb.SBProcess.eBroadcastBitSTDOUT | lldb.SBProcess.eBroadcastBitSTDERR | 
> lldb.SBProcess.eBroadcastBitInterrupt
> broadcaster.AddListener(self.listener, mask)
> 
> def run(self):
> print ' Listening Thread ID: %d' % 

Re: [lldb-dev] How to use the C++ API? No useful documentation?

[Jim Ingham via lldb-dev]

Yes, the process listener is a little bit special.  

When you are running a process in the debugger, the process is likely going to 
be stopping and starting for all sorts of reasons.  For instance, stepping 
through a source line is actually going to:

step over the breakpoint at the start pc - if you had stopped due to a 
breakpoint
then set a breakpoint at the next branch instruction it sees and continue to 
there
then step over that breakpoint, and if that caused a step in, decide if it 
wants to stop there, and if not step out
etc...

But none of these stops are relevant at the user level.  The thread plans have 
control over these implementation stops, and it would only cause trouble if 
code outside the thread plans tried to intervene here.

So lldb_private has the notion of a public state, and a private state for the 
process.  While all the above is going on, the private state is tracking all 
the changes described above, but the public state will remain "running".

Now eventually, whatever you asked the process to do will end, and the private 
state will go to stopped, and the stepping machinery will decide that its plan 
is complete and we should report a public stop.  So it sends an event to the 
process listener.  

Another wrinkle is that we also want to keep the state you would get from 
SBProcess::GetState sync'ed with the event queue.  It would be weird if one 
thread calling into lldb saw the process stopped, but the event queue thought 
the last event it saw was "running".  So the public state won't change to 
stopped till somebody fetches the stopped event off the queue.  

That means the process listener is privileged.  You have to have one when you 
create a process and since it is driving the state changes, there can be only 
one.  We didn't actually put in code to enforce this because I was planning to 
add the ability to have multiple listeners, but have one the "driving" 
listener, and the others passive observers.  Or have some kind of control baton 
that could be passed from listener to listener.  That way you could have one 
thread run the process for a while, then pass control to another listener.  But 
up to now nobody has really needed this complexity, so I never got around to 
doing that.

Anyway, so in the current state of things, you just have to know that there can 
only be one process listener, and it has to be the one you pass in when you 
launch the process.  And if you don't provide a listener, then we will set the 
Debugger's listener to be the process listener.  The documentation for launch 
hints at this but we could make it more explicit.

Hope this helps,

Jim



> On Feb 24, 2016, at 4:05 PM, Greg Clayton via lldb-dev 
>  wrote:
> 
> Not sure. First off, you don't need to do:
> 
> process.GetBroadcaster().AddListener(...)
> 
> The debugger's listener is already listening to all the events. If you don't 
> specify a listener during launch the process will use the debugger's listener 
> automatically. If you end up making your own process listener, you would 
> actually tell your listener to listen to a broadcaster:
> 
> SBListener listener("process-listener");
> launch_info.SetListener (listener);
> SBProcess process = target.Launch(launch_info, error);
> 
> Everything else looks good. 
> 
> What happens if you try running using the process_events.py python script? 
> You might need to specify the PYTHONPATH environment variable to point to 
> your lldb.so
> 
> % PYTHONPATH=/path/to/lldb/build/directory python 
> lldb/examples/python/process_events.py --breakpoint main.c:12 -- ./a.out arg1 
> arg2
> 
> Does this work if you replace a.out with the path and args for your program? 
> If it does, I would start porting the code from process_events.py and seeing 
> what works and what doesn't. The process_events.py will call 
> "process.Continue()" after it stops. Feel free to edit and play with this 
> script.
> 
> 
>> On Feb 24, 2016, at 3:45 PM, Paul Peet  wrote:
>> 
>> I am still getting "non determinism".
>> 
>> This is my current code:
>> 
>> SBListener listener = debugger.GetListener();
>> process.GetBroadcaster().AddListener(listener,
>>SBProcess::eBroadcastBitStateChanged |
>>SBProcess::eBroadcastBitSTDOUT);
>> 
>> if(!process.IsValid() || !error.Success()) {
>> return 1;
>> }
>> 
>> error = process.Continue();
>> if(!error.Success()) {
>> return 1;
>> }
>> 
>> while(true) {
>> SBEvent event;
>> 
>> if(listener.WaitForEvent(6, event)) {
>>   if(!event.IsValid()) {
>> break;
>>   }
>> 
>>   const uint32_t event_type = event.GetType();
>> 
>>   if (!SBProcess::EventIsProcessEvent(event)) {
>> continue;
>>   }
>> 
>>   if(event_type == SBProcess::eBroadcastBitStateChanged) {
>> const StateType state = SBProcess::GetStateFromEvent(event);
>> 
>> switch(state) {
>>   default:
>> continue;
>>   case eStateStopped: 

Re: [lldb-dev] Questions for module/symbol load/unload events

[Jim Ingham via lldb-dev]

> On Feb 27, 2016, at 8:34 PM, Jeffrey Tan via lldb-dev 
>  wrote:
> 
> Hi,
> 
> I am trying to listen for module/symbol load/unload events and display them 
> in output UI so that debugger users can have a basic clue what is debugger 
> busy doing while launching a big executable linking many shared libraries.
> 
> Questions:
> 1. I did not find an API to get current load/unload module during module 
> events. I was expecting some static API like lldb.SBModule(or 
> SBTarget).GetModuleFromEvent(SBEvent), but this does not exists. I tried to 
> treat current PC's module as loading module in module load/unload events. But 
> that does not work too(I think because process is not stopped in module 
> load/unload events). Do I miss something here?

From SBTarget.h:

static uint32_t
GetNumModulesFromEvent (const lldb::SBEvent );

static lldb::SBModule
GetModuleAtIndexFromEvent (const uint32_t idx, const lldb::SBEvent );

Note, you can also cause the process to stop with modules are loaded with the 
setting:

target.process.stop-on-sharedlibrary-events

if that is more convenient for you.

> 
> 2. Even though "image list" shows I have around 42 modules loaded in process, 
> I only got two module load events. Why is that?

On OS X the loader loads the closure of modules for whatever it is loading, and 
only stops and informs the debugger when this is all done.  So it is quite 
usual to see only a few load events even though many modules get loaded.


> 
> 3. Even though I added lldb.SBTarget.eBroadcastBitSymbolsLoaded, there is no 
> event of type eBroadcastBitSymbolsLoaded generated. Is it expected? 
> Apparently I have the symbols next to the binary. 

That event gets sent when symbols are added to an already loaded module.  It is 
so a UI will know to refresh the backtrace, local variables, source view, etc 
when code goes from having no symbols to having some symbols.  Those actions 
are not needed if the library & its symbols get loaded simultaneously, so it 
isn’t sent in that case.

Jim


> 
> This is tested on mac OSX lldb.
> 
> 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] Spurious process state change events

[Jim Ingham via lldb-dev]

> On Jan 15, 2016, at 1:49 PM, Vadim Chugunov via lldb-dev 
>  wrote:
> 
> +lldb-dev
> 
> On Fri, Jan 15, 2016 at 1:47 PM, Vadim Chugunov  wrote:
> Thanks, that was it!
> 
> On Fri, Jan 15, 2016 at 1:00 PM, Pavel Labath  wrote:
> Hi,
> 
> The stopped event should have the "restarted" flag set. You can use
> the GetRestartedFromEvent function to check for that. (Let me know if
> they don't). I think you can get this (under varying circumstances) on
> other platforms as well, so you need to handle this everywhere.
> 
> Somebody correct me if I'm wrong, but I believe that every restarted
> should be then followed by a running event.

No, if you get a stop event with the restarted bit set, the next event will be 
another stop event.  It just seemed annoying, if you already know the process 
restarted, to have to turn around and wait for the running event.

Jim


> 
> cheers,
> pl
> 
> 
> On 15 January 2016 at 19:35, Vadim Chugunov via lldb-dev
>  wrote:
> > Hi,
> > I have a Python script that drives LLDB (in async mode), with a
> > listener attached to the process.
> > On OSX, upon the launch, LLDB emits a eStateRunning process state
> > event, and then eventually eStateStopped - when a breakpoint is hit.
> > On Linux, however, the initial eStateRunning is immediately followed
> > by eStateStopped and another eStateRunning, without any intervention
> > on my part.  This messes things up for me somewhat, because my script
> > thinks that a breakpoint has been hit and tries examine state of the
> > process.
> > So I have 2 questions:
> > - Is it supposed to happen?
> > - What would be the best way to filter out these spurious stop events?
> >   if is_linux and is_first_stop_event: ...  feels a bit hacky.
> >
> > 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 mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Spurious process state change events

[Jim Ingham via lldb-dev]

Please do file a bug, that's definitely not how things are supposed to work.  
You will still see a private "running" event, of course, since those are just 
the raw events from the target, but the running event shouldn't get broadcast 
to the public event queue if it was coming from a continuation due to a 
breakpoint condition or command.

Jim


> On Jan 20, 2016, at 3:59 AM, Pavel Labath  wrote:
> 
> Hello,
> 
> thanks for confirming my suspicions. Sending the extra running event
> seems quite annoying to me as well, but it is how things work at the
> moment. And the problem does not seem to be linux-specific. This is
> the sequence of events I get on a Mac, when running over a conditional
> breakpoint that does not stop:
> 
> Got event: running , restarted:  False
> Got event: stopped , restarted:  True
> Got event: running , restarted:  False
> Got event: stopped , restarted:  False
> 
> Shall I file a bug about this?
> 
> pl
> 
> On 19 January 2016 at 19:03, Jim Ingham  wrote:
>> 
>>> On Jan 15, 2016, at 1:49 PM, Vadim Chugunov via lldb-dev 
>>>  wrote:
>>> 
>>> +lldb-dev
>>> 
>>> On Fri, Jan 15, 2016 at 1:47 PM, Vadim Chugunov  wrote:
>>> Thanks, that was it!
>>> 
>>> On Fri, Jan 15, 2016 at 1:00 PM, Pavel Labath  wrote:
>>> Hi,
>>> 
>>> The stopped event should have the "restarted" flag set. You can use
>>> the GetRestartedFromEvent function to check for that. (Let me know if
>>> they don't). I think you can get this (under varying circumstances) on
>>> other platforms as well, so you need to handle this everywhere.
>>> 
>>> Somebody correct me if I'm wrong, but I believe that every restarted
>>> should be then followed by a running event.
>> 
>> No, if you get a stop event with the restarted bit set, the next event will 
>> be another stop event.  It just seemed annoying, if you already know the 
>> process restarted, to have to turn around and wait for the running event.
>> 
>> Jim
>> 
>> 
>>> 
>>> cheers,
>>> pl
>>> 
>>> 
>>> On 15 January 2016 at 19:35, Vadim Chugunov via lldb-dev
>>>  wrote:
 Hi,
 I have a Python script that drives LLDB (in async mode), with a
 listener attached to the process.
 On OSX, upon the launch, LLDB emits a eStateRunning process state
 event, and then eventually eStateStopped - when a breakpoint is hit.
 On Linux, however, the initial eStateRunning is immediately followed
 by eStateStopped and another eStateRunning, without any intervention
 on my part.  This messes things up for me somewhat, because my script
 thinks that a breakpoint has been hit and tries examine state of the
 process.
 So I have 2 questions:
 - Is it supposed to happen?
 - What would be the best way to filter out these spurious stop events?
  if is_linux and is_first_stop_event: ...  feels a bit hacky.
 
 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 mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Weird stop stack while hitting breakpoint

[Jim Ingham via lldb-dev]

You only show one thread in your example.  Did another thread have a valid stop 
reason?  lldb shouldn’t be stopping for no reason anywhere…

Jim

> On Mar 18, 2016, at 4:08 PM, Jeffrey Tan via lldb-dev 
>  wrote:
> 
> Btw: the breakpoint I set is:
> "b BigGrepMasterAsync.cpp:171" which is not in any of the stopped stack 
> frames.
> 
> On Fri, Mar 18, 2016 at 3:47 PM, Jeffrey Tan  > wrote:
> Hi,
> 
> Our IDE(wrapping lldb using python) works fine on Linux for simple hello 
> world cases. While trying a real world case, I found whenever we set a source 
> line breakpoint, then trigger the code path, lldb will send a stopped state 
> process event, with thread.GetStopReason() being None and with weird 
> callstack. Any ideas why do I get this stop stack(code is listed at the end)? 
> I have verified that if I do not set breakpoint and trigger the same code 
> path does not cause this stop event to generate.
> 
> bt
> * thread #1: tid = 952490, 0x7fd7cb2daa83 libc.so.6`__GI_epoll_wait + 51, 
> name = 'biggrep_master_'
>   * frame #0: 0x7fd7cb2daa83 libc.so.6`__GI_epoll_wait + 51
> frame #1: 0x0271189f 
> biggrep_master_server_async`epoll_dispatch(base=0x7fd7ca970800, 
> arg=0x7fd7ca62c1e0, tv=) + 127 at epoll.c:315
> frame #2: 0x0270f6d1 
> biggrep_master_server_async`event_base_loop(base=0x7fd7ca970800, 
> flags=) + 225 at event.c:524
> frame #3: 0x025f9378 
> biggrep_master_server_async`folly::EventBase::loopBody(this=0x7fd7ca945180,
>  flags=0) + 834 at EventBase.cpp:335
> frame #4: 0x025f900b 
> biggrep_master_server_async`folly::EventBase::loop(this=0x7fd7ca945180) + 
> 29 at EventBase.cpp:287
> frame #5: 0x025fa053 
> biggrep_master_server_async`folly::EventBase::loopForever(this=0x7fd7ca945180)
>  + 109 at EventBase.cpp:435
> frame #6: 0x01e24b72 
> biggrep_master_server_async`apache::thrift::ThriftServer::serve(this=0x7fd7ca96d710)
>  + 110 at ThriftServer.cpp:365
> frame #7: 0x004906bc 
> biggrep_master_server_async`facebook::services::ServiceFramework::startFramework(this=0x7ffc06776140,
>  waitUntilStop=true) + 1942 at ServiceFramework.cpp:885
> frame #8: 0x0048fe6d 
> biggrep_master_server_async`facebook::services::ServiceFramework::go(this=0x7ffc06776140,
>  waitUntilStop=true) + 35 at ServiceFramework.cpp:775
> frame #9: 0x004219a7 biggrep_master_server_async`main(argc=1, 
> argv=0x7ffc067769d8) + 2306 at BigGrepMasterServerAsync.cpp:134
> frame #10: 0x7fd7cb1ed0f6 libc.so.6`__libc_start_main + 246
> frame #11: 0x00420bfc biggrep_master_server_async`_start + 41 at 
> start.S:122
> 
> Here is the code snippet of handling code:
> def _handle_process_event(self, event):
> # Ignore non-stopping events.
> if lldb.SBProcess.GetRestartedFromEvent(event):
> log_debug('Non stopping event: %s' % str(event))
> return
> 
> process = lldb.SBProcess.GetProcessFromEvent(event)
> if process.state == lldb.eStateStopped:
> self._send_paused_notification(process)
> elif process.state == lldb.eStateExited:
> exit_message = 'Process(%d) exited with: %u' % (
> process.GetProcessID(),
> process.GetExitStatus())
> if process.GetExitDescription():
> exit_message += (', ' + process.GetExitDescription())
> self._send_user_output('log', exit_message)
> self.should_quit = True
> else:
> self._send_notification('Debugger.resumed', None)
> 
> event_type = event.GetType()
> if event_type == lldb.SBProcess.eBroadcastBitSTDOUT:
> # Read stdout from inferior.
> process_output = ''
> while True:
> output_part = process.GetSTDOUT(1024)
> if not output_part or len(output_part) == 0:
> break
> process_output += output_part
> self._send_user_output('log', process_output)
> 
> ___
> 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] [Bug 26978] New: LLDB stack overflow while dealing with symbols for a process on Linux

[Jim Ingham via lldb-dev]

Note, g++ also uses the Itanium ABI for it’s C++ ABI, so as long as you are on 
a platform whose primary compiler is gcc and that isn’t very very old, either 
demangler will be equivalent except for bugs.  The side effects of one or the 
other are pretty much just that you get a different set of bugs.  So we let the 
platform owners choose the version they think best.

Jim


> On Mar 18, 2016, at 3:54 PM, Kate Stone  wrote:
> 
> Not all platforms use the same C++ name mangling.  Clang follows the Itanium 
> ABI specification which is what both the built-in LLDB demanglers understand.
> 
> Kate Stone k8st...@apple.com 
>  Xcode Low Level Tools
> 
> On Mar 18, 2016, at 3:50 PM, Jeffrey Tan via lldb-dev 
> > wrote:
> 
>> Thanks Jim. This is very helpful. 
>> We have double checked the libiberty we are building against which seems 
>> already be updated two weeks ago so this bug might not been fixed yet. 
>> Rebuilding LLDB_USE_BUILTIN_DEMANGLER fixed this stack overflow. 
>> 
>> Questions:
>> 1. Any reason LLDB_USE_BUILTIN_DEMANGLER is not used for other platforms? 
>> 2. Any side-effect if I use LLDB_USE_BUILTIN_DEMANGLER for lldb on other 
>> platform?
>> 
>> On Thu, Mar 17, 2016 at 7:04 PM, Jim Ingham > > wrote:
>> The code that has gotten itself into an infinite loop here is the libiberty 
>> cp-demangle.c, which is part of the C++ runtime libraries for the system you 
>> are on.  So we can't do anything to fix bugs with that.  You might make sure 
>> there isn't a newer version of that than the one on your system, but other 
>> than fixing the bugs in it yourself, there's not much we can do about that 
>> one.
>> 
>> However, if you build lldb with LLDB_USE_BUILTIN_DEMANGLER defined it will 
>> do two things, it will trigger the FastDemangler that Kate wrote, and if 
>> that succeeds, yay!  Otherwise it will fall back to another demangler that 
>> comes along with the C++ standard libraries from the llvm project.  That 
>> one, like the cp-demangle.c is very stack intensive, but it might not have 
>> whatever bug you are triggering in the libiberty one.  And if it does have 
>> crashing bugs somebody in the clang world could fix them...
>> 
>> Anyway, you might try that and see if you have any more luck.  IIRC, FreeBSD 
>> uses the llvm one in favor of the libiberty one.
>> 
>> Jim
>> 
>> 
>> > On Mar 17, 2016, at 6:09 PM, Jeffrey Tan via lldb-dev 
>> > > wrote:
>> >
>> > This is crazy. I tried 10MB, not working, then 20MB still not working. I 
>> > got around 80K frames stack overflow, this is clearly an infinitely loop 
>> > in "d_print_comp":
>> >
>> > (gdb) bt
>> > #0  0x7f35925511e1 in d_print_comp (dpi=0x7f3586747c00, options=17, 
>> > dc=0x7f3586743bb0) at cp-demangle.c:4324
>> > #1  0x7f35925511e6 in d_print_comp (dpi=dpi@entry=0x7f3586747c00, 
>> > options=options@entry=17, dc=0x7f3586743be0) at cp-demangle.c:4324
>> > #2  0x7f3592551010 in d_print_comp (dpi=0x7f3586747c00, options=17, 
>> > dc=0x7f3586743ca0) at cp-demangle.c:4489
>> > #3  0x7f35925511e6 in d_print_comp (dpi=dpi@entry=0x7f3586747c00, 
>> > options=options@entry=17, dc=0x7f3586743cd0) at cp-demangle.c:4324
>> > #4  0x7f3592551010 in d_print_comp (dpi=0x7f3586747c00, options=17, 
>> > dc=0x7f3586744030) at cp-demangle.c:4489
>> > #5  0x7f3592554353 in d_print_mod (dpi=dpi@entry=0x7f3586747c00, 
>> > options=options@entry=17, mod=) at cp-demangle.c:5539
>> > #6  0x7f3592554dbe in d_print_mod_list (dpi=dpi@entry=0x7f3586747c00, 
>> > options=options@entry=17, mods=mods@entry=0x7f358534a7b0, 
>> > suffix=suffix@entry=0) at cp-demangle.c:5468
>> > #7  0x7f35925556a1 in d_print_function_type 
>> > (dpi=dpi@entry=0x7f3586747c00, options=options@entry=17, 
>> > mods=0x7f358534a7b0, dc=0x7f3586744138) at cp-demangle.c:5609
>> > #8  0x7f359255010c in d_print_comp (dpi=dpi@entry=0x7f3586747c00, 
>> > options=options@entry=17, dc=0x7f3586744138) at cp-demangle.c:4808
>> > #9  0x7f359254fa01 in d_print_comp (dpi=0x7f3586747c00, options=17, 
>> > dc=0x7f3586744150) at cp-demangle.c:4434
>> > .
>> >
>> > #79590 0x7f35925526b3 in d_print_comp (dpi=dpi@entry=0x7f3586747c00, 
>> > options=options@entry=17, dc=0x7f3586744108) at cp-demangle.c:4529
>> > #79591 0x7f359255023b in d_print_comp (dpi=dpi@entry=0x7f3586747c00, 
>> > options=options@entry=17, dc=0x7f3586744408) at cp-demangle.c:4742
>> > #79592 0x7f3592553448 in d_print_comp (dpi=dpi@entry=0x7f3586747c00, 
>> > options=options@entry=17, dc=0x7f3586744450) at cp-demangle.c:4793
>> > #79593 0x7f359254fa01 in d_print_comp (dpi=dpi@entry=0x7f3586747c00, 
>> > options=options@entry=17, dc=dc@entry=0x7f3586744468) at cp-demangle.c:4434
>> > #79594 0x7f3592555f53 in d_demangle_callback (options=17, 
>> > 

Re: [lldb-dev] Weird stop stack while hitting breakpoint

[Jim Ingham via lldb-dev]

The selected thread should be getting set.  You didn’t include the code for 
_send_paused_notification so I don’t know what that does, but if 
SBProcess::GetSelectedThread wasn’t returning a thread with a valid stop 
reason, then there’s some bug somewhere.  That’s all done in generic code, 
however, so I’m not sure how that would happen.

Jim

> On Mar 18, 2016, at 5:23 PM, Jeffrey Tan  wrote:
> 
> Thanks for the info. I understand the multiple threads stopping at the same 
> time issue. But I would think we should at least pick one stopped thread and 
> set it as selected thread instead of some random thread with stop reason 
> None. Also, in my repro case, there is only one thread that has stop reason, 
> so the heuristics should be pretty trivial to set selected thread to that one.
> I have workaround this issue with the suggestion but I think there is a 
> bug(on Linux) here.
> 
> On Fri, Mar 18, 2016 at 4:40 PM, Jim Ingham  > wrote:
> On many platforms (OS X for sure) there’s no guarantee that when you stop you 
> will only have hit one breakpoint on one thread.  On OS X in multithreaded 
> programs, it is not at all uncommon to have many threads hit breakpoint(s) by 
> the the time the stop gets reported.  So you just have to iterate over all 
> the threads and see what their stop reasons are.  Note that it isn’t just 
> breakpoints, you might have been stepping on thread A, and when you stop, 
> thread A will have stopped with “plan complete” for the step operation, and 
> thread B for some other breakpoint.
> 
> So when you get a stop event you have to iterate over the threads and see why 
> they have stopped.
> 
> LLDB will set one of the threads as the selected thread, using some 
> heuristics (if you were stepping on thread A & threads A & B stopped with 
> breakpoints, thread A will be the selected thread, etc…)  So you could just 
> show the selected thread, but really you want to figure out what all the 
> threads are doing.
> 
> Jim
> 
>> On Mar 18, 2016, at 4:25 PM, Jeffrey Tan > > wrote:
>> 
>> 
>> Hmm, interesting, I got the stop reason from the 
>> lldb.SBProcess.GetProcessFromEvent(event).GetSelectedThread().GetStopReason().
>>  Is that thread not the one that stopped? But you are right, the breakpoint 
>> hits in another thread:
>> 
>> thread #87: tid = 1006769, 0x0042eacd 
>> biggrep_master_server_async`facebook::biggrep::BigGrepMasterAsync::future_find(this=0x7f3ea2d74fd0,
>>  corpus=error: summary string parsing error, needle=error: summary string 
>> parsing error, options=0x7f3e899fc7e0) + 51 at 
>> BigGrepMasterAsync.cpp:171, name = 'BigGrep-pri3-32', stop reason = 
>> breakpoint 1.1
>> 
>> How do I know which thread hits the breakpoint?
>> 
>> Jeffrey
>> 
>> 
>> On Fri, Mar 18, 2016 at 4:12 PM, Jim Ingham > > wrote:
>> You only show one thread in your example.  Did another thread have a valid 
>> stop reason?  lldb shouldn’t be stopping for no reason anywhere…
>> 
>> Jim
>> 
>>> On Mar 18, 2016, at 4:08 PM, Jeffrey Tan via lldb-dev 
>>> > wrote:
>>> 
>>> Btw: the breakpoint I set is:
>>> "b BigGrepMasterAsync.cpp:171" which is not in any of the stopped stack 
>>> frames.
>>> 
>>> On Fri, Mar 18, 2016 at 3:47 PM, Jeffrey Tan >> > wrote:
>>> Hi,
>>> 
>>> Our IDE(wrapping lldb using python) works fine on Linux for simple hello 
>>> world cases. While trying a real world case, I found whenever we set a 
>>> source line breakpoint, then trigger the code path, lldb will send a 
>>> stopped state process event, with thread.GetStopReason() being None and 
>>> with weird callstack. Any ideas why do I get this stop stack(code is listed 
>>> at the end)? I have verified that if I do not set breakpoint and trigger 
>>> the same code path does not cause this stop event to generate.
>>> 
>>> bt
>>> * thread #1: tid = 952490, 0x7fd7cb2daa83 libc.so.6`__GI_epoll_wait + 
>>> 51, name = 'biggrep_master_'
>>>   * frame #0: 0x7fd7cb2daa83 libc.so.6`__GI_epoll_wait + 51
>>> frame #1: 0x0271189f 
>>> biggrep_master_server_async`epoll_dispatch(base=0x7fd7ca970800, 
>>> arg=0x7fd7ca62c1e0, tv=) + 127 at epoll.c:315
>>> frame #2: 0x0270f6d1 
>>> biggrep_master_server_async`event_base_loop(base=0x7fd7ca970800, 
>>> flags=) + 225 at event.c:524
>>> frame #3: 0x025f9378 
>>> biggrep_master_server_async`folly::EventBase::loopBody(this=0x7fd7ca945180,
>>>  flags=0) + 834 at EventBase.cpp:335
>>> frame #4: 0x025f900b 
>>> biggrep_master_server_async`folly::EventBase::loop(this=0x7fd7ca945180) 
>>> + 29 at EventBase.cpp:287
>>> frame #5: 0x025fa053 
>>> 

Re: [lldb-dev] Is it ok to use lldb_private from the driver?

[Jim Ingham via lldb-dev]

The driver used to have a bunch of lldb_private stuff in it, mostly to run the 
event loop, which Greg abstracted into SB API’s a while ago.  If it can be 
avoided, I’d rather not add it back in.  Our claim is folks should be able to 
write their own debugger interfaces (command line or gui) using the SB API’s, 
so it would be good if we stuck to that discipline as well.

I thought that the lldm-mi was pure SB API’s.  That seemed a virtue to me.

Jim

> On Mar 18, 2016, at 9:54 AM, Zachary Turner via lldb-dev 
>  wrote:
> 
> I notice everything uses SB classes only.  Is this a hard requirement?  We 
> have a bit of cruft in all of the top-level executables (lldb-server, 
> lldb-mi, lldb) that could be shared if we could move it into Host, but then 
> the 3 drivers would have to #include "lldb/Host/Host.h".  Note that lldb-mi 
> and lldb-server already do this, it's only lldb that doesn't.  Is this ok?
> 
> If not, I can always add a method to SBHostOS and just not add a 
> corresponding swig interface definition for it (so it wouldn't be accessible 
> from Python), which would achieve basically the same effect.
> ___
> 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] Is it ok to use lldb_private from the driver?

[Jim Ingham via lldb-dev]

If I were writing a Pure Python interface to lldb, could I use the Python 
signal facilities to abstract the functionality you are trying to abstract 
through Host::Signal?  If so, then I’d have no objection to only doing it in 
the C++ API’s (maybe with a note to that effect in the headers.)

If not, as long as what you are doing didn’t preclude somebody implementing a 
Python version later if they were sufficiently motivated, I don’t think it 
would be a requirement on you to do it now.

Jim

> On Mar 18, 2016, at 10:20 AM, Zachary Turner  wrote:
> 
> Is it ok to add a public API that isn't interfaced to Python?  In this case 
> the culprit is the signal() function.  Windows doesn't really support signal 
> in the same way that other platforms do, so there's some code in each driver 
> that basically defines a signal function, and then if you're unlucky when you 
> build, or accidentally include the wrong header file (even indirectly), 
> you'll get multiply defined symbol errors.
> 
> So what I wanted to do was make a Host::Signal() that on Windows had our 
> custom implementation, and on other platforms just called signal.  But it 
> returns and accepts function pointers, and making this work through the 
> python api is going to be a big deal, if not flat out impossible.
> 
> The idea is that instead of writing signal() everywhere, we would write 
> lldb_private::Host::Signal() everywhere instead.  
> 
> On Fri, Mar 18, 2016 at 10:16 AM Jim Ingham  > wrote:
> The driver used to have a bunch of lldb_private stuff in it, mostly to run 
> the event loop, which Greg abstracted into SB API’s a while ago.  If it can 
> be avoided, I’d rather not add it back in.  Our claim is folks should be able 
> to write their own debugger interfaces (command line or gui) using the SB 
> API’s, so it would be good if we stuck to that discipline as well.
> 
> I thought that the lldm-mi was pure SB API’s.  That seemed a virtue to me.
> 
> Jim
> 
> > On Mar 18, 2016, at 9:54 AM, Zachary Turner via lldb-dev 
> > > wrote:
> >
> > I notice everything uses SB classes only.  Is this a hard requirement?  We 
> > have a bit of cruft in all of the top-level executables (lldb-server, 
> > lldb-mi, lldb) that could be shared if we could move it into Host, but then 
> > the 3 drivers would have to #include "lldb/Host/Host.h".  Note that lldb-mi 
> > and lldb-server already do this, it's only lldb that doesn't.  Is this ok?
> >
> > If not, I can always add a method to SBHostOS and just not add a 
> > corresponding swig interface definition for it (so it wouldn't be 
> > accessible from Python), which would achieve basically the same effect.
> > ___
> > 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] [Bug 26978] New: LLDB stack overflow while dealing with symbols for a process on Linux

[Jim Ingham via lldb-dev]

The code that has gotten itself into an infinite loop here is the libiberty 
cp-demangle.c, which is part of the C++ runtime libraries for the system you 
are on.  So we can't do anything to fix bugs with that.  You might make sure 
there isn't a newer version of that than the one on your system, but other than 
fixing the bugs in it yourself, there's not much we can do about that one.

However, if you build lldb with LLDB_USE_BUILTIN_DEMANGLER defined it will do 
two things, it will trigger the FastDemangler that Kate wrote, and if that 
succeeds, yay!  Otherwise it will fall back to another demangler that comes 
along with the C++ standard libraries from the llvm project.  That one, like 
the cp-demangle.c is very stack intensive, but it might not have whatever bug 
you are triggering in the libiberty one.  And if it does have crashing bugs 
somebody in the clang world could fix them...

Anyway, you might try that and see if you have any more luck.  IIRC, FreeBSD 
uses the llvm one in favor of the libiberty one.

Jim


> On Mar 17, 2016, at 6:09 PM, Jeffrey Tan via lldb-dev 
>  wrote:
> 
> This is crazy. I tried 10MB, not working, then 20MB still not working. I got 
> around 80K frames stack overflow, this is clearly an infinitely loop in 
> "d_print_comp":
> 
> (gdb) bt
> #0  0x7f35925511e1 in d_print_comp (dpi=0x7f3586747c00, options=17, 
> dc=0x7f3586743bb0) at cp-demangle.c:4324
> #1  0x7f35925511e6 in d_print_comp (dpi=dpi@entry=0x7f3586747c00, 
> options=options@entry=17, dc=0x7f3586743be0) at cp-demangle.c:4324
> #2  0x7f3592551010 in d_print_comp (dpi=0x7f3586747c00, options=17, 
> dc=0x7f3586743ca0) at cp-demangle.c:4489
> #3  0x7f35925511e6 in d_print_comp (dpi=dpi@entry=0x7f3586747c00, 
> options=options@entry=17, dc=0x7f3586743cd0) at cp-demangle.c:4324
> #4  0x7f3592551010 in d_print_comp (dpi=0x7f3586747c00, options=17, 
> dc=0x7f3586744030) at cp-demangle.c:4489
> #5  0x7f3592554353 in d_print_mod (dpi=dpi@entry=0x7f3586747c00, 
> options=options@entry=17, mod=) at cp-demangle.c:5539
> #6  0x7f3592554dbe in d_print_mod_list (dpi=dpi@entry=0x7f3586747c00, 
> options=options@entry=17, mods=mods@entry=0x7f358534a7b0, 
> suffix=suffix@entry=0) at cp-demangle.c:5468
> #7  0x7f35925556a1 in d_print_function_type 
> (dpi=dpi@entry=0x7f3586747c00, options=options@entry=17, mods=0x7f358534a7b0, 
> dc=0x7f3586744138) at cp-demangle.c:5609
> #8  0x7f359255010c in d_print_comp (dpi=dpi@entry=0x7f3586747c00, 
> options=options@entry=17, dc=0x7f3586744138) at cp-demangle.c:4808
> #9  0x7f359254fa01 in d_print_comp (dpi=0x7f3586747c00, options=17, 
> dc=0x7f3586744150) at cp-demangle.c:4434
> .
> 
> #79590 0x7f35925526b3 in d_print_comp (dpi=dpi@entry=0x7f3586747c00, 
> options=options@entry=17, dc=0x7f3586744108) at cp-demangle.c:4529
> #79591 0x7f359255023b in d_print_comp (dpi=dpi@entry=0x7f3586747c00, 
> options=options@entry=17, dc=0x7f3586744408) at cp-demangle.c:4742
> #79592 0x7f3592553448 in d_print_comp (dpi=dpi@entry=0x7f3586747c00, 
> options=options@entry=17, dc=0x7f3586744450) at cp-demangle.c:4793
> #79593 0x7f359254fa01 in d_print_comp (dpi=dpi@entry=0x7f3586747c00, 
> options=options@entry=17, dc=dc@entry=0x7f3586744468) at cp-demangle.c:4434
> #79594 0x7f3592555f53 in d_demangle_callback (options=17, 
> opaque=0x7f3586742cc0, callback=0x7f359254b820 
> , dc=0x7f3586744468) at cp-demangle.c:4063
> #79595 0x7f3592555f53 in d_demangle_callback (mangled=,
> mangled@entry=0x0, callback=callback@entry=0x7f359254b820 
> , opaque=opaque@entry=0x7f3586747db0, 
> options=17) at cp-demangle.c:5865
> #79596 0x7f359255609f in __cxa_demangle (options=17, palc= pointer>, mangled=0x0) at cp-demangle.c:5886
> 
> #79597 0x7f359255609f in __cxa_demangle 
> (mangled_name=mangled_name@entry=0x7f3570e3d460 
> "_ZNSt9_Any_data9_M_accessIPPZN5folly6fibers12FiberManager16runInMainContextIZN8facebook8memcache15CacheClientImplINS6_17CControllerCommonINS1_7dynamic11multiOpSyncINS6_11McOperationILi11EEESt6vect"...,
>  output_buffer=output_buffer@entry=0x0, length=length@entry=0x0, 
> status=status@entry=0x0) at cp-demangle.c:5950
> #79598 0x7f359417cc57 in 
> lldb_private::Mangled::GetDemangledName(lldb::LanguageType) const 
> (this=this@entry=0x7f3584288310, 
> language=language@entry=lldb::eLanguageTypeC_plus_plus)
> at 
> /home/engshare/third-party2/lldb/3.8.0.rc3/src/llvm/tools/lldb/source/Core/Mangled.cpp:316
> 
> #79599 0x7f359427adca in lldb_private::Symtab::InitNameIndexes() 
> (this=0x7f35701a8ff0) at 
> /home/engshare/third-party2/lldb/3.8.0.rc3/src/llvm/tools/lldb/source/Symbol/Symtab.cpp:334
> #79600 0x7f359427c0b8 in 
> lldb_private::Symtab::FindAllSymbolsWithNameAndType(lldb_private::ConstString 
> const&, lldb::SymbolType, std::vector int> >&) (this=this@entry=0x7f35701a8ff0, name=..., 
> symbol_type=symbol_type@entry=lldb::eSymbolTypeAny, symbol_indexes=...) at 
> 

Re: [lldb-dev] Weird stop stack while hitting breakpoint

[Jim Ingham via lldb-dev]

On many platforms (OS X for sure) there’s no guarantee that when you stop you 
will only have hit one breakpoint on one thread.  On OS X in multithreaded 
programs, it is not at all uncommon to have many threads hit breakpoint(s) by 
the the time the stop gets reported.  So you just have to iterate over all the 
threads and see what their stop reasons are.  Note that it isn’t just 
breakpoints, you might have been stepping on thread A, and when you stop, 
thread A will have stopped with “plan complete” for the step operation, and 
thread B for some other breakpoint.

So when you get a stop event you have to iterate over the threads and see why 
they have stopped.

LLDB will set one of the threads as the selected thread, using some heuristics 
(if you were stepping on thread A & threads A & B stopped with breakpoints, 
thread A will be the selected thread, etc…)  So you could just show the 
selected thread, but really you want to figure out what all the threads are 
doing.

Jim

> On Mar 18, 2016, at 4:25 PM, Jeffrey Tan  wrote:
> 
> 
> Hmm, interesting, I got the stop reason from the 
> lldb.SBProcess.GetProcessFromEvent(event).GetSelectedThread().GetStopReason().
>  Is that thread not the one that stopped? But you are right, the breakpoint 
> hits in another thread:
> 
> thread #87: tid = 1006769, 0x0042eacd 
> biggrep_master_server_async`facebook::biggrep::BigGrepMasterAsync::future_find(this=0x7f3ea2d74fd0,
>  corpus=error: summary string parsing error, needle=error: summary string 
> parsing error, options=0x7f3e899fc7e0) + 51 at 
> BigGrepMasterAsync.cpp:171, name = 'BigGrep-pri3-32', stop reason = 
> breakpoint 1.1
> 
> How do I know which thread hits the breakpoint?
> 
> Jeffrey
> 
> 
> On Fri, Mar 18, 2016 at 4:12 PM, Jim Ingham  > wrote:
> You only show one thread in your example.  Did another thread have a valid 
> stop reason?  lldb shouldn’t be stopping for no reason anywhere…
> 
> Jim
> 
>> On Mar 18, 2016, at 4:08 PM, Jeffrey Tan via lldb-dev 
>> > wrote:
>> 
>> Btw: the breakpoint I set is:
>> "b BigGrepMasterAsync.cpp:171" which is not in any of the stopped stack 
>> frames.
>> 
>> On Fri, Mar 18, 2016 at 3:47 PM, Jeffrey Tan > > wrote:
>> Hi,
>> 
>> Our IDE(wrapping lldb using python) works fine on Linux for simple hello 
>> world cases. While trying a real world case, I found whenever we set a 
>> source line breakpoint, then trigger the code path, lldb will send a stopped 
>> state process event, with thread.GetStopReason() being None and with weird 
>> callstack. Any ideas why do I get this stop stack(code is listed at the 
>> end)? I have verified that if I do not set breakpoint and trigger the same 
>> code path does not cause this stop event to generate.
>> 
>> bt
>> * thread #1: tid = 952490, 0x7fd7cb2daa83 libc.so.6`__GI_epoll_wait + 
>> 51, name = 'biggrep_master_'
>>   * frame #0: 0x7fd7cb2daa83 libc.so.6`__GI_epoll_wait + 51
>> frame #1: 0x0271189f 
>> biggrep_master_server_async`epoll_dispatch(base=0x7fd7ca970800, 
>> arg=0x7fd7ca62c1e0, tv=) + 127 at epoll.c:315
>> frame #2: 0x0270f6d1 
>> biggrep_master_server_async`event_base_loop(base=0x7fd7ca970800, 
>> flags=) + 225 at event.c:524
>> frame #3: 0x025f9378 
>> biggrep_master_server_async`folly::EventBase::loopBody(this=0x7fd7ca945180,
>>  flags=0) + 834 at EventBase.cpp:335
>> frame #4: 0x025f900b 
>> biggrep_master_server_async`folly::EventBase::loop(this=0x7fd7ca945180) 
>> + 29 at EventBase.cpp:287
>> frame #5: 0x025fa053 
>> biggrep_master_server_async`folly::EventBase::loopForever(this=0x7fd7ca945180)
>>  + 109 at EventBase.cpp:435
>> frame #6: 0x01e24b72 
>> biggrep_master_server_async`apache::thrift::ThriftServer::serve(this=0x7fd7ca96d710)
>>  + 110 at ThriftServer.cpp:365
>> frame #7: 0x004906bc 
>> biggrep_master_server_async`facebook::services::ServiceFramework::startFramework(this=0x7ffc06776140,
>>  waitUntilStop=true) + 1942 at ServiceFramework.cpp:885
>> frame #8: 0x0048fe6d 
>> biggrep_master_server_async`facebook::services::ServiceFramework::go(this=0x7ffc06776140,
>>  waitUntilStop=true) + 35 at ServiceFramework.cpp:775
>> frame #9: 0x004219a7 biggrep_master_server_async`main(argc=1, 
>> argv=0x7ffc067769d8) + 2306 at BigGrepMasterServerAsync.cpp:134
>> frame #10: 0x7fd7cb1ed0f6 libc.so.6`__libc_start_main + 246
>> frame #11: 0x00420bfc biggrep_master_server_async`_start + 41 at 
>> start.S:122
>> 
>> Here is the code snippet of handling code:
>> def _handle_process_event(self, event):
>> # Ignore non-stopping events.
>> if lldb.SBProcess.GetRestartedFromEvent(event):
>> log_debug('Non stopping event: %s' 

Re: [lldb-dev] SymbolFile::FindGlobalVariables

[Jim Ingham via lldb-dev]

lldb uses DWARF expressions internally as a convenient language to represent 
locations of values.  We had to pick some representation, and the DWARF 
expression was powerful enough for our purposes, meant we didn't have to 
reinvent something that already existed, and had the added benefit that if you 
did your DWARF then you don't have to transcode. 

Jim

> On Mar 11, 2016, at 11:32 AM, Zachary Turner via lldb-dev 
>  wrote:
> 
> Also why does the lldb_private::Variable() class take a DWARFExpression to 
> its constructor?  Seems like this is wrong in the face of non-DWARF debug 
> information.
> 
> On Fri, Mar 11, 2016 at 11:02 AM Zachary Turner  wrote:
> I'm trying to implement this function for PDB.  There are two overloads:
> 
> uint32_t
> FindGlobalVariables (const ConstString , const CompilerDeclContext 
> *parent_decl_ctx, bool append, uint32_t max_matches, VariableList& variables)
> 
> uint32_t
> FindGlobalVariables(const RegularExpression& regex, bool append, uint32_t 
> max_matches, VariableList& variables)
> 
> I know how to implement the second overload, but not the first.  What is a 
> CompilerDeclContext?  Some comments in the DWARF implementation of the 
> function seem to imply it's related to namespaces, but there's a lot of 
> strange code that I don't understand.  What is the relationship between a 
> namespace and a symbol file?  And why does `DeclContextMatchesThisSymbolFile` 
> contain no code at all that accesses any property of the symbol file?  It 
> just checks if decl_ctx->GetTypeSystem()->GetMinimumLanguage(nullptr) == 
> decl_ctx->GetTypeSystem(), which appears to have nothing to do with any 
> symbol file.
> 
> What user command or debugger operation results in FindGlobalVariables 
> getting called with this particular overload, and how does it build the 
> CompilerDeclContext?
> 
> On another note, why is the decl context stored as void* instead of having an 
> actual wrapper with an abstract interface such as ClangDeclContext / 
> JavaDeclContext, etc that all inherit from LanguageDeclContext, and pass the 
> LanguageDeclContext around instead of a void*?
> ___
> 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

[Jim Ingham via lldb-dev]

> 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] SBListener not using a shared_ptr internally? (Update: Segfault after r262863)

[Jim Ingham via lldb-dev]

Yes, that should work too.  The thing that doesn't work is to just let the C++ 
destructor chain tear down the debuggers you've made.  It should be possible to 
make that work, but nobody's had time to make that happen, and given you can 
avoid the crashes if you exit cleanly, it hasn't been a terribly high priority.

Jim

> On Mar 28, 2016, at 11:48 AM, Paul Peet  wrote:
> 
> Ah, Thanks adding Debugger::Destroy at the end of my code made the
> segfaults disappear.
> Also as far as I understood the lldb code (Core/Debugger.cpp) it
> should also be possible to call SBDebugger::Terminate() for "destroy"
> all instances of lldb related objects.
> 
> 2016-03-28 20:22 GMT+02:00 Jim Ingham :
>> lldb doesn't currently work if you leave the process of cleaning up to the 
>> C++ destructor chain.  You need to call Debugger::Destroy on your way out.
>> 
>> I think there's a bunch more cleanup than just the broadcaster/listener 
>> stuff before we'll do this right.
>> 
>> Jim
>> 
>>> On Mar 28, 2016, at 8:55 AM, Paul Peet  wrote:
>>> 
>>> Hey again,
>>> 
>>> I've noticing segfaults after r262863
>>> (dc5ef2da510f3adba99cd8b2fe18c2e6d417227d).
>>> Could you try reproducing this bug with this code please?
>>> 
>>> int main() {
>>> using namespace lldb;
>>> 
>>> SBDebugger::Initialize();
>>> 
>>> SBDebugger debugger = SBDebugger::Create(true);
>>> if(!debugger.IsValid()) {
>>>   return 1;
>>> }
>>> 
>>> SBTarget target = debugger.CreateTarget("/home/dev/helloWorld/main");
>>> if(!target.IsValid()) {
>>>   return 1;
>>> }
>>> 
>>> const char* args[] = { "/home/dev/helloWorld/main", 0 };
>>> const char* env[] = { 0 };
>>> 
>>> SBLaunchInfo launch_info(args);
>>> launch_info.SetEnvironmentEntries(env, true);
>>> launch_info.SetWorkingDirectory("/home/dev/helloWorld");
>>> launch_info.SetLaunchFlags(eLaunchFlagStopAtEntry);
>>> 
>>> SBError error;
>>> SBProcess process = target.Launch(launch_info, error);
>>> 
>>> return 0;
>>> }
>>> 
>>> I tried to build lldb with and without the above commit and it turns
>>> out that the revision is causing the segfault when simply running that
>>> code (When it's exiting).
>>> 
>>> This is the backtrace:
>>> 
>>> #0  0x55b03b00 in ?? ()
>>> #1  0x771be1aa in
>>> lldb_private::Broadcaster::BroadcasterImpl::RestoreBroadcaster() ()
>>> from /usr/lib/liblldb.so.3.8.0
>>> #2  0x7748b674 in
>>> lldb_private::process_gdb_remote::GDBRemoteCommunicationClient::SendPacketAndWaitForResponse(char
>>> const*, unsigned long, StringExtractorGDBRemote&, bool) () from
>>> /usr/lib/liblldb.so.3.8.0
>>> #3  0x7748e89d in
>>> lldb_private::process_gdb_remote::GDBRemoteCommunicationClient::SendGDBStoppointTypePacket(lldb_private::process_gdb_remote::GDBStoppointType,
>>> bool, unsigned long, unsigned int) () from /usr/lib/liblldb.so.3.8.0
>>> #4  0x7746fdab in
>>> lldb_private::process_gdb_remote::ProcessGDBRemote::DisableBreakpointSite(lldb_private::BreakpointSite*)
>>> () from /usr/lib/liblldb.so.3.8.0
>>> #5  0x7733938b in std::_Function_handler>> (lldb_private::BreakpointSite*),
>>> lldb_private::Process::DisableAllBreakpointSites()::{lambda(lldb_private::BreakpointSite*)#1}>::_M_invoke(std::_Any_data
>>> const&, lldb_private::BreakpointSite*&&) () from
>>> /usr/lib/liblldb.so.3.8.0
>>> #6  0x7716ae4f in
>>> lldb_private::BreakpointSiteList::ForEach(std::function>> (lldb_private::BreakpointSite*)> const&) () from
>>> /usr/lib/liblldb.so.3.8.0
>>> #7  0x7733ba9f in
>>> lldb_private::Process::DisableAllBreakpointSites() () from
>>> /usr/lib/liblldb.so.3.8.0
>>> #8  0x7734a58c in lldb_private::Process::Destroy(bool) () from
>>> /usr/lib/liblldb.so.3.8.0
>>> #9  0x7734aa2d in lldb_private::Process::Finalize() () from
>>> /usr/lib/liblldb.so.3.8.0
>>> #10 0x771d3fe0 in lldb_private::Debugger::Clear() () from
>>> /usr/lib/liblldb.so.3.8.0
>>> #11 0x771d97cf in lldb_private::Debugger::~Debugger() () from
>>> /usr/lib/liblldb.so.3.8.0
>>> #12 0x771da0c8 in
>>> std::_Sp_counted_ptr>> (__gnu_cxx::_Lock_policy)2>::_M_dispose() () from
>>> /usr/lib/liblldb.so.3.8.0
>>> #13 0x771cdceb in
>>> std::vector>> std::allocator >::~vector()
>>> () from /usr/lib/liblldb.so.3.8.0
>>> #14 0x760d9c38 in __run_exit_handlers () from /usr/lib/libc.so.6
>>> #15 0x760d9c85 in exit () from /usr/lib/libc.so.6
>>> #16 0x760c4717 in __libc_start_main () from /usr/lib/libc.so.6
>>> #17 0x4f69 in _start ()
>>> 
>>> 2016-03-25 22:42 GMT+01:00 Jim Ingham :
 What version of the lldb sources are you working with?  I changed the 
 SBListener over to using only the ListenerSP internally
 in r262863.
 
 Jim
 
> On Mar 25, 2016, at 1:03 PM, Paul Peet via lldb-dev 
>  wrote:
> 
> Hey,
> 

Re: [lldb-dev] How to enumerate stopped threads in C++ API?

[Jim Ingham via lldb-dev]

I'm surprised that this turns out to be a bottleneck.  All the work to create 
the threads should have been done when you stopped, so this should just be 
running over a vector that already exists and pulling a field out.  Can you 
profile this and see what is actually slow?

Jim

> On Mar 3, 2016, at 9:54 AM, Eugene Birukov via lldb-dev 
>  wrote:
> 
> Hi,
> 
> I am working on a custom debugger on Linux and I am using LLDB C++ API for 
> that. So far, from the functionality point of view the life is good, but I am 
> running into severe performance issue.
> 
> The problem is that the target application has literally hundreds of threads, 
> and when the target process stops, I need to identify all the threads that 
> have non-trivial stop reason. So, I am doing something like that:
> 
> // Loop over threads
> int numThreads = m_Process.GetNumThreads();
> for (int threadIndex = 0; threadIndex < numThreads; ++threadIndex)
> {
> // Inspect the thread state
> sbThread = m_Process.GetThreadAtIndex(threadIndex);
> stopReason = sbThread.GetStopReason();
> ...
> 
> 
> Well, this loop turns out to be a bottleneck. 
> 
> So, is there any way to find all the stopped threads without iterating over 
> the whole world?
> 
> Thanks,
> Eugene
> 
> 
> ___
> 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] SBListener not using a shared_ptr internally? (Update: Segfault after r262863)

[Jim Ingham via lldb-dev]

lldb doesn't currently work if you leave the process of cleaning up to the C++ 
destructor chain.  You need to call Debugger::Destroy on your way out.  

I think there's a bunch more cleanup than just the broadcaster/listener stuff 
before we'll do this right.

Jim

> On Mar 28, 2016, at 8:55 AM, Paul Peet  wrote:
> 
> Hey again,
> 
> I've noticing segfaults after r262863
> (dc5ef2da510f3adba99cd8b2fe18c2e6d417227d).
> Could you try reproducing this bug with this code please?
> 
> int main() {
>  using namespace lldb;
> 
>  SBDebugger::Initialize();
> 
>  SBDebugger debugger = SBDebugger::Create(true);
>  if(!debugger.IsValid()) {
>return 1;
>  }
> 
>  SBTarget target = debugger.CreateTarget("/home/dev/helloWorld/main");
>  if(!target.IsValid()) {
>return 1;
>  }
> 
>  const char* args[] = { "/home/dev/helloWorld/main", 0 };
>  const char* env[] = { 0 };
> 
>  SBLaunchInfo launch_info(args);
>  launch_info.SetEnvironmentEntries(env, true);
>  launch_info.SetWorkingDirectory("/home/dev/helloWorld");
>  launch_info.SetLaunchFlags(eLaunchFlagStopAtEntry);
> 
>  SBError error;
>  SBProcess process = target.Launch(launch_info, error);
> 
>  return 0;
> }
> 
> I tried to build lldb with and without the above commit and it turns
> out that the revision is causing the segfault when simply running that
> code (When it's exiting).
> 
> This is the backtrace:
> 
> #0  0x55b03b00 in ?? ()
> #1  0x771be1aa in
> lldb_private::Broadcaster::BroadcasterImpl::RestoreBroadcaster() ()
> from /usr/lib/liblldb.so.3.8.0
> #2  0x7748b674 in
> lldb_private::process_gdb_remote::GDBRemoteCommunicationClient::SendPacketAndWaitForResponse(char
> const*, unsigned long, StringExtractorGDBRemote&, bool) () from
> /usr/lib/liblldb.so.3.8.0
> #3  0x7748e89d in
> lldb_private::process_gdb_remote::GDBRemoteCommunicationClient::SendGDBStoppointTypePacket(lldb_private::process_gdb_remote::GDBStoppointType,
> bool, unsigned long, unsigned int) () from /usr/lib/liblldb.so.3.8.0
> #4  0x7746fdab in
> lldb_private::process_gdb_remote::ProcessGDBRemote::DisableBreakpointSite(lldb_private::BreakpointSite*)
> () from /usr/lib/liblldb.so.3.8.0
> #5  0x7733938b in std::_Function_handler (lldb_private::BreakpointSite*),
> lldb_private::Process::DisableAllBreakpointSites()::{lambda(lldb_private::BreakpointSite*)#1}>::_M_invoke(std::_Any_data
> const&, lldb_private::BreakpointSite*&&) () from
> /usr/lib/liblldb.so.3.8.0
> #6  0x7716ae4f in
> lldb_private::BreakpointSiteList::ForEach(std::function (lldb_private::BreakpointSite*)> const&) () from
> /usr/lib/liblldb.so.3.8.0
> #7  0x7733ba9f in
> lldb_private::Process::DisableAllBreakpointSites() () from
> /usr/lib/liblldb.so.3.8.0
> #8  0x7734a58c in lldb_private::Process::Destroy(bool) () from
> /usr/lib/liblldb.so.3.8.0
> #9  0x7734aa2d in lldb_private::Process::Finalize() () from
> /usr/lib/liblldb.so.3.8.0
> #10 0x771d3fe0 in lldb_private::Debugger::Clear() () from
> /usr/lib/liblldb.so.3.8.0
> #11 0x771d97cf in lldb_private::Debugger::~Debugger() () from
> /usr/lib/liblldb.so.3.8.0
> #12 0x771da0c8 in
> std::_Sp_counted_ptr (__gnu_cxx::_Lock_policy)2>::_M_dispose() () from
> /usr/lib/liblldb.so.3.8.0
> #13 0x771cdceb in
> std::vector std::allocator >::~vector()
> () from /usr/lib/liblldb.so.3.8.0
> #14 0x760d9c38 in __run_exit_handlers () from /usr/lib/libc.so.6
> #15 0x760d9c85 in exit () from /usr/lib/libc.so.6
> #16 0x760c4717 in __libc_start_main () from /usr/lib/libc.so.6
> #17 0x4f69 in _start ()
> 
> 2016-03-25 22:42 GMT+01:00 Jim Ingham :
>> What version of the lldb sources are you working with?  I changed the 
>> SBListener over to using only the ListenerSP internally
>> in r262863.
>> 
>> Jim
>> 
>>> On Mar 25, 2016, at 1:03 PM, Paul Peet via lldb-dev 
>>>  wrote:
>>> 
>>> Hey,
>>> 
>>> I am currently working on lldb bindings for javascript (v8) but it
>>> seems that the API is giving me some troubles.
>>> 
>>> What I am doing is to basically wrap SB* objects into V8 objects, and
>>> since SB objects contain a shared_ptr into an internal class I think I
>>> can simply copy construct them.
>>> 
>>> To return a wrapped SB object by some Javascript function, I am simply
>>> copy constructing the SB object into the wrapper object which is
>>> dynamically allocated and when the Javascript object is garbage
>>> collected it will also destroy the SBObject (And also the shared_ptr,
>>> So it should be save I guess?).
>>> 
>>> Okay, so far so good but I detected some inconsistency when trying to
>>> wrap SBListener. The deal was to make SBListener::WaitForEvent
>>> non-blocking, to do that I am creating a new thread which calls
>>> WaitForEvents, when it returns and the event is valid, the callbacks
>>> given from the 

Re: [lldb-dev] break on exceptions/windows

[Jim Ingham via lldb-dev]

The exception breakpoints Greg is talking about are language exceptions (C++ 
throws, Swift Errors and the like.)

I don't know what kind of exception you are talking about here, but at least 
from a command interface standpoint, it would be good to keep alike things that 
actually are alike, but only if they ARE actually alike.

Jim

> On Apr 4, 2016, at 10:07 AM, Greg Clayton  wrote:
> 
> You should talk to Jim Ingham on this. We have special exception breakpoints 
> that we did for Swift and you will want to follow the same methodology. I am 
> not sure what the methodology is so I'm CC'ing Jim so can can comment.
> 
> Greg
>> On Apr 4, 2016, at 9:52 AM, Zachary Turner via lldb-dev 
>>  wrote:
>> 
>> Take a look at ProcessWindowsLive.cpp in Plugins/Process/Windows.  There's a 
>> function called ProcessWindowsLive::OnDebugException.  If you're working in 
>> a fork and you don't intend to upstream any changes, you could just modify 
>> the default case of the switch statement there to not return 
>> ExceptionResult::SendToApplication.
>> 
>> If you wanted to upstream something, you'd probably want a way to specify 
>> what types of exceptions to break on.  For this you'd need to implement a 
>> new command so that you could do something like "break set --exception 
>> 0xC005" and pass that information to the ProcessWindowsLive plugin 
>> somehow, so that it could decide when to break and when to pass it on to the 
>> application for a second chance.
>> 
>> On Mon, Apr 4, 2016 at 8:26 AM Carlo Kok  wrote:
>> 
>> 
>> Op 2016-04-04 om 16:00 schreef Zachary Turner:
>>> Not possible currently, although it wouldn't be too hard to add. Would
>>> be a welcome feature if you are interested
>> 
>> 
>> I'm (obviously?) interested. But wouldn't know where to start.
>> 
>> --
>> Carlo Kok
>> RemObjects Software
>> ___
>> 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] break on exceptions/windows

[Jim Ingham via lldb-dev]

> On Apr 4, 2016, at 11:48 AM, Carlo Kok  wrote:
> 
> 
> 
> Op 2016-04-04 om 20:41 schreef Greg Clayton:
>> 
>>> On Apr 4, 2016, at 11:36 AM, Carlo Kok  wrote:
> 
 
>>> 
>>> There should be a way then to do a "break on every exception", instead of 
>>> just 1 specific code.
>> 
>> That would be easy with the --exception-name:
>> 
>> (lldb) breakpoint set --exception-name=all
>> 
>>> and some way for the api to get the payload (which can have a variable 
>>> number of parameters)
>> 
>> What are you thinking here? Example?
> 
> I have a frontend language (and I imagine lots of others have one) where I 
> can throw exceptions. Windows has no predefined way of how an exception 
> object is formatted, you give it a list of pointer sized ints and a count, 
> and that's what it fills the exception object with, for example I pass:
> [0] Return address
> [1] frame pointer
> [2] Class instance of the exception object
> with my custom exception code.
> 
> msvc does the same with completely different values. Other languages will 
> have their own values. When using the api I would want access to the code (To 
> know of it's mine, these are the cods Zachery Turner mentioned) and the 
> payload (to get access to the object) so that I show what exception occurred 
> and turn it into a string representation.

Language exceptions are a general class of thing, and those should all be 
treated similarly if possible.

The way you would do this for your new language is to would add a 
LanguageRuntime for your language, and that would implement 
CreateExceptionBreakpoint using a BreakpointResolverWindowsException for the 
correct exception code.  The Object filtering is done using 
"BreakpointPreconditions", which are a way for a breakpoint to stick some code 
that gets called right when the breakpoint is hit before any of the other 
ShouldStop machinery takes over.  When you make the breakpoint you would pass 
the "thrown object specifier" to the breakpoint, which would make an 
appropriate precondition that would know how to dig out the object and compare.

So you would see:

(lldb) breakpoint set -E MyNewLanguage -O MyObjectName

This is currently only implemented in Swift, though the needed infrastructure 
is present in the llvm tree.

If there are other things you want to do that aren't generalizable, then we 
should treat them as opaque data that gets passed to the platform and it will 
know how to make the resolver & if needed precondition to do the filtering.

Jim


> 
> ---
> Carlo Kok
> RemObjects Software

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

Re: [lldb-dev] break on exceptions/windows

[Jim Ingham via lldb-dev]

Interesting.  

For the other windows exceptions, could we do something abstract like:

(lldb) break set --platform 

(-P for short) to set a "platform breakpoint", where "data" is a string that 
the current platform will understand, but the breakpoint machinery doesn't have 
to.

The way breakpoints work internally is that somebody provides a 
"BreakpointResolver" subclass which gets called when anything interesting 
happens in the program (rerun, shared library load, etc).  It's the 
BreakpointResolver's job to add locations to the breakpoint, describe itself 
and the like.  But this is a fairly abstract interface, and it wouldn't be hard 
to have a Platform function that got passed "data" and returned a breakpoint 
resolver to turn on the watch for these exceptions.

Then when the breakpoint gets set, the model is Breakpoints have 
"BreakpointLocations" which each add one place a stop might occur: a 
"BreakpointSite".  The division between Sites & Locations is because two 
logically different Locations could map to the same physical Site.  Then the 
Sites are used at the lowest level to map a stop reason back into the 
breakpoint(s) that caused it.  To date, the only BreakpointSites are PC based, 
so the BreakpointList gets asked "is there a site at this PC".  But that all 
happens in the process plugins, so it wouldn't be hard to map other stop 
reasons to particular sites.  The lower layers of the process (e.g. 
ProcessGDBRemote) figure out which site maps to the stop reason, and makes a 
StopInfoBreakpoint with that BreakpointSite.  And after that the Site -> 
Location -> Breakpoint logic is done w/o much care how the Site actually works.


WRT language exceptions in specific, in lldb you say:

(lldb) break set -E c++

to break on C++ exception throws.  You would say:

(lldb) break set -E c++ -O 

to restrict the exception throw to a particular object type, except I haven't 
implemented this for anything but Swift errors yet, but it wouldn't be hard to 
do that.  So regardless of what we do with the other Windows exceptions, we 
should implement the language exceptions consistently this way at the command 
line level just to keep things consistent.  But again, once we're able to hand 
out "BreakpointResolverWindowsExceptions" in general, we could create them on 
Windows for the C++ ABI as well (another reason you'll probably want a Windows 
C++ language runtime since it's the itanium ABI that does this job on other 
platforms.  The object filtering is mostly runtime ABI work - to figure out the 
thrown exception from the throw site.  But that's just some ABI function that 
the general matching code would call.

This would be some work, for sure, but I don't think it would be terribly hard 
to do.

Jim
 



> On Apr 4, 2016, at 10:46 AM, Zachary Turner  wrote:
> 
> Windows works a little differently.  Windows has the notion of a Windows 
> exception, which the best way I can describe it is like a signal.  But it's 
> an arbitrary 32-bit value, and there are hundreds, if not thousands of 
> different values.  here's a few:
> 
> 0x40010005   Ctrl+C
> 0x8003  Breakpoint (e.g. int 3)
> 0x8004  Single Step
> 0xC005  Access violation
> 0xC01D  Illegal Instruction
> 0xC095  Integer overflow
> 0xE06D7363 C++ Exception
> 
> Note the last one.  It's interesting, because it illustrates that on Windows, 
> C++ exceptions are just Windows exceptions with a different code.  And if you 
> were to implement some other programming language such as swift on Windows, 
> you would probably even do it the same way, by finding an unused exception 
> code and raising it with your language-specific exception context.
> 
> When any of these happen in the inferior, the debugger gets a notification 
> (called a first-chance exception), and the debugger can decide what to do, 
> such as break into the debugger, or ignore it and pass it on to the 
> application
> 
> It's possible this makes more sense as a windows specific debugger command, 
> or perhaps a windows specific subcommand of the "break" command that is only 
> available if the selected target is windows.
> 
> Existing Windows debuggers allow exception breakpoints of this nature through 
> a consistent interface, with the ability to drill down into different types 
> of exceptions.  What I mean is, you can set the debugger to stop on all 
> access violations or all C++ exceptions, but you can get more advanced for 
> C++ exceptions and set an exception when a specific type is thrown (like a 
> std::string, for example).  The debugger would implement this by installing a 
> 0xE06D7363 exception breakpoint, and ignoring any where the type wasn't 
> std::string (by analyzing the context record).
> 
> So, there is at least one aspect of this work that shares some behavior with 
> how C++ language exceptions might work with clang on non-Windows platforms.  
> Being able to say "break when a std::string is thrown" is not OS-specific 

Re: [lldb-dev] break on exceptions/windows

[Jim Ingham via lldb-dev]

Yes, that's why I prefer a more abstract command interface than trying to be 
too specific about some abstract breakpoint.  So you'd just have:

Error
Platform::SetPlatformBreakpoint(lldb_private::Target *target, const char *data);

Then this can have any meaning that it needs to.  The other way to structure 
this is:

break set -P -key "KEY" -value "VALUE" 

Jim



> On Apr 4, 2016, at 11:36 AM, Carlo Kok  wrote:
> 
> 
> 
> Op 2016-04-04 om 20:30 schreef Greg Clayton:
>> 
>>> On Apr 4, 2016, at 11:24 AM, Zachary Turner  wrote:
>>> 
>>> It seems like we already have some precedent for conditional command 
>>> arguments.  For example:
>>> 
>>> (lldb) help platform process list
>>> ...
>>>-u  ( --uid  )
>>> [POSIX] Find processes that have a matching user ID.
>>> 
>>> So on Windows this argument doesn't make sense.  Could we make an argument 
>>> that is conditional on the *target* rather than the host?  Then, for 
>>> example, you could have something like this:
>>> 
>>> (lldb) help break set
>>> ...
>>>--code  ( --code  )
>>> [Windows Target] Break when the exception with code  is 
>>> raised.
>>> 
>>> How to plumb this to the ProcessWindows plugin is an open question, but 
>>> should be mostly mechanical.
>> 
>> This is like my suggestion of:
>> 
>> (lldb) breakpoint set --exception-code 0x40010005
>> 
>> The code can be passed to the current Platform along with the current target:
>> 
>> Error Platform::SetExceptionBreakpointWithExceptionCode 
>> (lldb_private::Target *target, uint64_t exception_code);
>> 
>> The process can be extracted from the target when the breakpoint needs to be 
>> resolved.
>> 
>> 
> 
> There should be a way then to do a "break on every exception", instead of 
> just 1 specific code.
> 
> and some way for the api to get the payload (which can have a variable number 
> of parameters)
> 
> -- 
> Carlo Kok
> RemObjects Software

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

Re: [lldb-dev] break on exceptions/windows

[Jim Ingham via lldb-dev]

If we're going this far, then we should just add a "catch" command, and have 
the platforms be able to add "catchable" things.  For instance, you could catch 
shared library loads, you could catch fork & exec, maybe IPC message sends and 
Windows exceptions.  Seems like they fit better in this model than as 
breakpoints.

Jim


> On Apr 4, 2016, at 2:28 PM, Greg Clayton  wrote:
> 
> We could add a "platform breakpoint set" command as a new stand alone 
> breakpoint mechanism and avoid messing with the "breakpoint set" command at 
> all. 
> 
> (lldb) platform breakpoint set ...
> 
> This would be passed to the current lldb_private::Platform plug-in for it to 
> parse as needed. Each platform can have their own options that are completely 
> custom.
> 
> 
> 
>> On Apr 4, 2016, at 1:27 PM, Zachary Turner  wrote:
>> 
>> Another option would be to have sub-sub commands.  Already when you mix so 
>> many options together, lots of the options don't make sense with each other. 
>>  What about
>> 
>> break set windows --exc-code=0xC005
>> 
>> This way all the windows specific stuff is wrapped up behind another 
>> subcommand, and you don't have to worry about consistency with other 
>> platforms' interfaces.
>> 
>> On Mon, Apr 4, 2016 at 1:18 PM Greg Clayton  wrote:
>> I really would rather avoid the key/value thing. I prefer the 
>> --exception-name and --exception-code and have the platform handle it. Seems 
>> cleaner.
>> 
>> Greg
>> 
>>> On Apr 4, 2016, at 11:41 AM, Jim Ingham  wrote:
>>> 
>>> Yes, that's why I prefer a more abstract command interface than trying to 
>>> be too specific about some abstract breakpoint.  So you'd just have:
>>> 
>>> Error
>>> Platform::SetPlatformBreakpoint(lldb_private::Target *target, const char 
>>> *data);
>>> 
>>> Then this can have any meaning that it needs to.  The other way to 
>>> structure this is:
>>> 
>>> break set -P -key "KEY" -value "VALUE"
>>> 
>>> Jim
>>> 
>>> 
>>> 
 On Apr 4, 2016, at 11:36 AM, Carlo Kok  wrote:
 
 
 
 Op 2016-04-04 om 20:30 schreef Greg Clayton:
> 
>> On Apr 4, 2016, at 11:24 AM, Zachary Turner  wrote:
>> 
>> It seems like we already have some precedent for conditional command 
>> arguments.  For example:
>> 
>> (lldb) help platform process list
>> ...
>>  -u  ( --uid  )
>>   [POSIX] Find processes that have a matching user ID.
>> 
>> So on Windows this argument doesn't make sense.  Could we make an 
>> argument that is conditional on the *target* rather than the host?  
>> Then, for example, you could have something like this:
>> 
>> (lldb) help break set
>> ...
>>  --code  ( --code  )
>>   [Windows Target] Break when the exception with code  is 
>> raised.
>> 
>> How to plumb this to the ProcessWindows plugin is an open question, but 
>> should be mostly mechanical.
> 
> This is like my suggestion of:
> 
> (lldb) breakpoint set --exception-code 0x40010005
> 
> The code can be passed to the current Platform along with the current 
> target:
> 
> Error Platform::SetExceptionBreakpointWithExceptionCode 
> (lldb_private::Target *target, uint64_t exception_code);
> 
> The process can be extracted from the target when the breakpoint needs to 
> be resolved.
> 
> 
 
 There should be a way then to do a "break on every exception", instead of 
 just 1 specific code.
 
 and some way for the api to get the payload (which can have a variable 
 number of parameters)
 
 --
 Carlo Kok
 RemObjects Software
>>> 
>> 
> 

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

Re: [lldb-dev] Bug with ThreadPlanStepRange::InRange, symbol context and target.source-map setting

[Jim Ingham via lldb-dev]

I talked with Greg about this before I posted the suggestion below, and having 
the LineEntry contain both mapped and unmapped FileSpec's was his suggestion... 
 But who knows what changes of heart a weekend might bring.

Jim

> On May 9, 2016, at 9:43 AM, Ted Woodward <ted.woodw...@codeaurora.org> wrote:
> 
> I'll defer to Greg on remapping FileSpecs in SymbolContexts - he's the one 
> who added it, in r168845:
> 
> commit 214d2a327feb2e5987d093c2b63c457ffbd1d677
> Author: Greg Clayton <gclay...@apple.com>
> Date:   Thu Nov 29 00:53:06 2012 +
> 
>
> 
>Make stack frames fix up their line table entries when the target has 
> source remappings. Also rearranged how the m_sc.target_sp was filled in so it 
> can be used during the StackFrame::GetSymbolContext(...) function.
> 
> 
> http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Target/StackFrame.cpp?r1=168845=168844=168845
> 
> --
> Qualcomm Innovation Center, Inc.
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a 
> Linux Foundation Collaborative Project
> 
> 
> -Original Message-
> From: jing...@apple.com [mailto:jing...@apple.com] 
> Sent: Friday, May 06, 2016 6:01 PM
> To: Ted Woodward <ted.woodw...@codeaurora.org>
> Cc: LLDB <lldb-dev@lists.llvm.org>
> Subject: Re: [lldb-dev] Bug with ThreadPlanStepRange::InRange, symbol context 
> and target.source-map setting
> 
> Another alternative would be to make the LineEntry hold both the remapped & 
> original file spec, and add an API to get the "original FileSpec".  Then 
> anybody who is holding onto a line entry or file spec derived therefrom will 
> know to compare the original file spec, since the remapped one is unreliable. 
>  Probably should move the remapping to the LineEntry 
> (LineEntry::ApplyFileMappings(Target ) so it is clear who is in charge 
> of this.  
> 
> Note, you absolutely should never use SourceMaps to remap FileSpecs that are 
> in the module's debug information, since these modules are shared among all 
> the Debugger's, and the Debuggers could have different SourceMaps.  So by 
> putting this explicitly in the LineEntry - which is not something we use to 
> store line information, it's just something we cons up to hand out when 
> requested - it might make that requirement clearer.
> 
> Jim
> 
> 
>> On May 6, 2016, at 3:49 PM, Jim Ingham via lldb-dev 
>> <lldb-dev@lists.llvm.org> wrote:
>> 
>> Why are we remapping the FileSpecs in SymbolContext's we are handing out?  
>> That seems to me a bad idea.  It means that every time I want to do a 
>> FileSpec compare between the LineEntry FileSpec's that I get at from stack 
>> frames at two different times, I have to remember to re-apply the SourceMap 
>> to the file spec I've stored away before doing the compare.  After all, the 
>> user might have changed the source map and thus the file spec we are handing 
>> out.  That seems very error prone.  And we can't handle that in the FileSpec 
>> "==" operator because FileSpec's don't have Targets, so they have no way of 
>> getting to the map.  
>> 
>> Wouldn't it be better to use the source maps when we print filenames and 
>> look for actual source files, and leave the symbol context FileSpec's in 
>> some canonical form we know won't change over time?
>> 
>> Jim
>> 
>> 
>>> On May 6, 2016, at 3:05 PM, Ted Woodward <ted.woodw...@codeaurora.org> 
>>> wrote:
>>> 
>>> Symbols are being remapped. StackFrame::GetSymbolContext does this:
>>> 
>>>  m_sc.line_entry = sc.line_entry;
>>>  if (m_sc.target_sp)
>>>  {
>>>  // Be sure to apply and file remappings to our file 
>>> and line
>>>  // entries when handing out a line entry
>>>  FileSpec new_file_spec;
>>>  if (m_sc.target_sp->GetSourcePathMap().FindFile 
>>> (m_sc.line_entry.file, new_file_spec))
>>>  m_sc.line_entry.file = new_file_spec;
>>>  }
>>> 
>>> This code gets called if the StackFrame ctor is called with the 
>>> SymbolContext = nullptr, but this is skipped if the SymbolContext is valid. 
>>> All new StackFrames in StackFrameList are done with a null SC, except for 
>>> an inlined frame. In that case, StackFrameList::GetFramesUpTo calls 
>>> SymbolContext::GetParentOfInlinedScope, which sets the SC, and 
>>> GetFramesUpTo does not remap it li

Re: [lldb-dev] Listing memory regions in lldb

[Jim Ingham via lldb-dev]

Oh, that's a cute trick, but it relies on the not (at-least-to-me) obvious fact 
that an address in an unmapped region will return the extents of the unmapped 
region.  For it to be useful, that needs to be a requirement of the API's 
implementation.

It seems to me it would be much clearer to have an API that returns the memory 
regions for you.

Jim



> On May 12, 2016, at 11:09 AM, Greg Clayton via lldb-dev 
>  wrote:
> 
> We have a way internally with:
> 
>virtual Error
>lldb_private::Process::GetMemoryRegionInfo (lldb::addr_t load_addr, 
> MemoryRegionInfo _info);
> 
> This isn't expose via the public API in lldb::SBProcess. If you want, you can 
> expose this. We would need to expose a SBMemoryRegionInfo and the call could 
> be:
> 
> namespace lldb
> {
>class SBProcess
>{
>SBError GetMemoryRegionInfo (lldb::addr_t load_addr, 
> SBMemoryRegionInfo _info);
>};
> }
> 
> then you would call this API with address zero and it would return a 
> SBMemoryRegionInfo with an address range and if that memory is 
> read/write/execute. On MacOSX we always have a page zero at address 0 for 64 
> bit apps so it would respond with:
> 
> [0x0 - 0x1) read=false, write=false, execute=false
> 
> Then you call the function again with the end address of the previous range. 
> 
> I would love to see this functionality exported through our public API. Let 
> me know if you are up for making a patch. If you are, you might want to 
> quickly read the following web page to see the rules that we apply to 
> anything going into our public API:
> 
> http://lldb.llvm.org/SB-api-coding-rules.html
> 
> 
> Greg
> 
>> On May 12, 2016, at 6:20 AM, Howard Hellyer via lldb-dev 
>>  wrote:
>> 
>> I'm working on a plugin for lldb and need to scan the memory of a crashed 
>> process. Using the API to read chunks of memory and scan (via 
>> SBProcess::Read*) for what I'm looking for is easy but I haven't been able 
>> to find a way to find which address ranges are accessible. The 
>> SBProcess::Read* calls will return an error on an invalid address but it's 
>> not an efficient way to scan a 64 bit address space. 
>> 
>> This seems like it blocks simple tasks like scanning memory for blocks 
>> allocated with a header and footer to track down memory leaks, which is 
>> crude but traditional, and ought to be pretty quick to script via the Python 
>> API. 
>> 
>> At the moment I've resorted to running a python script prior to launching my 
>> plugin that takes the output of "readelf --segments", /proc//maps or 
>> "otool -l" but this isn't ideal. On the assumption that I'm not missing 
>> something huge I've looked at whether it is possible to extend LLDB to 
>> provide this functionality and it seems possible, there are checks 
>> protecting calls to read memory that use the data that would need to be 
>> exposed. I'm working on a prototype implementation which I'd like to deliver 
>> back at some stage but before I go too far does this sound like a good idea? 
>> Howard Hellyer
>> IBM Runtime Technologies, IBM Systems
>> 
>> 
>> ___
>> 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] Listing memory regions in lldb

[Jim Ingham via lldb-dev]

You should be able to enumerate the memory that is occupied by loaded 
executables, by getting the list of loaded Modules from the target, and iterate 
through the all the Sections.  The Sections know their loaded locations.  I 
assume all the mapped ones will return a valid load address from 
GetLoadBaseAddress, so you can distinguish the loaded and unloaded ones.  So 
you shouldn't need "readelf --segments" or "otool -l", lldb should know this.

You can scan the currently active stacks, but we don't currently know the 
allocated stack extents, just what is being used.  It would be interesting to 
know the actual stack extents, so you could search in old stacks and to know if 
you are close to exhausting the stack of a thread.

We don't have either a generic API, or internal implementations, for getting 
all the mapped memory regions (or shared pages) of processes.  That would be 
quite useful.  IIRC ptr_refs does this by injecting some code into the target 
program that enumerates the regions.  Greg would know more about this.  Most 
systems provide some API to get at this that works cross-process, but that 
doesn't help debugging remotely.  So we either need to teach debugserver & 
lldb-server to do this, or use appropriate code injection.  The gdb-remote 
protocol has a query for the "memory map" of the process, though this is more 
tailored to identify things like memory mapped registers.  Still it might be 
possible to use this as well.

It would be nice to be able to separately query heap, executable & stack memory 
as well.  Though a properly annotated memory map would give you a way to do 
this, so that could be layered on top.

Jim

> On May 12, 2016, at 6:20 AM, Howard Hellyer via lldb-dev 
>  wrote:
> 
> I'm working on a plugin for lldb and need to scan the memory of a crashed 
> process. Using the API to read chunks of memory and scan (via 
> SBProcess::Read*) for what I'm looking for is easy but I haven't been able to 
> find a way to find which address ranges are accessible. The SBProcess::Read* 
> calls will return an error on an invalid address but it's not an efficient 
> way to scan a 64 bit address space. 
> 
> This seems like it blocks simple tasks like scanning memory for blocks 
> allocated with a header and footer to track down memory leaks, which is crude 
> but traditional, and ought to be pretty quick to script via the Python API. 
> 
> At the moment I've resorted to running a python script prior to launching my 
> plugin that takes the output of "readelf --segments", /proc//maps or 
> "otool -l" but this isn't ideal. On the assumption that I'm not missing 
> something huge I've looked at whether it is possible to extend LLDB to 
> provide this functionality and it seems possible, there are checks protecting 
> calls to read memory that use the data that would need to be exposed. I'm 
> working on a prototype implementation which I'd like to deliver back at some 
> stage but before I go too far does this sound like a good idea? 
> Howard Hellyer
> IBM Runtime Technologies, IBM Systems 
> 
> 
> ___
> 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] Listing memory regions in lldb

[Jim Ingham via lldb-dev]

> On May 13, 2016, at 9:13 AM, Zachary Turner <ztur...@google.com> wrote:
> 
> On Intel processors, the best way to do this is probably going to be to walk 
> the page directory (see Intel processor manuals).  Assuming someone 
> implements this command in lldb, I hope it can be done in such a way as to 
> allow different implementations when one os/architecture has a better way of 
> doing it.

This would fall out naturally if the gathering of the data is done in 
debugserver/lldb-server, which seems to me the natural place for this work to 
be done.

Jim


> 
> On Thu, May 12, 2016 at 11:09 AM Jim Ingham via lldb-dev 
> <lldb-dev@lists.llvm.org> wrote:
> You should be able to enumerate the memory that is occupied by loaded 
> executables, by getting the list of loaded Modules from the target, and 
> iterate through the all the Sections.  The Sections know their loaded 
> locations.  I assume all the mapped ones will return a valid load address 
> from GetLoadBaseAddress, so you can distinguish the loaded and unloaded ones. 
>  So you shouldn't need "readelf --segments" or "otool -l", lldb should know 
> this.
> 
> You can scan the currently active stacks, but we don't currently know the 
> allocated stack extents, just what is being used.  It would be interesting to 
> know the actual stack extents, so you could search in old stacks and to know 
> if you are close to exhausting the stack of a thread.
> 
> We don't have either a generic API, or internal implementations, for getting 
> all the mapped memory regions (or shared pages) of processes.  That would be 
> quite useful.  IIRC ptr_refs does this by injecting some code into the target 
> program that enumerates the regions.  Greg would know more about this.  Most 
> systems provide some API to get at this that works cross-process, but that 
> doesn't help debugging remotely.  So we either need to teach debugserver & 
> lldb-server to do this, or use appropriate code injection.  The gdb-remote 
> protocol has a query for the "memory map" of the process, though this is more 
> tailored to identify things like memory mapped registers.  Still it might be 
> possible to use this as well.
> 
> It would be nice to be able to separately query heap, executable & stack 
> memory as well.  Though a properly annotated memory map would give you a way 
> to do this, so that could be layered on top.
> 
> Jim
> 
> > On May 12, 2016, at 6:20 AM, Howard Hellyer via lldb-dev 
> > <lldb-dev@lists.llvm.org> wrote:
> >
> > I'm working on a plugin for lldb and need to scan the memory of a crashed 
> > process. Using the API to read chunks of memory and scan (via 
> > SBProcess::Read*) for what I'm looking for is easy but I haven't been able 
> > to find a way to find which address ranges are accessible. The 
> > SBProcess::Read* calls will return an error on an invalid address but it's 
> > not an efficient way to scan a 64 bit address space.
> >
> > This seems like it blocks simple tasks like scanning memory for blocks 
> > allocated with a header and footer to track down memory leaks, which is 
> > crude but traditional, and ought to be pretty quick to script via the 
> > Python API.
> >
> > At the moment I've resorted to running a python script prior to launching 
> > my plugin that takes the output of "readelf --segments", /proc//maps 
> > or "otool -l" but this isn't ideal. On the assumption that I'm not missing 
> > something huge I've looked at whether it is possible to extend LLDB to 
> > provide this functionality and it seems possible, there are checks 
> > protecting calls to read memory that use the data that would need to be 
> > exposed. I'm working on a prototype implementation which I'd like to 
> > deliver back at some stage but before I go too far does this sound like a 
> > good idea?
> > Howard Hellyer
> > IBM Runtime Technologies, IBM Systems
> >
> >
> > ___
> > 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] Push work-in-progress plugin for Process NetBSD?

[Jim Ingham via lldb-dev]

Provided it builds everywhere and you are planning on continuing to work on it, 
I see no problems with putting this into the lldb tree. If there are any parts 
that touch common code, you might want to submit those first (in appropriate 
chunks) so that the people who are going to review it can see the parts that 
touch their areas more clearly, then add in the independent code when the 
groundwork is settled.

Jim

> On May 12, 2016, at 6:28 PM, Zachary Turner via lldb-dev 
>  wrote:
> 
> I think it's fine, but I'll let others comment on that too.
> 
> But i will say, if you do this, please make sure it's clang-formatted.
> On Thu, May 12, 2016 at 6:23 PM Kamil Rytarowski via lldb-dev 
>  wrote:
> I keep locally almost 5k lines of code of the process plugin for NetBSD.
> 
> It's still not functional (there are bugs), but it has all or mostly all
> of the code needed for amd64. Is it fine to push it upstream and
> continue development against the version in-tree?
> 
> My code is based on FreeBSD with removed unsupported features, missing
> in the current version of NetBSD.
> 
> It will be easier for me to keep it in sync with HEAD and should be
> usable for other teams to take it into account in further changes.
> 
> 
> ___
> 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] Bug with ThreadPlanStepRange::InRange, symbol context and target.source-map setting

[Jim Ingham via lldb-dev]

> On May 6, 2016, at 11:22 AM, Ted Woodward via lldb-dev 
>  wrote:
> 
> I’m stepping over the first line of a libcxx test (source 
> https://llvm.org/svn/llvm-project/libcxx/trunk/test/std/thread/thread.condition/thread.condition.condvar/wait.pass.cpp
>  ). The first line has an inlined function call. I expect lldb to step over 
> the breakpoint, run to the end of the range that sets up the inlined function 
> call, run through the inlined function call, then run to the end of the line. 
> Instead, it runs to the inlined call, then stops.
>  
> I’m running lldb on Windows, debugging a Hexagon application that was built 
> on Linux. I’m using the target.source-map setting to let me see source.
>  
> The problem is in ThreadPlanStepRange::InRange. It checks to see if we’re 
> still on the same line by comparing the filename in the Stepping Plan’s line 
> entry to the filename in the current frame’s line entry. 
> m_addr_context.line_entry.file has been normalized by the value in 
> target.source-map, but new_context.line_entry.file hasn’t, so they’re not the 
> same, even though they should be.
>  
> SymbolContext 
> new_context(frame->GetSymbolContext(eSymbolContextEverything));
> if (m_addr_context.line_entry.IsValid() && 
> new_context.line_entry.IsValid())
> {
> if (m_addr_context.line_entry.file == new_context.line_entry.file)
> {
>  
>  
> Either both should use target.source-map, or neither should.  How do I run 
> new_context.line_entry.file through the target.source-map normalization?



It doesn't seem right to me that when symbols are handed out they have the 
source map applied to their file spec's.  After all, then you could get into 
problems like: somebody started a step so we recorded m_addr_context.  Then 
their step was interrupted (say by hitting a breakpoint) and the user added a 
source mapping.  Then we stop in a frame from the same module, and now the 
SymbolContext that the step plan stored (m_addr_context) has a different path 
than the one in the frame when we get to it.  Checking every time you compared 
file specs seems very error prone, we shouldn't do it that way.  I guess if the 
FileSpec == handled this it would be odd but not too bad.  But that seems like 
it would result in a lot of unnecessary work.  I think it would be better to 
only do source map path conversion when sources are looked up, and maybe when 
paths are printed.  For symbols we should stick to what the debug info says.

Jim


>  
> Ted
>  
> --
> Qualcomm Innovation Center, Inc.
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a 
> Linux Foundation Collaborative Project
>  
> ___
> 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] Bug with ThreadPlanStepRange::InRange, symbol context and target.source-map setting

[Jim Ingham via lldb-dev]

Why are we remapping the FileSpecs in SymbolContext's we are handing out?  That 
seems to me a bad idea.  It means that every time I want to do a FileSpec 
compare between the LineEntry FileSpec's that I get at from stack frames at two 
different times, I have to remember to re-apply the SourceMap to the file spec 
I've stored away before doing the compare.  After all, the user might have 
changed the source map and thus the file spec we are handing out.  That seems 
very error prone.  And we can't handle that in the FileSpec "==" operator 
because FileSpec's don't have Targets, so they have no way of getting to the 
map.  

Wouldn't it be better to use the source maps when we print filenames and look 
for actual source files, and leave the symbol context FileSpec's in some 
canonical form we know won't change over time?

Jim


> On May 6, 2016, at 3:05 PM, Ted Woodward  wrote:
> 
> Symbols are being remapped. StackFrame::GetSymbolContext does this:
> 
>m_sc.line_entry = sc.line_entry;
>if (m_sc.target_sp)
>{
>// Be sure to apply and file remappings to our file 
> and line
>// entries when handing out a line entry
>FileSpec new_file_spec;
>if (m_sc.target_sp->GetSourcePathMap().FindFile 
> (m_sc.line_entry.file, new_file_spec))
>m_sc.line_entry.file = new_file_spec;
>}
> 
> This code gets called if the StackFrame ctor is called with the SymbolContext 
> = nullptr, but this is skipped if the SymbolContext is valid. All new 
> StackFrames in StackFrameList are done with a null SC, except for an inlined 
> frame. In that case, StackFrameList::GetFramesUpTo calls 
> SymbolContext::GetParentOfInlinedScope, which sets the SC, and GetFramesUpTo 
> does not remap it like StackFrame::GetSymbolContext does. Then it creates a 
> new StackFrame with the SC.
> 
> Adding this before the new StackFrame fixes the issue:
>if (target_sp)
>{
>// Be sure to apply and file remappings to our file 
> and line
>// entries when handing out a line entry
>FileSpec new_file_spec;
>if 
> (target_sp->GetSourcePathMap().FindFile(next_frame_sc.line_entry.file, 
> new_file_spec))
>next_frame_sc.line_entry.file = new_file_spec;
>}
> 
> I've put up a patch on Phabricator with Jim as reviewer.
> 
> --
> Qualcomm Innovation Center, Inc.
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a 
> Linux Foundation Collaborative Project
> 
> 
> -Original Message-
> From: jing...@apple.com [mailto:jing...@apple.com] 
> Sent: Friday, May 06, 2016 2:41 PM
> To: Ted Woodward 
> Cc: LLDB 
> Subject: Re: [lldb-dev] Bug with ThreadPlanStepRange::InRange, symbol context 
> and target.source-map setting
> 
> 
>> On May 6, 2016, at 11:22 AM, Ted Woodward via lldb-dev 
>>  wrote:
>> 
>> I’m stepping over the first line of a libcxx test (source 
>> https://llvm.org/svn/llvm-project/libcxx/trunk/test/std/thread/thread.condition/thread.condition.condvar/wait.pass.cpp
>>  ). The first line has an inlined function call. I expect lldb to step over 
>> the breakpoint, run to the end of the range that sets up the inlined 
>> function call, run through the inlined function call, then run to the end of 
>> the line. Instead, it runs to the inlined call, then stops.
>> 
>> I’m running lldb on Windows, debugging a Hexagon application that was built 
>> on Linux. I’m using the target.source-map setting to let me see source.
>> 
>> The problem is in ThreadPlanStepRange::InRange. It checks to see if we’re 
>> still on the same line by comparing the filename in the Stepping Plan’s line 
>> entry to the filename in the current frame’s line entry. 
>> m_addr_context.line_entry.file has been normalized by the value in 
>> target.source-map, but new_context.line_entry.file hasn’t, so they’re not 
>> the same, even though they should be.
>> 
>>SymbolContext 
>> new_context(frame->GetSymbolContext(eSymbolContextEverything));
>>if (m_addr_context.line_entry.IsValid() && 
>> new_context.line_entry.IsValid())
>>{
>>if (m_addr_context.line_entry.file == new_context.line_entry.file)
>>{
>> 
>> 
>> Either both should use target.source-map, or neither should.  How do I run 
>> new_context.line_entry.file through the target.source-map normalization?
> 
> 
> 
> It doesn't seem right to me that when symbols are handed out they have the 
> source map applied to their file spec's.  After all, then you could get into 
> problems like: somebody started a step so we recorded m_addr_context.  Then 
> their step was interrupted (say 

Re: [lldb-dev] LLDB Evolution

[Jim Ingham via lldb-dev]

> On Aug 12, 2016, at 5:23 AM, Pavel Labath via lldb-dev 
>  wrote:
> 
> On 12 August 2016 at 00:54, Chris Lattner via lldb-dev
>  wrote:
>> I recommend approaching this in three steps:
>> 
>> 1) get the less-controversial changes done that Greg was outlining.
>> 2) start a discussion in the llvm community about the concept of a
>> member/global prefix.
>> 2a) the community could agree that llvm-as-a-whole should move to prefixes
>> or otherwise change the camel case policy.
>> 2b) the community could agree that the existing policies are preferred
>> 3) LLDB moves to whatever is the end result of the discussion.
>> 
>> I guess what I’m saying is that since the opinions about this are very
>> strong, and because we haven’t really had that debate in the LLVM community,
>> that it would be bad to proactively move to the LLVM style, simply to have
>> to move back later.  Iff the (sure to be extensive) community discussion
>> settles on the idea that prefixes are the wrong thing, then LLDB should
>> remove them to be consistent.
>> 
>> -Chris
> 
> +1
> 
> 
> 
> In terms of the formatting of tests, I did some more research on this.
> I think the changes needed to be made to the test suite are generally
> trivial to fix (e.g. r278490), but I don't think we can avoid a manual
> intervention. CommentPragmas does not seem to be a silver bullet -- it
> does prevent clang-format from breaking the comment, but it does not
> prevent it from moving the whole comment to a new line. That said,
> when I reformatted the test sources with CommentPragmas set, the
> number of failures went down to 80 (from about 150)...
> 
> I believe we should still perform the reformatting of the tests, at
> least to standardize on the 2 space indent (in fact we should consider
> doing the same for the python code as well, I don't know what's the
> situation there in llvm land), but it can be done later. It will make
> the period while the code is in flux longer, but hopefully not too
> long. Also the modifications will be independent of the main reformat,
> so it will still be true that a single source file only got
> reformatted once.
> 

My eyes put in a vote for not reformatting the Python to 2 space tabs. In C++, 
most IDE's do smart things with double-clicking on { to find the closing ones 
easing the task that two space indents makes somewhat harder.  But since the 
spacing is the only nesting indicator in Python, it would be nice to keep that 
more visually apparent.

> pl
> ___
> 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] Trying to understand how Expression Evaluation works

[Jim Ingham via lldb-dev]

> On Jul 20, 2016, at 4:32 PM, Khaled Mohammed via lldb-dev 
>  wrote:
> 
> Hi,
> 
> Is there a document which describes in detail how the expression evaluation 
> works? is there a wiki for lldb developers?
> 

There is no documentation beyond the code & its comments describing how this is 
done, but you can get a fair bit of insight if you turn on the expression log:

(lldb) log enable -f /tmp/lldb-expr-log.txt lldb expr

then run an expression and go read through the log.  It's pretty voluminous, 
but fairly clear, and there are generally Headers in the log text that can be 
found directly in the "log->Printf" calls in the sources, so you can trace 
where in the code each bit of work happens by searching for them.

> Few questions...
> 1) Does it use clang to parse the expression text directly? or is the 
> expression text morphed into a function before passing to clang?

The latter.  The expression log will show the transformed text fairly early on 
in the log in the log.  The function is different depending on the context 
we're trying to emulate (C++ or ObjC method, for instance.)  Sean recently 
added the ability to parse "top-level code" (with "expr --top-level --")  in 
which case the code doesn't get wrapped.

> 2) Is the evaluation done in target or in the host?

If it can be IR interpreted (pretty much if there are no function calls) it is 
interpreted in the host, but side effects will be propagated to the target.

If it can't be IR interpreted, it will be JIT'ed and run in the target.  We 
don't have a hybrid mode like gdb where we interpret the results of the parse, 
but stop along the way to dispatch any function calls by hand to the target.  
Doing it that way forces gdb to know all the ABI details.  The lldb wrapper 
function is simple (taking one pointer, and returns nothing.)  So that's the 
only bit of the ABI we have to get right for expression evaluations to work.  
clang, which has to get this right anyway, takes care of the rest.

LLDB does have another way to run code: "UtilityFunction" which takes more than 
one argument, and calls an extant function in the target directly.  That part 
doesn't use clang, and really only supports passing it a few scalars, and 
returning a scalar.

> 3) Is the code generation done in host or target? if code generation is done 
> in the host, how is binary passed to the target to execute?

Code generation is done on the host using a version of the clang library built 
into lldb.

The JIT'ed code is written directly into memory lldb allocates in the target, 
and executed from there.  The LLVM JIT can be told the addresses of the 
sections as they will be in the target, so it can fix up any internal 
references for the target location.  You can also see this stage happen in the 
log.

Hope this helps,

Jim


> 
> Thanks,
> -Khaled
> ___
> 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] No event generated after a SBThread::JumpToLine() call

[Jim Ingham via lldb-dev]

JumpToLine just resets the PC, it doesn't continue the process.  For an API, it 
makes more sense to let the API user decide whether they want to do more work 
before continuing.  So you wouldn't expect a "running" event.

We could send a PC-changed event, but we generally only send that sort of event 
to help a GUI keep sync'ed with changes the CLI does (like the 
eBroadcastBitSelectedFrameChanged event, etc.)  So you wouldn't expect to see 
that event from the API.

Jim

> On Jul 18, 2016, at 5:51 AM, Marius Trandafir via lldb-dev 
>  wrote:
> 
> Hello everyone,
>  
> After calling SBThread::JumpToLine(…) I was expecting that the thread would 
> broadcast an event but it seems that this doesn’t happen.
> Is this the intended behavior? Does the call to JumpToLine comes in pair with 
> another function call?
>  
> Regards,
> Marius
>  
>  
>  
> Marius Trandafir
>  
> Staff Software Engineer
> National Instruments Romania
>  
> +40 0761 68 65 27
>  
>  
> National Instruments Romania S.R.L.
> --
> B-dul 21 Decembrie 1989, nr. 77, A2
> Cluj-Napoca 400604, Romania
> C.I.F.: RO17961616 | O.R.C.: J12/3337/2005
> Telefon: +40 264 406428 | Fax: +40 264 406429
> E-mail: office.c...@ni.com 
> Web: romania.ni.com 
> 
> Vanzari si suport tehnic:
> Telefon gratuit : 0800 070071
> E-mail vanzari: ni.roma...@ni.com
> E-mail suport tehnic: techsupp...@ni.com 
> ___
> 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] Question about -break-insert in lldb-mi

[Jim Ingham via lldb-dev]

That is my understanding of what the -f flag is supposed to do.  It doesn't 
take an argument, it just directs gdb to do "future-break" rather than "break". 
 The lldb MI should probably just parse & discard it.

Jim


> On Jul 11, 2016, at 1:59 PM, Pierson Lee (PIE)  
> wrote:
> 
> So the instance I run into the error is setting a conditional breakpoint:
> 
> -break-insert -f -c "x==0" main.cpp:13
> 
> And I get: 
> 
> MI: Error: Command Args. Validation failed. Args missing additional 
> information: f
> ^error,msg="Command 'break-insert'. Command Args. Validation failed. Args 
> missing additional information: f"
> 
> It seems in the tests/examples, -f is the last parameter and the 
> function/code location happens after the -f. 
> 
> From my understanding of the MI Command, the -f is a flag that tells it the 
> breakpoint is to be set as pending if the debugger cannot determine the 
> location of the breakpoint. The optional "parameter" doesn't seem to be used. 
> 
> Does this seem like a bug or am I misunderstanding what the -f flag does on 
> -break-insert ?
> 
> Thanks
> Pierson 
> 
> -Original Message-
> From: Ted Woodward [mailto:ted.woodw...@codeaurora.org] 
> Sent: Monday, July 11, 2016 1:13 PM
> To: Pierson Lee (PIE) ; jing...@apple.com; 'LLDB' 
> 
> Subject: RE: [lldb-dev] Question about -break-insert in lldb-mi
> 
> This is what Eclipse does when setting a breakpoint at main on a Hexagon 
> target, before -exec-run:
> 
> TX:21-break-insert -t -f main
> 
> --
> Qualcomm Innovation Center, Inc.
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a 
> Linux Foundation Collaborative Project
> 
> 
> -Original Message-
> From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Pierson 
> Lee (PIE) via lldb-dev
> Sent: Monday, July 11, 2016 1:33 PM
> To: jing...@apple.com
> Cc: lldb-dev@lists.llvm.org
> Subject: Re: [lldb-dev] Question about -break-insert in lldb-mi
> 
> If I don't specify the -f flag (with some random parameter), then a pending 
> breakpoint is not created and the initial binding fails. But if I specify the 
> -f with the random parameter, then it will bind when the library is loaded. 
> This is the behavior I see on gdb also, but sans the random parameter. I 
> looked at the source code and can't figure out what it expects the parameter 
> to be and what it does with the value. 
> 
> -Original Message-
> From: jing...@apple.com [mailto:jing...@apple.com] 
> Sent: Friday, July 8, 2016 7:03 PM
> To: Pierson Lee (PIE) 
> Cc: lldb-dev@lists.llvm.org
> Subject: Re: [lldb-dev] Question about -break-insert in lldb-mi
> 
> 
> gdb used to try to find a symbol matching the breakpoint specification and if 
> it didn't find one immediately, it would raise an error.  If you didn't want 
> this behavior (in a world with many shared libraries you seldom did) then you 
> could set a "future-break" which is what the -f flag turns on.  This was 
> better though a bit bogus, because it would set the breakpoint the FIRST time 
> it took, then never look again.
> 
> But this was quite a while ago, and I think gdb's gotten better about 
> organizing breakpoints.  But I haven't used a modern gdb for a while, so I'm 
> not sure how it works now-a-days.
> 
> Anyway, lldb's breakpoints don't work that way.  They stay active till you 
> delete them, and keep searching for new matches every time a shared library 
> is loaded.  You could make them emulate the gdb behavior by judiciously 
> deleting & duplicating breakpoints from the original specification, but 
> there's no way to get the native lldb breakpoints to do so (nor should there 
> be IMHO...)
> 
> So if you are using the lldb-mi, there's no reason to bother with the -f 
> flag.  But also lldb-mi should probably just ignore this flag.
> 
> Jim
> 
> 
>> On Jul 8, 2016, at 5:58 PM, Pierson Lee (PIE) via lldb-dev 
>>  wrote:
>> 
>> Hi,
>> 
>> I’m trying to use -break-insert and the -f flag for it. 
>> 
>> I noticed in MICmdCmdBreak.cpp , in CmICmdCmdBreakInsert::ParseArgs() that 
>> the -f has a required parameter.
>> 
>>m_setCmdArgs.Add(new 
>> CMICmdArgValOptionShort(m_constStrArgNamedPendinfBrkPt, false, true,
>>   
>> CMICmdArgValListBase::eArgValType_StringQuotedNumberPath, 1));
>> 
>> 
>> Based on the GDB MI documentation (at 
>> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fsourceware.org%2fgdb%2fonlinedocs%2fgdb%2fGDB_002fMI-Breakpoint-Commands.html%23GDB_002fMI-Breakpoint-Commands=01%7c01%7cPierson.Lee%40microsoft.com%7c2f7fe625424341c8101908d3a79d5c33%7c72f988bf86f141af91ab2d7cd011db47%7c1=vA0kav9epp3zRa4QivQ9wmimjEHYiJ0AiQfJcGKdzEs%3d)
>>  for -break-insert shows:
>> 
>> ‘-f’
>> If location cannot be parsed (for example if it refers to unknown files or 
>> functions), create a pending 

Re: [lldb-dev] Debugging Python scripts (backtraces, variables) with LLDB

[Jim Ingham via lldb-dev]

Nothing of this sort has been done to my knowledge, and I haven't heard of any 
plans to do so either.

It should certainly be possible, you just need to grub the C stack and 
recognize the pattern of a Python stack frame in it and where said frame 
stashes away the arguments & locals, and then re-present it as a Python frame.  
The SB API's should make that fairly straight forward.

It looks like the Python work in gdb is based on a generic "frame filter" 
concept in the gdb Python API's.  That's something Greg and I talked about when 
working on gdb way back, and has been a future goal for lldb from the start, 
but it hasn't ever gotten beyond discussion to date.  We already have the 
notion of a "thread provider" which allows the Mach Kernel plugin to present 
its activations as threads in lldb.  You could do much the same thing in lldb, 
where a thread would have the native unwind based stack frame and then 
pluggable StackFrame provider that would show different representations of the 
stack.

If anybody is interested in taking on such a project, that would be very cool.

Jim

> On Jul 6, 2016, at 8:48 AM, Alexandru Croitor via lldb-dev 
>  wrote:
> 
> Hello,
> 
> I've searched for information wether it is possible to debug a python script 
> using LLDB, and haven't found anything so far.
> 
> Specifically I'm interested in an LLDB counterpart to what GDB provides (the 
> two main pages being https://wiki.python.org/moin/DebuggingWithGdb and 
> http://fedoraproject.org/wiki/Features/EasierPythonDebugging ).
> 
> So python stack traces, python values, etc.
> 
> I assume this is not implemented, but are there any plans, or is it even 
> feasible to implement?
> 
> Regards, Alex.
> ___
> 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] Inquiry about Error codes sent by lldb-server

[Jim Ingham via lldb-dev]

Note this isn't something we made up...  In the gdb remote protocol spec, it 
says:

The error response returned for some packets includes a two character error 
number. That number is not well defined.

I think they are just meant to be useful for debugging a particular gdb-remote 
protocol server.  For instance, in lldb some of the packet response handlers 
that emit various error numbers, which will help you trace the error back to 
its source.  But in the specification of the protocol, they seldom have any 
particular meaning.  

Jim


> On Jun 30, 2016, at 9:47 AM, Greg Clayton via lldb-dev 
>  wrote:
> 
> 
>> On Jun 30, 2016, at 5:28 AM, Ravitheja Addepally via lldb-dev 
>>  wrote:
>> 
>> Hello,
>>  The lldb-server sends hard coded values like 0x78 etc in case of error, 
>> so does the ProcessGDBRemote use these numbers anyway except for just 
>> detecting error ? ( in my understanding it doesn't seem to use the value of 
>> the number please correct me if i am wrong ). Is there some special meaning 
>> to these numbers ? 
> 
> None what so ever. They are just random number that tell you nothing.
> 
>> 
>> Regards,
>> A Ravi Theja
>> ___
>> 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] Calling multiply defined symbols

[Jim Ingham via lldb-dev]

We have a not-yet-implemented scheme to allow some syntax like:

(lldb) expr $$foo.c$bar(5)

that would mean: look up the version of bar defined in foo.c and call that.  
What I wrote above isn't right, since the "." is going to cause the parser 
headaches, so we'll have to come up with some cleverer way to encode file-names 
that won't be absolutely horrible to type.  That would allow you to by hand 
disambiguate this sort of name collision.  This would also useful for accessing 
static variables in files & functions.

The expression parser does have some precedence order to deal with multiple 
symbols of the same name.  For instance, if there is one version in the dylib 
containing the current source file and others out in the world, we will pick 
the one in the containing dylib.  If the function is actually implemented in 
the compilation unit that holds the current frame, we should know to use that 
one and not the others.  We'd have to have debug info to be able to determine 
this. If that's not working, then that shouldn't be hard to fix.But if 
there are just a bunch of implementations in the same dylib but not in the 
current compilation unit, there's no reasonable distance metric to use to 
determine precedence.

Jim

> On Jun 29, 2016, at 4:57 AM, Aidan via lldb-dev  
> wrote:
> 
> Hi all,
> 
> We have a process that contains multiple definitions of the same function.  
> The function in question is declared 'static extern' in a header and included 
> in multiple compilation units.
> This causes some confusion for lldb expression parser when trying to invoke 
> the function by name, since it doesn't know which of the multiple (identical) 
> implementations to call.  In this case the expression evaluation fails and 
> informs the user 'call to 'abs' is ambiguous' in my case.
> 
> The function in question could be changed to resolve the error, but I'd be 
> interested to know if there is a way to resolve such an ambiguity from the 
> LLDB's CLI.
> Alternatively, should there be an precedence order that LLDB could be made to 
> obey in the case of this ambiguity?
> 
> Thanks,
> Aidan
> ___
> 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] Breakpoint + callback performance ... Can it be faster?

[Jim Ingham via lldb-dev]

Are you sure the actual handling of the breakpoint & callback in lldb is what 
is taking most of the time?  The last time we looked at this, the majority of 
the work was in communicating with debugserver to get the stop notification and 
restart.  Note, besides all the packet code, this involves context switches 
from process->lldbserver->lldb and back, which is also pretty expensive.  

Greg just switched to using a unix-domain socket for this communication for 
platforms that support it.  This speeds up the packet traffic side of things.  

One of the original motivations of having lldb-server be based on lldb classes 
- as opposed to the MacOS X version of debugserver which is an independent 
construct - was that you could re-use the server code to create an in-process 
Process plugin, eliminating a lot of this traffic & context switching when you 
needed maximum speed.  The original Mac OS X lldb port actually had a process 
plugin wholly in-process with lldb as well as the debugserver based one, but 
there wasn't enough motivation to justify maintaining the two different 
implementations of the same code.  I don't know whether the Linux port takes 
advantage of this possibility, however.  That would be something to look into, 
however.

Once we actually figure out about the stop, figuring out the breakpoint and 
getting to its callback is pretty simple...  I doubt making "lighter weight 
breakpoints" in particular will recover the performance you need, though if 
your sampling turns up some inefficient algorithms have crept in, it would be 
great to fix that.

Another option we've toyed with on and off is something like the gdb 
"tracepoints" were you can upload instructions to perform "experiments" when a 
breakpoint is hit to the lldb-server instance.  The work to perform the 
experiment and the results would all be kept in the lldb-server instance till a 
real breakpoint is hit, at which point lldb can download all the results and 
present them to the user.  This would eliminate some of the context-switches 
and packet traffic while you were running in the hot parts of your code.  This 
is a decent chunk of work, however.

Jim


> On Aug 16, 2016, at 9:57 AM, Benjamin Dicken via lldb-dev 
>  wrote:
> 
> I recently started using lldb to write a basic instrumentation tool for 
> tracking the values of variables at various code-points in a program. I've 
> been working with lldb for less than two weeks, so I am pretty new. Though, I 
> have used and written llvm passes in the past, so I'm familiar with the 
> clang/llvm/lldb ecosystem.
> 
> I have a very early prototype of the tool up and running, using the C++ API. 
> The user can specify either an executable to run or an already-running PID to 
> attach to. The user also supplies a file+line_number at which a breakpoint 
> (with a callback) is placed. For testing/prototyping purposes, the breakpoint 
> callback just increments a counter and then immediately returns false. 
> Eventually, more interesting things will happen in this callback.
> 
> I've noticed that just the action of hitting a breakpoint and invoking the 
> callback is very expensive. I did some instruction-count collection by 
> running this lldb tool on a simple test program, and placing the 
> breakpoint+callback at different points in the program, causing it to get 
> triggered different amounts of times. I used `perf stat -e instructions ...` 
> to gather instruction exec counts for each run. After doing a little math, it 
> appears that I'm incurring 1.0 - 1.1 million instruction execs per breakpoint.
> 
> This amount of slowdown is prohibitively expensive for my needs, because I 
> want to place callbacks in hot portions of the "inferior" program.
> 
> Is there a way to make this faster? Is it possible to create "lighter-weight" 
> breakpoints? I really like the lldb API (though the documentation is lacking 
> in some places), but if this performance hit can't be mitigated, it may be 
> unusable for me.
> 
> For reference, this is the callback function:
> 
> ``` 
> static int cb_count = 0;
> bool SimpleCallback (
> void *baton,  
> lldb::SBProcess ,
> lldb::SBThread ,
> lldb::SBBreakpointLocation ) {
>   //TODO: Eventually do more interesting things...
>   cb_count++; 
>   return false;
> }
> ```
> 
> And here is how I set it up to be called back:
> 
> ```
> lldb::SBBreakpoint bp1 = 
> debugger_data->target.BreakpointCreateByLocation(file_name, line_no);
> if (!bp1.IsValid()) std::cerr << "invalid breakpoint";
> bp1.SetCallback(SimpleCallback, 0);
> ```
> 
> -Benjamin
> ___
> 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] non-stop mode with lldb-mi?

[Jim Ingham via lldb-dev]

> On Feb 3, 2017, at 8:45 AM, Greg Clayton via lldb-dev 
>  wrote:
> 
> Non-stop mode is a huge change to the core of LLDB isn’t it. I think you 
> might think this is easier than it actually is to enable in LLDB? 
> 
> Is non-stop mode where you can leave some threads running while others are 
> stopped? The biggest issue with this is to do it right we need to be able to 
> emulate instructions so that if 3 threads hit breakpoints, we would need to 
> emulate the instruction that used to be at the breakpoint in LLDB since we 
> can’t remove the breakpoint (unless you stop the other threads which defeats 
> the purpose of non-stop mode) without the other 2 threads possibly missing 
> the breakpoint while you disable breakpoint, single step, enable breakpoint.

That is just one of the many things that will have to be changed to support 
non-stop mode.  For now, non-stop mode is only likely to work reliably if the 
threads you are allowing to run never stop - hit breakpoints, crash or whatever 
- so worrying about missing breakpoints is a second order problem.  

Anyway, even as it is it has some utility - presumably you're using it because 
you have some threads in your program that can't stop, so you're not likely to 
want them to hit breakpoints anyway...  But the current help text for the 
non-stop setting should probably include some appropriate caveats.

Jim


> 
> Greg
> 
>> On Feb 3, 2017, at 7:54 AM, Ted Woodward via lldb-dev 
>>  wrote:
>> 
>> That turns on and off async, but not non-stop.
>>  
>> I’m working on adding support for –gdb-set and –gdb-show non-stop, and will 
>> post my changes on phabricator when I’m done.
>>  
>> --
>> Qualcomm Innovation Center, Inc.
>> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a 
>> Linux Foundation Collaborative Project
>>  
>> From: Ilia K [mailto:ki.s...@gmail.com] 
>> Sent: Wednesday, February 01, 2017 11:13 PM
>> To: Ted Woodward 
>> Cc: LLDB 
>> Subject: Re: [lldb-dev] non-stop mode with lldb-mi?
>>  
>> Please check `-gdb-set target.async` option. Probably that's what you need.
>>  
>> On Thu, Feb 2, 2017 at 1:44 AM, Ted Woodward via lldb-dev 
>>  wrote:
>>> Does lldb-mi support non-stop mode?
>>>  
>>> If so, is there a way to set it besides “settings set target.non-stop-mode 
>>> true”?
>>>  
>>> --
>>> Qualcomm Innovation Center, Inc.
>>> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a 
>>> Linux Foundation Collaborative Project
>>>  
>>> 
>>> ___
>>> lldb-dev mailing list
>>> lldb-dev@lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>> 
>> 
>> 
>>  
>> -- 
>> - Ilia
>> ___
>> 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] Tab completion for variable names, etc.

[Jim Ingham via lldb-dev]

This is a long-standing missing feature in lldb.  We delegate to clang the 
parsing of expressions, so we're going to have to either create a separate 
parser for symbol completion or figure out how to get clang to parse up to the 
cursor and then tell us what it has parsed so far.  This would be a great 
project for somebody to take on, if anybody has some spare time on their hands!

Jim


> On Jan 23, 2017, at 4:09 PM, Andreas Yankopolus via lldb-dev 
>  wrote:
> 
> Does lldb support tab completion of variable or class/method names? If so, 
> how is it enabled? Command completion works just fine with lldb 3.9 on Ubuntu 
> 16.10 and with Apple’s version on MacOS Sierra. But if I define 
> "std::vector v;" in a C++ source file, break lldb after this 
> definition, and type “print v.” followed by hitting the tab key, nothing 
> happens. In gdb, this lists member functions such as “front”, “back”, etc.
> ___
> 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] Navigating STL types

[Jim Ingham via lldb-dev]

lldb has "synthetic child providers" for most of the STL collection types, so 
we do show all the child values, for instance my_vec is a std::vector and:

(lldb) expr my_vec
(std::__1::vector) $0 = size=10 {
  [0] = 0
  [1] = 1
  [2] = 2
  [3] = 3
  [4] = 4
  [5] = 5
  [6] = 6
  [7] = 7
  [8] = 8
  [9] = 9
}

Those values were printed by the std::vector data formatter.  To learn more 
about data formatters, see:

http://lldb.llvm.org/varformats.html

You can access individual members of the array using the "frame variable" 
command, which prints local variables & arguments it looks up by name in the 
debug info:

(lldb) frame variable my_vec[5]
(int) my_vec[5] = 5

You can't do that using the "print" command, because it will actually try to 
run this as an expression, which fails without the accessor functions.  

OTOH, the "frame variable" command doesn't run real expressions, it just looks 
up the variable by name and then accesses the synthetic children that the data 
formatter provides.  But for many things this works well enough to get you 
going.  You can combine "frame var" with the -L option and the expression 
parser if you need to pass a particular element to some function:

(lldb) frame variable -L my_vec[5]
0x0001002000e4: (int) my_vec[5] = 5
(lldb) expr printf("%d\n", *((int *) 0x0001002000e4))
5
(int) $1 = 2

That's not ideal, for sure, and it will be great when the STL leaves all these 
functions around for the debugger at -O0.  But you can usually get your hands 
on what you need this way...

BTW, another even more horrible trick when you are desperate is to put:

template class std::vector;

in your C++ sources somewhere (replace std::vector with the instantiation 
you need to print.)  That will cause clang to emit a full copy of the template 
instantiation in your binary, and then everything works as expected:

(lldb) expr my_vec.size()
(std::__1::vector::size_type) $0 = 10
(lldb) expr my_vec[5]
(std::__1::__vector_base::value_type) $1 = 5

etc.  Obviously, this isn't a great long-term solution, but if you can afford 
the time to rebuild it does get the job done.

Jim



> On Jan 23, 2017, at 4:13 PM, Andreas Yankopolus via lldb-dev 
>  wrote:
> 
> Mehdi,
> 
>> Yes, this is a problem with our STL, we are forcing inlining and we need to 
>> fix this on libc++ side, it is scheduled, but we haven’t come to it yet.
> 
> Any guesstimate as to the timeframe? Seems like being able to navigate STL 
> types would be a useful thing.
> 
> Thanks,
> 
> Andreas
> ___
> 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] Why SBValue::Cast is deprecated and how to replace it with expression?

[Jim Ingham via lldb-dev]

Cast is deprecated because it isn't a real C++ cast.  In particular if you cast 
a pointer to a base class to it's parent class, it doesn't do the work to 
offset the pointer to take into account the position of the base class in it's 
parent.  All it does is extract the address of the original value object and 
cast THAT to the new type.

For C & ObjC types, Cast is not going to cause any problems.  But for C++ it is 
not always correct.

Any of the "evaluate expression" calls with a proper cast expression should 
work, clang will get the offsetting right in the code it generates.  So for 
instance:

casted_value = frame.EvaluateExpression("(MyType *) var_to_cast");

SBFrame::EvaluateExpression will search for types & globally visible objects 
searching outward from the current scope.  So finding variables & types from 
other contexts should only be problem if there are multiple incompatible 
types/variables globally visible.  

To handle the possible ambiguities here, we need to add some syntax to the 
expression parser to indicate "this type/varname from this scope".  gdb did 
this with:

foo.dylib::varname 

which was unfortunate since it collides with C++ and can make entering C++ 
expressions awkward.

Our tentative plan is to use the "$$" to indicate "names with special sauce" 
since we're already using initial $ specially, and then do something like:

$$foo.dylib$varname

to mean the variable called varname in foo.dylib.

Jim

> On Jan 29, 2017, at 8:17 PM, Roman Popov via lldb-dev 
>  wrote:
> 
> Hello,
> 
> SBValue::Cast marked as deprecated in LLDB headers:
> 
> // Deprecated - use the expression evaluator to perform type casting
> 
> lldb
> ::SBValue Cast(lldb::SBType type);
> But I can't understand how to replace it with expression evaluation.
> 
> Suppose I have:
> 
> auto casted_val = my_value.Cast(my_type);
> What would be equivalent expression, taking into account that both value and 
> type can be out of current scope?
> 
> 
> 
> Same question on stackoverflow:
> 
> http://stackoverflow.com/questions/41928915/lldb-api-why-sbvaluecast-is-deprecated-and-how-to-replace-it-with-createvalue
> 
> 
> 
> Thanks in advance for help,
> 
> -Roman
> 
> ___
> 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 3.9 on Linux crashes when loading core dump

[Jim Ingham via lldb-dev]

If that works, can you add it to the lldb-gdb.html document?

Jim

> On Jan 20, 2017, at 3:57 PM, Ted Woodward via lldb-dev 
>  wrote:
> 
> Try “image search-paths add” as a replacement for “set solib-search-path”
>  
> --
> Qualcomm Innovation Center, Inc.
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a 
> Linux Foundation Collaborative Project
>  
> From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Eugene 
> Birukov via lldb-dev
> Sent: Friday, January 20, 2017 12:35 PM
> To: Pavel Labath 
> Cc: rd...@microsoft.com; LLDB 
> Subject: Re: [lldb-dev] LLDB 3.9 on Linux crashes when loading core dump
>  
> Hello Pavel,
>  
> Thanks for the reply. Unfortunately I cannot share the core dump with you.
>  
> Yes, Rob has figured that LLDB does not find this shared library and that 
> causes the problem. To understand what is going on here, I need to add one 
> more detail that was missing from my original post: this is a cross-machine 
> investigation. I.e. the core dump collected on one machine (CentOs) was sent 
> to another
> (Ubuntu) where I tried to open it.
>  
> LLDB opens the executable without paying attention that there is a core dump 
> attached and tries to locate shared libraries. Apparently the ones that exist 
> on my machine are not good, so it then looks in the directory with the 
> executable itself. There is no way to "set solib-search-path" as we do on GDB 
> and force it to look somewhere else. After we dumped all the shared libraries 
> in the folder with the executable LLDB was able to open the dump. This is a 
> bit inconvenient, but works as a workaround for now.
>  
> Sent from Outlook
>  
> 
> From: Pavel Labath 
> Sent: Friday, January 20, 2017 6:55 AM
> To: Eugene Birukov
> Cc: LLDB; rd...@microsoft.com
> Subject: Re: [lldb-dev] LLDB 3.9 on Linux crashes when loading core dump
>  
> Hello Eugene,
> 
> I have been aware of this problem for a while, but I haven't found a
> really good solution so far, partially due to lack of a good repro
> case -- I think your analysis has helped me with this, and I am
> finally starting to piece together the sequence of events leading to
> the crash. If you have a repro case you can send me, it would be even
> better.
> 
> I don't really have an answer to your quesiton, but here are a couple
> of observations (the details might be a bit sketchy - it's been a long
> time since I looked at this):
> - reading the section headers from memory should be a fallback.
> Normally we try first to locate the file on disk and read data from
> there. This was mainly added for the vdso "module", as that is not
> really present on disk. One of the ways of fixing this crash could be
> to figure out why we are not finding the c++abi binary on disk.
> 
> - we trust far too much the data we read from inferior memory. We
> should be much more careful when doing things based on "untrusted"
> data. Checking the memory maps as you suggest could be one idea.
> Another option I am considering is teaching ReadMemory to allocate
> data in (reasonably sized, say a couple of MB) chunks. Right now it
> allocates the full buffer without even trying to read the memory. If
> it instead tried to read data in smaller chunks it would error out due
> to failure to read inferior memory long before it gets a chance to
> exhaust own address space. (With a sufficiently large chunk, this
> should not affect performance of normal reads).
> 
> hope that helps,
> pl
> 
> 
> 
> On 19 January 2017 at 19:41, Eugene Birukov via lldb-dev
>  wrote:
> > Hi,
> >
> >
> > I have a Linux core dump that causes LLDB 3.9 on Linux crash. I would
> > greatly appreciate any advise how to deal with the problem or what else I
> > should look at.
> >
> >
> > The core dump was produced by GDB and GDB itself opens it without problems.
> >
> >
> > So, during loading the core we call
> > DynamicLoaderPOSIXDYLD::LoadAllCurrentModules() which enumerates all the
> > modules and does some processing. In the course of actions, it calls the
> > ObjectFileELF::GetSectionHeaderInfo() for each module. This guy tries to
> > load section headers and read string table. Well, it gets some garbage in
> > the section header struct and tries to allocate 1.5TB memory which causes
> > operator new throw.
> >
> >
> > So, why we get garbage?
> >
> >
> > The module in question is libc++abi.so.1:
> >
> >
> > 521 ModuleSP module_sp = LoadModuleAtAddress(I->file_spec,
> > I->link_addr, I->base_addr, true);
> >
> > (gdb) p I->file_spec
> >
> > $95 = {
> >
> >   m_directory = {
> >
> > m_string = 0x829a58 "... redacted ..."
> >
> >   },
> >
> >   m_filename = {
> >
> > m_string = 0x7cc9e8 "libc++abi.so.1"
> >
> >   },
> >
> >   m_is_resolved = false,
> >
> >   m_syntax = lldb_private::FileSpec::ePathSyntaxPosix
> >
> > }
> >
> >
> > The module header lives at address 

Re: [lldb-dev] LLDB 3.9 on Linux crashes when loading core dump

[Jim Ingham via lldb-dev]

All the lldb.llvm.org web pages are taken from the www directory in the 
sources.  So just change it there and the web page will get updated.

The one you want is lldb-gdb.html.

Jim

> On Jan 20, 2017, at 4:44 PM, Eugene Birukov  wrote:
> 
> Sorry, never done that - where this HTML is located and what is the procedure 
> of updating it?
> 
> Sent from Outlook
> 
> 
> From: jing...@apple.com  on behalf of Jim Ingham 
> 
> Sent: Friday, January 20, 2017 4:35 PM
> To: Ted Woodward
> Cc: Eugene Birukov; Pavel Labath; LLDB; rd...@microsoft.com
> Subject: Re: [lldb-dev] LLDB 3.9 on Linux crashes when loading core dump
>  
> If that works, can you add it to the lldb-gdb.html document?
> 
> Jim
> 
> > On Jan 20, 2017, at 3:57 PM, Ted Woodward via lldb-dev 
> >  wrote:
> > 
> > Try “image search-paths add” as a replacement for “set solib-search-path”
> >  
> > --
> > Qualcomm Innovation Center, Inc.
> > The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a 
> > Linux Foundation Collaborative Project
> >  
> > From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Eugene 
> > Birukov via lldb-dev
> > Sent: Friday, January 20, 2017 12:35 PM
> > To: Pavel Labath 
> > Cc: rd...@microsoft.com; LLDB 
> > Subject: Re: [lldb-dev] LLDB 3.9 on Linux crashes when loading core dump
> >  
> > Hello Pavel,
> >  
> > Thanks for the reply. Unfortunately I cannot share the core dump with you.
> >  
> > Yes, Rob has figured that LLDB does not find this shared library and that 
> > causes the problem. To understand what is going on here, I need to add one 
> > more detail that was missing from my original post: this is a cross-machine 
> > investigation. I.e. the core dump collected on one machine (CentOs) was 
> > sent to another
> > (Ubuntu) where I tried to open it.
> >  
> > LLDB opens the executable without paying attention that there is a core 
> > dump attached and tries to locate shared libraries. Apparently the ones 
> > that exist on my machine are not good, so it then looks in the directory 
> > with the executable itself. There is no way to "set solib-search-path" as 
> > we do on GDB and force it to look somewhere else. After we dumped all the 
> > shared libraries in the folder with the executable LLDB was able to open 
> > the dump. This is a bit inconvenient, but works as a workaround for now.
> >  
> > Sent from Outlook
> >  
> > 
> > From: Pavel Labath 
> > Sent: Friday, January 20, 2017 6:55 AM
> > To: Eugene Birukov
> > Cc: LLDB; rd...@microsoft.com
> > Subject: Re: [lldb-dev] LLDB 3.9 on Linux crashes when loading core dump
> >  
> > Hello Eugene,
> > 
> > I have been aware of this problem for a while, but I haven't found a
> > really good solution so far, partially due to lack of a good repro
> > case -- I think your analysis has helped me with this, and I am
> > finally starting to piece together the sequence of events leading to
> > the crash. If you have a repro case you can send me, it would be even
> > better.
> > 
> > I don't really have an answer to your quesiton, but here are a couple
> > of observations (the details might be a bit sketchy - it's been a long
> > time since I looked at this):
> > - reading the section headers from memory should be a fallback.
> > Normally we try first to locate the file on disk and read data from
> > there. This was mainly added for the vdso "module", as that is not
> > really present on disk. One of the ways of fixing this crash could be
> > to figure out why we are not finding the c++abi binary on disk.
> > 
> > - we trust far too much the data we read from inferior memory. We
> > should be much more careful when doing things based on "untrusted"
> > data. Checking the memory maps as you suggest could be one idea.
> > Another option I am considering is teaching ReadMemory to allocate
> > data in (reasonably sized, say a couple of MB) chunks. Right now it
> > allocates the full buffer without even trying to read the memory. If
> > it instead tried to read data in smaller chunks it would error out due
> > to failure to read inferior memory long before it gets a chance to
> > exhaust own address space. (With a sufficiently large chunk, this
> > should not affect performance of normal reads).
> > 
> > hope that helps,
> > pl
> > 
> > 
> > 
> > On 19 January 2017 at 19:41, Eugene Birukov via lldb-dev
> >  wrote:
> > > Hi,
> > >
> > >
> > > I have a Linux core dump that causes LLDB 3.9 on Linux crash. I would
> > > greatly appreciate any advise how to deal with the problem or what else I
> > > should look at.
> > >
> > >
> > > The core dump was produced by GDB and GDB itself opens it without 
> > > problems.
> > >
> > >
> > > So, during loading the core we call
> > > DynamicLoaderPOSIXDYLD::LoadAllCurrentModules() which enumerates all the
> > > modules and does some 

Re: [lldb-dev] Too many ModuleSP references

[Jim Ingham via lldb-dev]

> On Feb 21, 2017, at 4:24 PM, Greg Clayton via lldb-dev 
>  wrote:
> 
>> - StepOverBreakpointTestCase: Have the test not store the breakpoints
>> in the test case object. Basically, declare that this is not a bug,
>> and it's the users responsibility to clean up necessary objects.
> 
> It would be nice to avoid this.
> 
>> 

I don't agree with this.  I think trying to force folks using the API from 
Python to manually clear all stored objects would be really obnoxious.  If 
anything, we should figure out how to make this accidental failure into an 
intended failure so we can make sure we don't end up requiring this kind of 
micro-management.

Jim


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

Re: [lldb-dev] Too many ModuleSP references

[Jim Ingham via lldb-dev]

> On Feb 21, 2017, at 4:49 PM, Jim Ingham via lldb-dev 
> <lldb-dev@lists.llvm.org> wrote:
> 
> 
>> On Feb 21, 2017, at 4:24 PM, Greg Clayton via lldb-dev 
>> <lldb-dev@lists.llvm.org> wrote:
>> 
>>> - StepOverBreakpointTestCase: Have the test not store the breakpoints
>>> in the test case object. Basically, declare that this is not a bug,
>>> and it's the users responsibility to clean up necessary objects.
>> 
>> It would be nice to avoid this.
>> 
>>> 
> 
> I don't agree with this.  I think trying to force folks using the API from 
> Python to manually clear all stored objects would be really obnoxious.  If 
> anything, we should figure out how to make this accidental failure into an 
> intended failure so we can make sure we don't end up requiring this kind of 
> micro-management.

It's possible you meant "it would be nice to avoid it's being the user's 
responsibility to clean up necessary objects", in which case sorry for 
mis-reading but happy we agree...

Jim


> 
> Jim
> 
> 
> ___
> 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] Too many ModuleSP references

[Jim Ingham via lldb-dev]

> On Feb 21, 2017, at 4:26 PM, Greg Clayton <gclay...@apple.com> wrote:
> 
>> 
>> On Feb 21, 2017, at 9:36 AM, Jim Ingham via lldb-dev 
>> <lldb-dev@lists.llvm.org> wrote:
>> 
>> Thanks for digging into this.
>> 
>> Maybe a better option would be to have IRExecutionUnit hold a 
>> SymbolContextScope, rather than a SymbolContext.  We started out with 
>> SymbolContext's because they were convenient but they hold too many things 
>> alive so when we run into SymbolContext's we've been converting them to the 
>> SymbolContextScope's when possible.  I can't see any need for the 
>> IRExecutionUnit to hold the module alive, so long as it handles failure to 
>> get the SymbolContext gracefully, which shouldn't be hard.
> 
> SymbolContextScope doesn't hold ownership as it is just a pointer. This 
> pointer would go bad if the module goes away and it would crash when you 
> tried to use it. See my other email for another approach with 
> SymbolContextRef.

Brain, brain, what is brain?

Yeah, I was conflating ExecutionContextRef & SymbolContext.  But still, having a SymbolContext equivalent to ExecutionContextRef 
seems the correct solution to me, even though we don't have the pre-baked class 
for it.

Jim


> 
> Greg
> 
>> 
>> Jim
>> 
>>> On Feb 21, 2017, at 9:03 AM, Pavel Labath via lldb-dev 
>>> <lldb-dev@lists.llvm.org> wrote:
>>> 
>>> Hello all,
>>> 
>>> I've been debugging the newly added TestStepOverBreakpoint.py, which
>>> has been failing on windows, for a very prosaic reason: after the test
>>> completes, we are unable to run "make clean" because lldb still holds
>>> the file open.
>>> 
>>> After some debugging, I've found that this happens because the test
>>> case stores the SBBreakpoint object in a member variable of the python
>>> test case class. The breakpoint class ends up transitively holding a
>>> reference to the main executable module, which prevents the module
>>> from being garbage-collected when the target is destroyed.
>>> 
>>> For reference, the full ownership chain is something like:
>>> StepOverBreakpointTestCase(python) => SBBreakpoint => Breakpoint =>
>>> BreakpointLocation => LLVMUserExpression => IRExecutionUnit =>
>>> SymbolContext => Module.
>>> 
>>> To get the test working, we need to break this chain somewhere. A
>>> couple of places I see are:
>>> - BreakpointLocation: Remove the compiled expression reference when
>>> the target is destroyed (AFAICS, it is used as a cache to avoid
>>> recomputing the expression every time. It can be theoretically
>>> recomputed if needed, but that shouldn't be necessary as the target is
>>> destroyed anyway)
>>> 
>>> - SBBreakpoint: make SBBreakpoint hold a weak_ptr to the Breakpoint
>>> object. When the target is destroyed, the SBBreakpoint object becomes
>>> invalid (One doesn't cannot do anything useful with the breakpoint
>>> once the target has been deleted anyway).
>>> 
>>> - StepOverBreakpointTestCase: Have the test not store the breakpoints
>>> in the test case object. Basically, declare that this is not a bug,
>>> and it's the users responsibility to clean up necessary objects.
>>> 
>>> Any thoughts on what is the appropriate solution here?
>>> 
>>> cheers,
>>> pavel
>>> ___
>>> 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] Too many ModuleSP references

[Jim Ingham via lldb-dev]

Thanks for digging into this.

Maybe a better option would be to have IRExecutionUnit hold a 
SymbolContextScope, rather than a SymbolContext.  We started out with 
SymbolContext's because they were convenient but they hold too many things 
alive so when we run into SymbolContext's we've been converting them to the 
SymbolContextScope's when possible.  I can't see any need for the 
IRExecutionUnit to hold the module alive, so long as it handles failure to get 
the SymbolContext gracefully, which shouldn't be hard.

Jim

> On Feb 21, 2017, at 9:03 AM, Pavel Labath via lldb-dev 
>  wrote:
> 
> Hello all,
> 
> I've been debugging the newly added TestStepOverBreakpoint.py, which
> has been failing on windows, for a very prosaic reason: after the test
> completes, we are unable to run "make clean" because lldb still holds
> the file open.
> 
> After some debugging, I've found that this happens because the test
> case stores the SBBreakpoint object in a member variable of the python
> test case class. The breakpoint class ends up transitively holding a
> reference to the main executable module, which prevents the module
> from being garbage-collected when the target is destroyed.
> 
> For reference, the full ownership chain is something like:
> StepOverBreakpointTestCase(python) => SBBreakpoint => Breakpoint =>
> BreakpointLocation => LLVMUserExpression => IRExecutionUnit =>
> SymbolContext => Module.
> 
> To get the test working, we need to break this chain somewhere. A
> couple of places I see are:
> - BreakpointLocation: Remove the compiled expression reference when
> the target is destroyed (AFAICS, it is used as a cache to avoid
> recomputing the expression every time. It can be theoretically
> recomputed if needed, but that shouldn't be necessary as the target is
> destroyed anyway)
> 
> - SBBreakpoint: make SBBreakpoint hold a weak_ptr to the Breakpoint
> object. When the target is destroyed, the SBBreakpoint object becomes
> invalid (One doesn't cannot do anything useful with the breakpoint
> once the target has been deleted anyway).
> 
> - StepOverBreakpointTestCase: Have the test not store the breakpoints
> in the test case object. Basically, declare that this is not a bug,
> and it's the users responsibility to clean up necessary objects.
> 
> Any thoughts on what is the appropriate solution here?
> 
> cheers,
> pavel
> ___
> 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] showing CPU register flags

[Jim Ingham via lldb-dev]

We've talked about providing a more natural view of registers that are 
logically made of subfields, as you describe, but I don't think any work has 
been done on that front.

The ValueObjectRegister has a couple of ways to implement this display.  The 
ValueObjectRegisters can be given a type, and then will display the subfields 
as though they were of that type.  So you could cons up synthetic types for 
your registers, and use that to display them.  The other way would be to use 
the synthetic child mechanism for ValueObjects in general, would be pretty 
amenable to this sort of re-presentation.  Another slightly tricky bit would be 
that if you showed a register as having "sub-fields" folks would probably 
assume they could use these for "register write" as well are "register read".  
I don't think the synthetic children can be used to change values of the 
ValueObject that produced them.  But if you gave them a synthetic type instead, 
that might just fall out.

The other concern is that the "register read" command uses a lower level 
interface (RegisterValues) rather than using ValueObjectRegister's.  The 
RegisterValues really want to be scalars, so they don't provide a natural way 
to do this.  You would probably have to convert "register read" over to use the 
ValueObject for this project to be worth doing.

Jim


> On Aug 17, 2016, at 8:17 AM, Giusti, Valentina via lldb-dev 
>  wrote:
> 
> Hi everyone,
> 
> I am currently implementing the support for the Intel MPX registers in LLDB. 
> This register set includes 2 registers, BNDSTATUS and BNDCFGU, which store 
> information about the status and configuration of the MPX feature in several 
> fields.
> I think that it would be useful for the user to have a nice display of such 
> fields, so that they don't have to extract the information from the raw 
> values of the registers. However, I see that the other registers are just 
> displayed as raw values, without any better ways to explore their contents.
> 
> Should I just follow this approach, and also just let the MPX registers be 
> available through their raw values? 
> Or have there ever been any requests for ways to display the register flags 
> from LLDB?
> 
> Thanks,
> - Valentina Giusti
> 
> 
> Intel Deutschland GmbH
> Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
> Tel: +49 89 99 8853-0, www.intel.de
> Managing Directors: Christin Eisenschmid, Christian Lamprechter
> Chairperson of the Supervisory Board: Nicole Lau
> Registered Office: Munich
> Commercial Register: Amtsgericht Muenchen HRB 186928
> 
> ___
> 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 on windows] Step out is not working

[Jim Ingham via lldb-dev]

I presume you meant "step over is not working" in the Subject?

The call to std::cout... ends up inserting quite a number of inlined function 
calls into my_func.  clang is not always great at generating coherent 
line-table and inlined subroutine ranges for deeply nested inlining, so that 
the stepping machinery can't safely figure out how to get out of the inlining, 
and ends up stopping.  This example actually works correctly on macOS with a 
recent clang, but this has been an ongoing issue for a while now.

lldb currently always implements "step over" as "step in" followed by "step 
out".  This saves us the (sometimes surprisingly tricky) work of predicting 
where a particular call will go, and where it will return to.  But it does 
leave us vulnerable to errors in the debug information at the callee site.  It 
would be nice to add a set of "vanilla" calls that we're sure we can predict, 
and for those we could just break on the return address and not even bother to 
step in.  That would likely remove this sort of stumble in a lot of cases.

OTOH, you should still file a bug about this.  As I said, this works correctly 
on current TOT lldb/clang 802 on macOS.  So it may also be some issue with the 
Windows port unrelated to this debug info problem.

Jim

> On Feb 28, 2017, at 3:35 AM, olizit via lldb-dev  
> wrote:
> 
> Hello,
> 
> Compile this sample program with clang 3.9.1 in 64bits mode
> #include 
> 
> int my_func(char c, double d)
> {
>   std::cout << "c: " << c << std::endl;
>   std::cout << "d:" << d << std::endl;
>   return 0;
> }
> 
> int main(int argc, char const *argv[])
> {
>   int i = 0;
>   i++;
>   i++;
>   my_func('a', 10.1);
>   i++;
>   i++;
>   
>   return 0;
> }
> 
> compile commande line :
> clang++ -x c++ -target "x86_64-pc-windows-msvc" -O0 -glldb -gdwarf-4 -D 
> _WIN32 -D _WIN64 -D _CONSOLE -D NDEBUG -D _DEBUG -D _MT -D _DLL -c -o main.o 
> main.cpp 
> lld-link /out:main.exe /machine:X64 /nxcompat /incremental  /nologo /wx 
> /subsystem:console /debug vcruntimed.lib msvcrtd.lib main.o
> 
> run lldb and enter commands
> target create "main.exe"
> b main.cpp:14
> r
> 
> First step over (n command) is ok but second step over goes into my_func 
> function.
> 
> 
> Thanks,
> 
> Olivier
> ___
> 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] [OS X] debugserver SETUID root?

[Jim Ingham via lldb-dev]

> On Sep 1, 2016, at 2:01 AM, René J.V. Bertin via lldb-dev 
>  wrote:
> 
> Hi,
> 
> MacPorts has long had ports for llvm and clang which are very practical. 
> Ports for lldb have been missing until now, so I've been trying to create one 
> based on the existing clang port. That wasn't particularly difficult, except 
> (who'd guess) for the codesigning bit.
> 
> Two questions: 
> 
> - to what extent is it indeed (still) required to reboot after each attempt 
> to (re)sign an executable? It doesn't appear to be the case for applications 
> that just need to accept internet connections, for instance.

You don't have to reboot after every attempt to sign an executable.  You only 
have to reboot after making the code signing identity and, doing the little 
command line trick to get the system to accept it.  That still seems necessary, 
but then once you've done that you can keep using that identity either till it 
expires or you reinstall your OS.

> - does the debugserver application do anything which makes it a really bad 
> idea to make it SETUID root?
> 

Apple goes to pretty great lengths to limit the harm a debugger can do as an 
attack vector.  With SIP on, being root gives you many fewer permissions w.r.t. 
debugging than you might think, so I don't actually think this would help much. 
 Suggesting people turn SIP off to use your debugger build seems like a bad 
idea to me.

> And a bonus question: has it ever been tried to sign the debugserver file 
> with the ad hoc identity ("-")? That identity works for accepting internet 
> connections (= once signed like that applications no longer put up the 
> deny/allow connection dialog each time they're started).

I doubt that would work.

Jim 

> 
> Thanks,
> René
> ___
> 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] Symbol Server for everyone.

[Jim Ingham via lldb-dev]

The "dsymForUUID" tool doesn't handle copying source files around - we tend to 
just remote mount them.  But we do include these keys in the return plist so 
that lldb can automatically remap the source files from where they were at 
build time to where they are at debug time.  So if your symbol server copies 
files locally and they aren't in the same location as at build time, you might 
want to play a similar trick on your end.

Jim

> On Aug 30, 2016, at 7:18 AM, Taras Tsugrii via lldb-dev 
>  wrote:
> 
> DBGBuildSourcePath
> /path/to/build/sources
> DBGSourcePath
> /path/to/actual/sources

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

Re: [lldb-dev] Help with Xcode crash on lldb_private::(anonymous namespace)::parse_builtin_type

[Jim Ingham via lldb-dev]

That is the demangler crashing on some C++ name in your program.

We added a "demangle" log channel to the lldb for Xcode 8.0 (it's also in TOT 
lldb) to make debugging this sort of crash easier.  Put:

log enable -f /tmp/lldb-demangle-log.txt lldb demangle

in your ~/.lldbinit file, then run your program till Xcode crashes, and look at 
the log file.  It will have a lot of output in pairs like:

demangle itanium: _Z12preoptimized
demangled itanium: _Z12preoptimized -> "preoptimized"

but then at the end will be an instance with the first line, not the second.  
That will be the problem. 

You can have multiple copies of Xcode on your system, so you wouldn't have to 
switch to 8.0 for your day-to-day work.  But if you can't easily switch to 
Xcode 8.0 for this analysis, you could try debugging Xcode with lldb, and 
setting a breakpoint at _cxa_demangle and print the incoming strings:

(lldb) expr (char *) $arg1

till you get the crash.  Do this in a breakpoint command with "continue" after 
the printing.  This is all optimized code so you are unlikely to be able to 
recover the full string that high up on the stack when you crash, you'll have 
to print all the strings at the call site.

LLDB uses a version of the system demangler code with some bug fixes.  It would 
be interesting to see if the system demangler also crashes on this:

$ c++filt 

But in any case, please file a bug with that bad symbol.  

Short of fixing the demangler bug, however, I can't see any easy way to work 
around this.  Our copy of the demangler hasn't changed since late May 2015, so 
this is more likely a latent bug tripped by some new symbol that is being 
generated by the compiler.  If you can identify  change in your code has 
started producing this troublesome symbol, you might be able to work around it 
that way, though this is not a great solution.

Jim


> On Aug 24, 2016, at 11:12 AM, Sara Burke via lldb-dev 
>  wrote:
> 
> Hi lldb-dev,
> 
> I’m getting a consistent crash in Xcode and am at my last resort trying to 
> figure out the cause. I’m coming to you guys to ask for help on what could be 
> causing the crash, and emailing lldb-dev in particular because the crash 
> seems to be happening in com.apple.LLDB.framework. 
> 
> We have hundreds of iOS apps (executables compiled for iOS & wrapped in .app 
> packages in order to run them on iOS devices). These executables link to a 
> bunch of iOS static libraries. Recently, someone in our codebase submitted 
> some code that is now causing Xcode to crash when the app launches. The crash 
> occurs for every app downstream of a particular library, with the same exact 
> crash log. I suspect someone submitted some code in that library that lldb 
> can’t handle, but the problem is, I am not able to identify which part of the 
> code is causing the problem; nothing looks suspicious. In addition, there are 
> a lot of changes, so I can’t cherry pick which ones to compile & test without 
> compiling all of them. 
>  
> Each time the crash occurs, the main thread is the “crashing thread”, but the 
> DBGLLDBLauncher Serial Queue is the thing that appears to be stuck, most 
> likely causing the main thread to crash. Below is the stack trace. 
> 
> Can anyone give me some hints on what might be causing this stack trace to 
> crash the main thread? I have been doing research and experiments for the 
> last few days and can’t seem to acquire any useful information.  If anyone 
> has suggestions for getting for info, please let me know. I’m really stuck 
> here.
> 
> Attached is an example full crash report, along with a sample of Xcode during 
> the crash. The sample gives a bit more detail, but is consistent with the 
> stack trace below. 
> 
> 
> Thread 14:: Dispatch queue: DBGLLDBLauncher Serial Queue
> 0   com.apple.LLDB.framework  
> 0x000117973179 char const* lldb_private::(anonymous 
> namespace)::parse_builtin_type(char 
> const*, char const*, lldb_private::(anonymous namespace)::Db&) + 4
> 1   com.apple.LLDB.framework  
> 0x00011795340c char const* lldb_private::(anonymous 
> namespace)::parse_type(char const*, 
> char const*, lldb_private::(anonymous namespace)::Db&) + 331
> 2   com.apple.LLDB.framework  
> 0x0001179561a6 char const* lldb_private::(anonymous 
> namespace)::parse_type(char const*, 
> char const*, lldb_private::(anonymous namespace)::Db&) + 12005
> 3   com.apple.LLDB.framework  
> 0x0001179548ca char const* lldb_private::(anonymous 
> namespace)::parse_type(char const*, 
> char const*, lldb_private::(anonymous namespace)::Db&) + 5641
> 4   com.apple.LLDB.framework  
> 0x00011795c154 char const* lldb_private::(anonymous 
> namespace)::parse_template_args(char 
> const*, char const*, 

Re: [lldb-dev] Problem with watchpoints

[Jim Ingham via lldb-dev]

The main problem with the watchpoint code is that it doesn't share nearly as 
much of the implementation of options and callback handling with the 
breakpoints as it should.  For instance, there's very little need for 
WatchpointOptions and BreakpointOptions to be separate classes, they do pretty 
much exactly the same thing.  If you want to hack on this, the best approach I 
think would be to remove the watchpoint options, and see how far you can get 
using the breakpoint option class.  I bet a lot of goodness will fall out of 
that.  The PerformActions for the StopInfoWatchpoint and StopInfoBreakpoint 
could probably share much of their implementations as well.  This is one of 
those cleanups that's been floating around on all our to-do lists for a while 
now, but keeps getting displaced by other tasks.

The BreakpointOptions.h and WatchpointOptions.h files a pretty well documented. 
 That's a fairly good example of how we used to do this.  We don't tend to put 
top-level docs in .cpp files.

Jim


> On Sep 9, 2016, at 2:13 PM, Daniel Noland via lldb-dev 
>  wrote:
> 
> I have also noticed a few problems similar to Ted's and I plan to
> address them assuming nobody else is already on it.  That said, I am new
> around here so please bear with me :)
> 
> In fact, I have been hacking on a few watchpoint methods for a while
> now.  I have implemented some features I personally wanted (specifically
> callback functions in the SBWatchpoint api). 
> 
> I have not yet created a PR (or whatever SVN equivalent) for several
> reasons (obviously including the big reformat), but mostly I am a bit
> lost with respect to proper procedure here.  I have gone through the
> code guidelines for LLVM and LLDB, but I am confused about some things.
> 
> * I have written unit test logic, but I don't really understand the LLDB
> testing framework.  Also, I understand from other threads that the
> framework is currently in flux in any case.
> 
> * I have written documentation, but I don't know if what I have written
> is even desirable.  For instance, the corresponding breakpoint
> implementation is almost totally lacking in source doc.
> 
> * I will need to rebase this patch on the reformatted code.  That is no
> big deal, but I have little experience with SVN and I will need to do
> some research to avoid turning an eventual merge into a big chore.
> 
> * I am pretty unclear on the appropriate way to make my changes work
> with the Python API.  Should that be on a different PR?  Are we
> targeting Python 2.7 and 3.{4,5} on all platforms?
> 
> * Do I need to check that the test suite passes on other platforms, or
> will other devs take care of that?  I don't use OSX or Windows.
> 
> Basically, I would like to help, but more than that I want my "help" to
> be helpful.
> 
> If somebody who knows what is going on would help me out I would greatly
> appreciate it.
> 
> \author{Daniel Noland}
> 
> On 09/09/2016 11:28 AM, Greg Clayton via lldb-dev wrote:
>>> On Sep 8, 2016, at 4:47 PM, Ted Woodward via lldb-dev 
>>>  wrote:
>>> 
>>> I recently discovered a problem with watchpoints talking to the Hexagon 
>>> simulator:
>>> 
>>> (lldb) w s e 0x1000
>>> error: Watchpoint creation failed (addr=0x1000, size=4).
>>> error: Target supports (0) hardware watchpoint slots.
>>> 
>>> 
>>> It seems that lldb now sends a qWatchpointSupportInfo packet. But this 
>>> packet isn’t defined in lldb-gdb-remote.txt.
>>> 
>>> Looking at the code, it expects to get back a pair “num:#”. If it doesn’t 
>>> it returns 0. The caller will report the above error if the number returned 
>>> is 0. So if qWatchpointSupportInfo isn’t supported, lldb can’t set a 
>>> watchpoint.
>>> 
>>> 
>>> What is the definition of the response to qWatchpointSupportInfo? Is the 
>>> the number of supported watchpoints, or the number of available 
>>> watchpoints? If it’s supported, then CheckIfWatchpointsExhausted won’t 
>>> really check if the watchpoints are exhausted. If it’s available, then a 
>>> return of 0 doesn’t let us aggregate watchpoints – a 4 byte watchpoint at 
>>> 0x1000 and one at 0x1004 could be one going from 0x1000-0x1007.
>> The person that checked this in no longer is working on LLDB and it has been 
>> like this since May 2012. It should return the total number of supported 
>> watchpoints. 
>>> 
>>> Wouldn’t it be better to try to set the watchpoint, then report a failure 
>>> if we get an error back from the remote server?
>> It is kind of nice to know that you can't set watchpoints because they 
>> aren't supported since we can provide a nicer message than "E98 returned 
>> from GDB server". Errors in GDB remote protocol are a horrible mess and they 
>> don't mean anything. So any clearer we can be about this, the better, so we 
>> should keep the qWatchpointSupportInfo packet IMHO. I am fine with us 
>> modifying the GDBRemoteCommunicationClient to try and send this packet and 
>> if it comes back as 

Re: [lldb-dev] Problem with watchpoints

[Jim Ingham via lldb-dev]

> On Sep 12, 2016, at 11:53 AM, Daniel Noland  wrote:
> 
> 
> 
> On 09/12/2016 11:30 AM, Jim Ingham wrote:
>> 
>>> On Sep 9, 2016, at 7:33 PM, Daniel Noland  wrote:
>>> 
>>> Yes, that was pretty much my assessment when I read through the code.
>>> 
>>> My existing patch (which I will post when I get home) takes a very 
>>> conservative approach and only modifies what is strictly necessary to make 
>>> the callback feature work.
>>> 
>>> That said, I found myself copy / paste / slight changing a fair bit of code 
>>> to make it work.  Usually a very bad sign.
>>> 
>>> If we can agree that a more aggressive refactor is desirable I would prefer 
>>> that route.
>> 
>> This work really needs to be done, and shouldn't even be all that hard.  So 
>> putting too much effort into the current implementation seems throw-away 
>> work.  It's okay when small changes make useful functionality available, but 
>> not the right general direction.  If you are interested in taking a more 
>> comprehensive change on, that would be great!
>> 
> I am actually very relieved to hear that!
> 
> I have a strong personal motivation to see very robust watchpoint
> functionality in LLDB (the last two years of my life will be largely
> wasted without it).  If the community is open to a more aggressive
> change I will be very happy to put in work on this front.
> 
>>> 
>>> It may be worth looking at the GDB Python API 
>>> (https://sourceware.org/gdb/onlinedocs/gdb/Breakpoints-In-Python.html#Breakpoints-In-Python).
>>>   Watchpoints are just a species of breakpoint in that implementation.
>>> 
>>> I have done extensive work with that API, and while there are things I 
>>> would do very differently, I generally consider it to be fairly good.
>>> 
>> 
>> From the API perspective, watchpoints and breakpoints are equivalent, except 
>> where the brokenness of the implementation shows through.
>> 
>>> In fact, I think that the LLDB SB API could profit quite a bit from several 
>>> of the things GDB has done on that front.  That is particularly true with 
>>> respect to symbols, variables, and frames.  That subject likely deserves a 
>>> different thread.
>> 
>> Within the constraints of maintaining support for the extant SB API's, we 
>> can certainly look to improving the breakpoint/watchpoint interface.  But 
>> the most logical approach seems to me to be to move the watchpoints over to 
>> the sharing the extant and pretty functional breakpoint implementation 
>> first, and then see what we can more efficiently add stuff to both.
>> 
> I agree.  I plan to start exactly as you suggest.

Excellent, feel free to pester us with whatever questions you have as you 
proceed.  This is a piece of work that really does need to get done so I'm 
happy to see somebody taking it on.

> 
> My main thought here (which should likely get a different thread) is
> that, having worked with the GDB and LLDB api for a while now, I feel
> pretty strongly that GDB has a better cleaner handling of variable
> names, scopes, frames, and values than LLDB seems to offer (I would love
> to be wrong about this btw), and that adopting / adapting some of those
> abstractions may significantly improve the break/watchpoint api.
> 
> I should be able to say that with more authority after giving the
> implementation more careful study.

Great!  I look forward to your ideas.  One note is that we have promised not to 
break compatibility with the current SB API's till we decide to do a whole 
scale revision.  So for now whatever we change needs to fit within the current 
schema.

> 
>> We also have to be a little careful about taking things too directly from 
>> gdb due to licensing issues.
>> 
> Good point about licensing.  That said, if the concern is duplicating
> the implementation, I doubt that I could do it if I tried :)
> 
> Duplication of the API should not be an issue either as I plan to
> strictly adhere to the existing SB api.
> 

That sounds right.

Jim


>> Jim
>> 
>> 
>>> 
>>> \author{Dan}
>>> 
>>> On Fri, Sep 9, 2016 at 3:52 PM, Jim Ingham  wrote:
>>> The main problem with the watchpoint code is that it doesn't share nearly 
>>> as much of the implementation of options and callback handling with the 
>>> breakpoints as it should.  For instance, there's very little need for 
>>> WatchpointOptions and BreakpointOptions to be separate classes, they do 
>>> pretty much exactly the same thing.  If you want to hack on this, the best 
>>> approach I think would be to remove the watchpoint options, and see how far 
>>> you can get using the breakpoint option class.  I bet a lot of goodness 
>>> will fall out of that.  The PerformActions for the StopInfoWatchpoint and 
>>> StopInfoBreakpoint could probably share much of their implementations as 
>>> well.  This is one of those cleanups that's been floating around on all our 
>>> to-do lists for a while now, but keeps getting displaced by other tasks.

Re: [lldb-dev] Problem with watchpoints

[Jim Ingham via lldb-dev]

> On Sep 9, 2016, at 7:33 PM, Daniel Noland  wrote:
> 
> Yes, that was pretty much my assessment when I read through the code.
> 
> My existing patch (which I will post when I get home) takes a very 
> conservative approach and only modifies what is strictly necessary to make 
> the callback feature work.
> 
> That said, I found myself copy / paste / slight changing a fair bit of code 
> to make it work.  Usually a very bad sign.
> 
> If we can agree that a more aggressive refactor is desirable I would prefer 
> that route.

This work really needs to be done, and shouldn't even be all that hard.  So 
putting too much effort into the current implementation seems throw-away work.  
It's okay when small changes make useful functionality available, but not the 
right general direction.  If you are interested in taking a more comprehensive 
change on, that would be great!

> 
> It may be worth looking at the GDB Python API 
> (https://sourceware.org/gdb/onlinedocs/gdb/Breakpoints-In-Python.html#Breakpoints-In-Python).
>   Watchpoints are just a species of breakpoint in that implementation.
> 
> I have done extensive work with that API, and while there are things I would 
> do very differently, I generally consider it to be fairly good.
> 

From the API perspective, watchpoints and breakpoints are equivalent, except 
where the brokenness of the implementation shows through.

> In fact, I think that the LLDB SB API could profit quite a bit from several 
> of the things GDB has done on that front.  That is particularly true with 
> respect to symbols, variables, and frames.  That subject likely deserves a 
> different thread.

Within the constraints of maintaining support for the extant SB API's, we can 
certainly look to improving the breakpoint/watchpoint interface.  But the most 
logical approach seems to me to be to move the watchpoints over to the sharing 
the extant and pretty functional breakpoint implementation first, and then see 
what we can more efficiently add stuff to both.

We also have to be a little careful about taking things too directly from gdb 
due to licensing issues.

Jim


> 
> \author{Dan}
> 
> On Fri, Sep 9, 2016 at 3:52 PM, Jim Ingham  wrote:
> The main problem with the watchpoint code is that it doesn't share nearly as 
> much of the implementation of options and callback handling with the 
> breakpoints as it should.  For instance, there's very little need for 
> WatchpointOptions and BreakpointOptions to be separate classes, they do 
> pretty much exactly the same thing.  If you want to hack on this, the best 
> approach I think would be to remove the watchpoint options, and see how far 
> you can get using the breakpoint option class.  I bet a lot of goodness will 
> fall out of that.  The PerformActions for the StopInfoWatchpoint and 
> StopInfoBreakpoint could probably share much of their implementations as 
> well.  This is one of those cleanups that's been floating around on all our 
> to-do lists for a while now, but keeps getting displaced by other tasks.
> 
> The BreakpointOptions.h and WatchpointOptions.h files a pretty well 
> documented.  That's a fairly good example of how we used to do this.  We 
> don't tend to put top-level docs in .cpp files.
> 
> Jim
> 
> 
> > On Sep 9, 2016, at 2:13 PM, Daniel Noland via lldb-dev 
> >  wrote:
> >
> > I have also noticed a few problems similar to Ted's and I plan to
> > address them assuming nobody else is already on it.  That said, I am new
> > around here so please bear with me :)
> >
> > In fact, I have been hacking on a few watchpoint methods for a while
> > now.  I have implemented some features I personally wanted (specifically
> > callback functions in the SBWatchpoint api).
> >
> > I have not yet created a PR (or whatever SVN equivalent) for several
> > reasons (obviously including the big reformat), but mostly I am a bit
> > lost with respect to proper procedure here.  I have gone through the
> > code guidelines for LLVM and LLDB, but I am confused about some things.
> >
> > * I have written unit test logic, but I don't really understand the LLDB
> > testing framework.  Also, I understand from other threads that the
> > framework is currently in flux in any case.
> >
> > * I have written documentation, but I don't know if what I have written
> > is even desirable.  For instance, the corresponding breakpoint
> > implementation is almost totally lacking in source doc.
> >
> > * I will need to rebase this patch on the reformatted code.  That is no
> > big deal, but I have little experience with SVN and I will need to do
> > some research to avoid turning an eventual merge into a big chore.
> >
> > * I am pretty unclear on the appropriate way to make my changes work
> > with the Python API.  Should that be on a different PR?  Are we
> > targeting Python 2.7 and 3.{4,5} on all platforms?
> >
> > * Do I need to check that the test suite passes on other 

Re: [lldb-dev] lldb type summary provider - SBProcess is invalid

[Jim Ingham via lldb-dev]

Yes, the "script" command always sets up the lldb.{process/thread/frame} 
regardless of whether its input is one-line or from the Script Input reader.  
The help for script should specify that.

Jim

> On Sep 14, 2016, at 10:24 PM, Lei Kong via lldb-dev  
> wrote:
> 
> Does the following qualify as "interactive usage"?  It seems using "process" 
> works in myfile.func(), or I was just lucky? Thanks.
>  
> (lldb) script myfile.func(args)
>  
> > Subject: Re: [lldb-dev] lldb type summary provider - SBProcess is invalid
> > From: gclay...@apple.com
> > Date: Wed, 14 Sep 2016 09:33:20 -0700
> > CC: egran...@apple.com; lldb-dev@lists.llvm.org
> > To: leik...@msn.com
> > 
> > 
> > > On Sep 13, 2016, at 9:50 PM, Lei Kong via lldb-dev 
> > >  wrote:
> > > 
> > > Thanks!
> > > SBValue.process works!
> > >  
> > > I have another script that I run manually to search process memory for 
> > > certain patterns, not a type summary provider, there is no SBValue passed 
> > > to my script, in such a case, how do I get current process?
> > >  
> > If this is python a command line command you are making, use the variant 
> > that takes an execution context:
> > 
> > def my_command(debugger, command, exe_ctx, result, dict):
> > # Always use the specified execution context to get the target, process
> > # thread and frame. If this command gets run from a breakpoint callback
> > # these will not match the debugger's selected target, the selected 
> > # process in the target, the selected thread in the process and the 
> > # selected frame in the thread.
> > target = exe_ctx.GetTarget()
> > process = exe_ctx.GetProcess()
> > thread = exe_ctx.GetThread()
> > frame = exe_ctx.GetFrame()
> > 
> > 
> > The execution context is explicitly specified for you.
> > 
> > > From: Enrico Granata
> > > Sent: Tuesday, September 13, 2016 10:31 AM
> > > To: Lei Kong
> > > Cc: lldb-dev@lists.llvm.org
> > > Subject: Re: [lldb-dev] lldb type summary provider - SBProcess is invalid
> > >  
> > > 
> > >> On Sep 13, 2016, at 10:02 AM, Lei Kong via lldb-dev 
> > >>  wrote:
> > >> 
> > >> I wrote a lldb type summary provider for wstring with 16bit wchar on 
> > >> Ubuntu 16.04.
> > >> 
> > >> Things work fine if I manually do the following in lldb:
> > >> 
> > >> (lldb) script import mytypes
> > >> (lldb) type summary add -F mytypes.wstring_SummaryProvider 
> > >> "std::__1::wstring"
> > >> 
> > >> I tried to make things easier with auto-loading by adding the following 
> > >> to .lldbinit:
> > >> 
> > >> script import mytypes
> > >> type summary add -F mytypes.wstring_SummaryProvider "std::__1::wstring"
> > >> 
> > >> Then I got a failure of "SBProcess is invalid" when printing a wstring 
> > >> variable.
> > >> 
> > >> My type summary function has the following, which I believe is where the 
> > >> error is encountered:
> > >> 
> > >> content = lldb.process.ReadMemory(bufferAddr, byteCount, error)
> > >> 
> > >> Maybe this is because "process" is not assigned yet when the type 
> > >> summary is added during auto-loading? Or this is a bug in lldb? Does 
> > >> anyone know how to work around this issue?
> > >> 
> > >> 
> > > 
> > > Good hunch :-)
> > > Maybe we should do a better job at documenting this, but 
> > > http://lldb.llvm.org/python-reference.html reads
> > > 
> > > "While extremely convenient, these variables (lldb.process et alia) have 
> > > a couple caveats that you should be aware of. First of all, they hold the 
> > > values of the selected objects on entry to the embedded interpreter. They 
> > > do not update as you use the LLDB API's to change, for example, the 
> > > currently selected stack frame or thread. 
> > > Moreover, they are only defined and meaningful while in the interactive 
> > > Python interpreter. There is no guarantee on their value in any other 
> > > situation, hence you should not use them when defining Python formatters, 
> > > breakpoint scripts and commands (or any other Python extension point that 
> > > LLDB provides). As a rationale for such behavior, consider that lldb can 
> > > run in a multithreaded environment, and another thread might call the 
> > > "script" command, changing the value out from under you."
> > > 
> > > As part of a formatter, you get passed an SBValue. One of the things you 
> > > can ask of an SBValue is the process it came from, thusly:
> > > 
> > > value.GetProcess()
> > > 
> > > That's the SBProcess object you want to use
> > > 
> > >>  
> > >> Thanks much
> > >> 
> > >>  
> > >>  
> > >>  
> > >> ___
> > >> lldb-dev mailing list
> > >> lldb-dev@lists.llvm.org
> > >> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> > > 
> > > 
> > > Thanks,
> > > - Enrico
> > >  egranata@.com ️ 27683
> > > 
> > > ___
> > > lldb-dev mailing list
> > > lldb-dev@lists.llvm.org
> > > 

Re: [lldb-dev] Connecting to lldb-rpc-server

[Jim Ingham via lldb-dev]

Enrico is right.  At present, each connection to the lldb-rpc-server gets its 
own SBDebugger, so you wouldn't be able to talk to the debugger that Xcode is 
using for its process.

Even if that was changed, then you'd run into other problems, for instance, at 
present only one Listener can wait for process events from the debugger, so you 
would not be able to control execution or coordinate with Xcode's running of 
the process.  But this is probably just the tip of the iceberg of things that 
would go wrong if you try to do this.  

If you have lots of resources to devote to hacking on lldb itself, I'm sure you 
could make this work, but this is a very tricky part of lldb, so the 
engineering work would be non-trivial to say the least.  I don't know your 
circumstances, but I doubt it would end up being worthwhile for you.

Enrico's suggestion of making Python commands to do the job is probably the 
best way to go.

Note, it used to be tricky to get a plain command tool (lldb-rpc-server) to 
connect to the Window Server and put up UI.  I haven't tried that since I 
worked on Tcl/Tk way back in the day, so it may be easier now.  But you should 
probably also experiment with that to make sure that's possible before you go 
too far down this route.

Jim


> On Oct 7, 2016, at 12:05 PM, Rex Fenley via lldb-dev 
>  wrote:
> 
> https://media4.giphy.com/media/l2Je27KfKp8x71qAo/200.gif
> 
> On Fri, Oct 7, 2016 at 12:01 PM, Enrico Granata  wrote:
> It is my understanding that this is not possible in the current architecture
> 
>> On Oct 7, 2016, at 11:55 AM, Rex Fenley  wrote:
>> 
>> We expect to have a rich user experience as this tool progresses, using 
>> Python to generate UI will limit our development process. It would be much 
>> simpler if we could communicate with Xcode's lldb directly from our 
>> application.
>> 
>> On Fri, Oct 7, 2016 at 11:33 AM, Enrico Granata  wrote:
>> I can see a couple of avenues for your use case:
>> 
>> - you can write custom LLDB commands (obligatory reference: 
>> http://lldb.llvm.org/python-reference.html) and have your users type these 
>> via the console instead of by clicking buttons
>> - you could write a Python script that pops up extra UI and have your 
>> buttons run as part of LLDB that way. I have admittedly never tried to do 
>> this, and it might require some tinkering, but in theory I believe it should 
>> be possible
>> 
>> Personally, I'd rather much have console commands I can type instead of a 
>> magic separate UI that might even be hidden underneath other windows or 
>> hiding useful information unless I drag it out of the way, but then it's 
>> annoying to reach for when I need it, ..., but that's me...
>> 
>>> On Oct 7, 2016, at 11:27 AM, Rex Fenley  wrote:
>>> 
>>> I'm trying to build a separate debugging tool that can be used in unison 
>>> with Xcode it will provide buttons that are shortcuts to lldb scripts we 
>>> write.
>>> 
>>> On Fri, Oct 7, 2016 at 10:45 AM, Enrico Granata  wrote:
>>> I am gonna echo Kate's question, but delve one level deeper
>>> 
>>> Why do you want to send commands to LLDB from a different process?
>>> 
>>> We have a bunch of different extension points in LLDB, so it's possible 
>>> that what you're trying to do is actually already possible
>>> 
 On Oct 7, 2016, at 10:41 AM, Rex Fenley via lldb-dev 
  wrote:
 
 Hi Kate,
 
 I'm trying to connect to the running instance of lldb in Xcode to send 
 commands to it from a different process :)
 
 On Fri, Oct 7, 2016 at 10:27 AM, Kate Stone  wrote:
 The RPC mechanism used in Xcode 8 is not a part of the open source LLDB 
 project and should be treated as an implementation detail of Xcode.  What 
 are you trying to accomplish?
 
 Kate Stone k8st...@apple.com
  Xcode Low Level Tools
 
> On Oct 6, 2016, at 6:11 PM, Rex Fenley via lldb-dev 
>  wrote:
> 
> Hi! I'm trying to connect to Xcode's lldb rpc server but I'm having 
> trouble.
> 
> This doesn't seem to work to list the hosts.
> rpcinfo -p lldb-rpc-server
> 
> Can't contact rpcbind on lldb-rpc-server
> 
> 
> rpcinfo: RPC: Unknown host
> 
> Am I doing this correctly?
> 
> -- 
> Rex Fenley  |  IOS DEVELOPER
> 
> 
> Remind.com |  BLOG  |  FOLLOW US  |  LIKE US
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
 
 
 
 
 -- 
 Rex Fenley  |  IOS DEVELOPER
 
 
 Remind.com |  BLOG  |  FOLLOW US  |  LIKE US
 ___
 lldb-dev mailing list
 lldb-dev@lists.llvm.org
 

[lldb-dev] Asserts in StringRef::front

[Jim Ingham via lldb-dev]

I fixed a bug in CommandObject::Execute that cause test-suite crashes when 
running with an Assert build of llvm (r283479.)

The test was doing:

break modify -c ''

which is the way you unset a condition on a breakpoint.

So the StringRef for that option value was empty, and it appears that you 
aren't supposed to call "front" on an empty StringRef.  But empty option values 
are used in a bunch of places in lldb.

Zachary, you might want to go scrub through the Args changes (and anywhere else 
you might be parsing an empty StringRef) to make sure there aren't other errors 
of this sort.

And if you aren't running your prep testsuite runs with an Assert build of 
llvm, it's probably a good idea to do so.

Jim

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

Re: [lldb-dev] --top-level doesn't work in lldb for Objective-C or Swift :(

[Jim Ingham via lldb-dev]

> On Oct 5, 2016, at 10:06 AM, Rex Fenley  wrote:
> 
> Jim,
> 
> That doesn't seem to work for us. We're using lldb packaged with Xcode 8 fyi.
> (lldb) expr --top-level -- NSString *string = [NSString stringWithUTF8String: 
> "This is a string"];
> 
> 
> 
> ; Function Attrs: nounwind
> 
> define internal void @_GLOBAL__sub_I__null_() #0 section 
> "__TEXT,__StaticInit,regular,pure_instructions" {
> 
>   call void @__cxx_global_var_init()
> 
>   ret void
> 
> }
> 
> 

Yes, I see that printout too, but it doesn't make the expression not work.  
With 8.0 I see:

(lldb) expr --top-level -- NSString *string = [NSString stringWithUTF8String: 
"This is a string"];

; Function Attrs: nounwind
define internal void @_GLOBAL__sub_I__null_() #0 section 
"__TEXT,__StaticInit,regular,pure_instructions" {
  call void @__cxx_global_var_init()
  ret void
}

(lldb) po string
This is a string

So the expression definitely worked.

Can you file a bug about the spammy printing?  Looks like somebody left a 
printf in code somewhere.

Jim

> On Tue, Oct 4, 2016 at 4:09 PM, Jim Ingham  wrote:
> This isn't an issue with ObjC support in general, but rather shows that ObjC 
> string constants are odd beasts.  You can work around this pretty easily by 
> making dynamic strings:
> 
> (lldb) expr --top-level -- NSString *string = [NSString stringWithUTF8String: 
> "This is a string"];
> (lldb) expr string
> (__NSCFString *) $0 = 0x0001002001b0 @"This is a string"
> 
> Please file a bug about the problem with ObjC constant strings.
> 
> Jim
> 
> 
> > On Oct 4, 2016, at 3:57 PM, Rex Fenley via lldb-dev 
> >  wrote:
> >
> > Hey lldb team!
> >
> > I'm trying to use `expr --top-level` from lldb in Xcode but it throws 
> > errors like the following:
> >
> > (lldb) expression --top-level -- NSString *str = @"This is a string";
> > Error [IRForTarget]: Couldn't replace an Objective-C constant string with a 
> > dynamic string
> > error: cannot import unsupported AST node ObjCStringLiteral
> > error: The expression could not be prepared to run in the target
> >
> > It seems like top-level only supports raw C code and not Objective-C. Is 
> > there an option we can set to support this? Is there somewhere in lldb's 
> > source code that could help point us to fixing this?
> >
> > Thank you, you guys rule!
> >
> > --
> > Rex Fenley  |  IOS DEVELOPER
> >
> >
> > Remind.com |  BLOG  |  FOLLOW US  |  LIKE US
> > ___
> > lldb-dev mailing list
> > lldb-dev@lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> 
> 
> 
> 
> -- 
> Rex Fenley  |  IOS DEVELOPER
> 
> 
> Remind.com |  BLOG  |  FOLLOW US  |  LIKE US

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

Re: [lldb-dev] --top-level doesn't work in lldb for Objective-C or Swift :(

[Jim Ingham via lldb-dev]

This isn't an issue with ObjC support in general, but rather shows that ObjC 
string constants are odd beasts.  You can work around this pretty easily by 
making dynamic strings:

(lldb) expr --top-level -- NSString *string = [NSString stringWithUTF8String: 
"This is a string"];
(lldb) expr string
(__NSCFString *) $0 = 0x0001002001b0 @"This is a string"

Please file a bug about the problem with ObjC constant strings.

Jim


> On Oct 4, 2016, at 3:57 PM, Rex Fenley via lldb-dev  
> wrote:
> 
> Hey lldb team!
> 
> I'm trying to use `expr --top-level` from lldb in Xcode but it throws errors 
> like the following:
> 
> (lldb) expression --top-level -- NSString *str = @"This is a string";
> Error [IRForTarget]: Couldn't replace an Objective-C constant string with a 
> dynamic string
> error: cannot import unsupported AST node ObjCStringLiteral
> error: The expression could not be prepared to run in the target
> 
> It seems like top-level only supports raw C code and not Objective-C. Is 
> there an option we can set to support this? Is there somewhere in lldb's 
> source code that could help point us to fixing this?
> 
> Thank you, you guys rule!
> 
> -- 
> Rex Fenley  |  IOS DEVELOPER
> 
> 
> Remind.com |  BLOG  |  FOLLOW US  |  LIKE US
> ___
> 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] --top-level doesn't work in lldb for Objective-C or Swift :(

[Jim Ingham via lldb-dev]

This isn't the appropriate place to discuss lldb-swift build problems, since 
the swift support is not actually in the llvm.org tree.  A better mailing list 
would be:

https://lists.swift.org/mailman/listinfo/swift-lldb-dev

Jim

> On Oct 5, 2016, at 12:25 PM, Rex Fenley  wrote:
> 
> Hey!
> 
> I tried building the LLDB target from within Xcode in order to gain 
> understanding of how this system works at the source level. However, I get 
> the following error during compilation:
> subprocess.CalledProcessError: Command '['python', 
> '/Users/Rex/Documents/projects/swift-lldb/llvm/tools/swift/utils/build-script',
>  '--preset=LLDB_Swift_ReleaseAssert', 
> 'swift_install_destdir=/Users/Rex/Documents/projects/swift-lldb/llvm-build/ReleaseAssert/swift-macosx-x86_64']'
>  returned non-zero exit status 1
> 
> And much further up I see
> 
> warning: A compatible version of re2c (>= 0.11.3) was not found; changes to 
> src/*.in.cc will not affect your build.
> 
> 
> and
> 
> error: unknown setting: cmark-cmake-options
> 
> How may I fix this/these issues to build and run lldb from Xcode?
> 
> 
> On Wed, Oct 5, 2016 at 12:05 PM, Rex Fenley  wrote:
> That's totally fine for our use case.
> 
> On Wed, Oct 5, 2016 at 11:57 AM, Jim Ingham  wrote:
> You would have to be really careful about using "debugger variables" whose 
> name is not decorated with a "$".  After all, this is introducing a global 
> variable, which will be shadowed by local variables, ivars, file statics for 
> the current frame's CU, etc.  So using the code you've added at various stop 
> points in the debugging session will be fragile.  That's the primary reason 
> that we don't encourage defining debugger variables in the common identifier 
> namespace of your program.
> 
> Jim
> 
> 
> 
> > On Oct 5, 2016, at 11:41 AM, Rex Fenley  wrote:
> >
> > Hey Kate! Thanks for all this info, it's really helpful :)
> >
> > We'd like to have more complex expressions being used from the debugger. 
> > Some of this would be code written in separate files. It will be difficult 
> > or at least very tedious to have all our code use "$", is there a way to 
> > void using "$"? Is there an option we could add to lldb to avoid using "$" 
> > and still have variables and data-structures globally accessible? I notice 
> > that within "repl" "$" it's not necessary to use any "$" variables, is 
> > there a way to elevate the logic "repl" uses into expr?
> >
> > On Wed, Oct 5, 2016 at 11:29 AM, Kate Stone  wrote:
> >> On Oct 5, 2016, at 10:14 AM, Rex Fenley via lldb-dev 
> >>  wrote:
> >>
> >> Maybe I have that incorrectly, this does seem to work when using lldb from 
> >> Xcode's console. This doesn't work when typing `lldb` into the terminal 
> >> and using it from there. I assumed the two were the same.
> >
> > The same underlying debugger is used in both cases.  There can be subtle 
> > reasons for differences in behavior in the different contexts, but I don’t 
> > see how they’d apply here.  Let’s get to a specific scenario and ensure 
> > that we can resolve that for you.
> >
> >> On a separate note, --top-level doesn't seem to work for swift (from Xcode 
> >> console lldb). We need it to work with swift for the scripts we'll be 
> >> writing.
> >> (lldb) expr -l swift --top-level -- let i = 10
> >>
> >> expr -l swift --top-level -- let a = i
> >>
> >> error: :3:9: error: use of unresolved identifier 'i'
> >>
> > The --top-level option isn’t meaningful for Swift, so it’s completely 
> > ignored.  The less ambiguous nature of the language allows us to 
> > automatically determine what are top-level constructs and what’s intended 
> > to be evaluated in scope.  We introduced --top-level for Objective-C / C++ 
> > primarily to enable declaring functions and anything else that literally 
> > cannot be written in a local scope.
> >
> > In your particular example the reason you can’t refer to “i” is completely 
> > unrelated.  Conceptually, every expression you evaluate is wrapped in its 
> > own scope.  So your two subsequent expressions act like this construct :
> >
> > do {
> > let i = 10
> > }
> > do {
> > let a = i
> > }
> >
> > As you can see, “i” is defined in this expression scope and then goes out 
> > of scope immediately after execution.  This is useful when you want to 
> > write a multi-line expression that introduces declarations for immediate 
> > use without having them cluttering up your namespace afterwards.  The 
> > convention used by LLDB for any declaration that you intend to use in later 
> > expressions is to prefix the name with a dollar sign.  So you can do the 
> > following:
> >
> > (lldb) expr -l swift -- let $i = 10
> > (lldb) expr -l swift -- let $a = i
> >
> > … and both “$a” and “$i" will be available in subsequent expressions.
> >
> > Kate Stone k8st...@apple.com
> >  Xcode Low Level Tools
> >
> >> On Wed, 

Re: [lldb-dev] --top-level doesn't work in lldb for Objective-C or Swift :(

[Jim Ingham via lldb-dev]

You would have to be really careful about using "debugger variables" whose name 
is not decorated with a "$".  After all, this is introducing a global variable, 
which will be shadowed by local variables, ivars, file statics for the current 
frame's CU, etc.  So using the code you've added at various stop points in the 
debugging session will be fragile.  That's the primary reason that we don't 
encourage defining debugger variables in the common identifier namespace of 
your program.

Jim



> On Oct 5, 2016, at 11:41 AM, Rex Fenley  wrote:
> 
> Hey Kate! Thanks for all this info, it's really helpful :)
> 
> We'd like to have more complex expressions being used from the debugger. Some 
> of this would be code written in separate files. It will be difficult or at 
> least very tedious to have all our code use "$", is there a way to void using 
> "$"? Is there an option we could add to lldb to avoid using "$" and still 
> have variables and data-structures globally accessible? I notice that within 
> "repl" "$" it's not necessary to use any "$" variables, is there a way to 
> elevate the logic "repl" uses into expr?
> 
> On Wed, Oct 5, 2016 at 11:29 AM, Kate Stone  wrote:
>> On Oct 5, 2016, at 10:14 AM, Rex Fenley via lldb-dev 
>>  wrote:
>> 
>> Maybe I have that incorrectly, this does seem to work when using lldb from 
>> Xcode's console. This doesn't work when typing `lldb` into the terminal and 
>> using it from there. I assumed the two were the same.
> 
> The same underlying debugger is used in both cases.  There can be subtle 
> reasons for differences in behavior in the different contexts, but I don’t 
> see how they’d apply here.  Let’s get to a specific scenario and ensure that 
> we can resolve that for you.
> 
>> On a separate note, --top-level doesn't seem to work for swift (from Xcode 
>> console lldb). We need it to work with swift for the scripts we'll be 
>> writing.
>> (lldb) expr -l swift --top-level -- let i = 10
>> 
>> expr -l swift --top-level -- let a = i
>> 
>> error: :3:9: error: use of unresolved identifier 'i'
>> 
> The --top-level option isn’t meaningful for Swift, so it’s completely 
> ignored.  The less ambiguous nature of the language allows us to 
> automatically determine what are top-level constructs and what’s intended to 
> be evaluated in scope.  We introduced --top-level for Objective-C / C++ 
> primarily to enable declaring functions and anything else that literally 
> cannot be written in a local scope.
> 
> In your particular example the reason you can’t refer to “i” is completely 
> unrelated.  Conceptually, every expression you evaluate is wrapped in its own 
> scope.  So your two subsequent expressions act like this construct :
> 
> do {
> let i = 10
> }
> do {
> let a = i
> }
> 
> As you can see, “i” is defined in this expression scope and then goes out of 
> scope immediately after execution.  This is useful when you want to write a 
> multi-line expression that introduces declarations for immediate use without 
> having them cluttering up your namespace afterwards.  The convention used by 
> LLDB for any declaration that you intend to use in later expressions is to 
> prefix the name with a dollar sign.  So you can do the following:
> 
> (lldb) expr -l swift -- let $i = 10
> (lldb) expr -l swift -- let $a = i
> 
> … and both “$a” and “$i" will be available in subsequent expressions.
> 
> Kate Stone k8st...@apple.com
>  Xcode Low Level Tools
> 
>> On Wed, Oct 5, 2016 at 10:06 AM, Rex Fenley  wrote:
>> Jim,
>> 
>> That doesn't seem to work for us. We're using lldb packaged with Xcode 8 fyi.
>> (lldb) expr --top-level -- NSString *string = [NSString 
>> stringWithUTF8String: "This is a string"];
>> 
>> 
>> 
>> ; Function Attrs: nounwind
>> 
>> define internal void @_GLOBAL__sub_I__null_() #0 section 
>> "__TEXT,__StaticInit,regular,pure_instructions" {
>> 
>>   call void @__cxx_global_var_init()
>> 
>>   ret void
>> 
>> }
>> 
>> 
>> On Tue, Oct 4, 2016 at 4:09 PM, Jim Ingham  wrote:
>> This isn't an issue with ObjC support in general, but rather shows that ObjC 
>> string constants are odd beasts.  You can work around this pretty easily by 
>> making dynamic strings:
>> 
>> (lldb) expr --top-level -- NSString *string = [NSString 
>> stringWithUTF8String: "This is a string"];
>> (lldb) expr string
>> (__NSCFString *) $0 = 0x0001002001b0 @"This is a string"
>> 
>> Please file a bug about the problem with ObjC constant strings.
>> 
>> Jim
>> 
>> 
>> > On Oct 4, 2016, at 3:57 PM, Rex Fenley via lldb-dev 
>> >  wrote:
>> >
>> > Hey lldb team!
>> >
>> > I'm trying to use `expr --top-level` from lldb in Xcode but it throws 
>> > errors like the following:
>> >
>> > (lldb) expression --top-level -- NSString *str = @"This is a string";
>> > Error [IRForTarget]: Couldn't replace an Objective-C constant string with 
>> > a dynamic string

Re: [lldb-dev] OverflowError: in method 'SBProcess_ReadPointerFromMemory', argument 2 of type 'lldb::addr_t'

[Jim Ingham via lldb-dev]

You passed an error into ReadPointerFromMemory.  In the cases where you aren't 
getting what you expect, what does that error say?

Jim

> On Sep 16, 2016, at 5:06 PM, Lei Kong via lldb-dev  
> wrote:
> 
> I ran into the error in the subject when running a python script with "script 
> myfile.myscript()".
>  
> The value addr_t parameter used is 0x01223f68, the following works 
> fine:
> 
> (lldb) scr
> Python Interactive Interpreter. To exit, type 'quit()', 'exit()' or Ctrl-D.
> >>> e = lldb.SBError()
> >>> ptr = lldb.process.ReadPointerFromMemory(0x01223f68, e)
> >>> print ptr
> 0
> >>> 
>  
> Any suggestion how to further investigate? Thanks.
>  
> myfile.myscript() calls the following function in a loop (iterate through all 
> vtable symbols), which contains the call ReadPointerFromMemory.
>  
> def dump_vtbl(vtableAddr) :
> error = lldb.SBError()
> vtableEndAddr = lldb.process.ReadPointerFromMemory(vtableAddr+8, error)
> if not error.success :
> return False
> print "vtable: [%0.16x, %0.16x)" % (vtableAddr, vtableEndAddr)
> for addr in range(vtableAddr, vtableEndAddr, 8) :
> print "read from address %.016x" % addr
> try:
> funcAddr = lldb.process.ReadPointerFromMemory(addr, error)
> except:
> sys.exc_clear()
> continue
> if not error.success :
> continue
> 
> ___
> 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] running lldb-mi with LLDB_DISABLE_PYTHON

[Jim Ingham via lldb-dev]

If you use the MI, that assumes that the server process is the one doing most 
of the work.  lldb is not meant to be a light-weight program, and if you start 
feeding it a lot of symbol information you may find it taking up too many 
resources to really want to run it on your device.   For device debugging, it 
is more efficient to run lldb-server or some other monitor that speaks the 
gdb-remote protocol on the device and then run lldb on the host.  The 
gdb-remote servers can be much more efficient since they don't directly deal 
with debug or symbol information.  We've done a lot of work both for iOS and 
for Android to make lldb's handling of this way of debugging efficient.  The 
changes we made to the gdb-remote protocol to support this work are documented 
in docs/lldb-gdb-remote.txt, though lldb will also run correctly with a vanilla 
gdb-remote server.

Jim

> On Sep 20, 2016, at 12:57 AM, Chunseok Lee via lldb-dev 
>  wrote:
> 
> Dear lldb dev team,
> 
> I am working on running lldb-mi on arm32 device(like rpi) for remote 
> debugging usage.
> Is there any way to run lldb-mi with python disabled ?
> When building lldb with LLDB_DISABLE_PYTHON, it seems that dataformatter 
> initialization is failed due to the following code in 
> MICmnLLDBDebugger.cpp:59   
> 
> //++
> //
> // MI summary helper routines
> static inline bool MI_add_summary(lldb::SBTypeCategory category,
>   const char *typeName,
>   lldb::SBTypeSummary::FormatCallback cb,
>   uint32_t options, bool regex = false) {
> #if defined(LLDB_DISABLE_PYTHON)
>   return false;
> #else
>   lldb::SBTypeSummary summary =
>   lldb::SBTypeSummary::CreateWithCallback(cb, options);
>   return summary.IsValid()
>  ? category.AddTypeSummary(
>lldb::SBTypeNameSpecifier(typeName, regex), summary)
>  : false;
> #endif
> }
> 
> Thank you.
> 
> BR,
> Chunseok Lee
> 
> -- 
> Where Do We come from? What Are We? Where Are We Going?
> ___
> 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 Evolution - Final Form

[Jim Ingham via lldb-dev]

> On Sep 19, 2016, at 3:32 PM, Zachary Turner  wrote:
> 
> Ok, in that case I agree with you more.  We should test the scripting 
> interface.  It's part of the software, it should be treated as such.  100% on 
> board.  But if we find that it is lacking (or even just inconvenient) to test 
> the full capabilities of the debugger, we shouldn't force it to.

I would make an even stronger statement.  As lldb developers, if there's 
something we want to do and it isn't available, we go add it to lldb_private, 
and maybe wire it up to a command so we can use it.  That's the path of least 
resistance.  If it weren't for writing the testsuite using the SB API's, we 
wouldn't tend to write much code using it ourselves.  Writing test cases for 
the Python API in the testsuite is a nice forcing function to get US using the 
SB API's to solve actual problems.  So where reasonable, I think we actually 
SHOULD force ourselves to use it.

There are some things it is annoying to test from the outside, particularly 
small utility functions that you need to test error cases and the like that 
it's just hard to get the actual debugger to generate reliably.  Those are 
great candidates for white box type unit testing.  But the full capabilities of 
the debugger should either be available through the SB API's or they really 
aren't doing anybody any good.  So if the SB API's are not up to revealing the 
full capabilities of the debugger, we need to fix that, not fall back on using 
stuff only lldb developers can have access just so we can get our tests written 
more quickly.

Jim


> 
> All of our tests right now are full-scale integration tests.  Integration 
> tests are certainly helpful, but they aren't the entire world.  And they 
> shouldn't even be a first line of defense, but rather a 3rd or 4th line of 
> defense due to how general they are.  Like the example I gave earlier about 
> TestSigned and TestUnsigned on Windows, where one was failing and one was 
> passing, and the reason had nothing to do with signedness.  
> 
> On Mon, Sep 19, 2016 at 3:24 PM Jim Ingham  wrote:
> 
> > On Sep 19, 2016, at 3:19 PM, Zachary Turner  wrote:
> >
> > Obviously I defer to you on whether testing via the SB API is better than 
> > what GDB does or used to do.  But these are not the only two systems in the 
> > world.  Having used both LLDB and LLVM's test suite extensively, I still 
> > remain unconvinced that LLDB's testing situation could not be improved.  Do 
> > we improve it by doing what GDB did?  Obviously not.  Can we improve it 
> > further by doing something completely different than what GDB did *and* 
> > what LLDB currently does?  I remain convinced that we can.
> 
> I think you misread my message.  I said:
> 
> Having a Python interface so that developers can program the debugger is very 
> powerful.
> 
> As evidence, see all the work the gdb folks did to add one (you have to know 
> a little bit about how gdb works to see how hard this would be, but you can 
> imagine a debugger written in C primarily to dump text to a terminal, think 
> of how you would wrap that in Python and you'll get a sense.)
> 
> Now forget about gdb, that was only an example of how much some folks thought 
> a scripting interface was worth.
> 
> Instead, focus on this good thing, the scripting interface.  We should test 
> this thing that we think is valuable.
> 
> What's a good way to make sure we test that?
> 
> USE IT FOR TESTING.
> 
> Jim
> 
> 
> >
> >
> > On Mon, Sep 19, 2016 at 3:07 PM Jim Ingham  wrote:
> >
> > > On Sep 19, 2016, at 2:11 PM, Zachary Turner via lldb-dev 
> > >  wrote:
> > >
> > >
> > >
> > > On Mon, Sep 19, 2016 at 2:02 PM Greg Clayton  wrote:
> > >
> > > >   • Separate testing tools
> > > >   • One question that remains open is how to 
> > > > represent the complicated needs of a debugger in lit tests.  Part a) 
> > > > above covers the trivial cases, but what about the difficult cases?  In 
> > > > https://reviews.llvm.org/D24591 a number of ideas were discussed.  We 
> > > > started getting to this idea towards the end, about a separate tool 
> > > > which has an interface independent of the command line interface and 
> > > > which can be used to test.  lldb-mi was mentioned.  While I have 
> > > > serious concerns about lldb-mi due to its poorly written and tested 
> > > > codebase, I do agree in principle with the methodology.  In fact, this 
> > > > is the entire philosophy behind lit as used with LLVM, clang, lld, etc.
> > >
> > > We have a public API... Why are we going to go and spend _any_ time on 
> > > doing anything else? I just don't get it. What a waste of time. We have a 
> > > public API. Lets use it. Not simple enough for people? Tough. Testing a 
> > > debugger should be done using the public API except when we are actually 
> > > trying to test 

Re: [lldb-dev] LLDB Evolution - Final Form

[Jim Ingham via lldb-dev]

> On Sep 19, 2016, at 3:19 PM, Zachary Turner  wrote:
> 
> Obviously I defer to you on whether testing via the SB API is better than 
> what GDB does or used to do.  But these are not the only two systems in the 
> world.  Having used both LLDB and LLVM's test suite extensively, I still 
> remain unconvinced that LLDB's testing situation could not be improved.  Do 
> we improve it by doing what GDB did?  Obviously not.  Can we improve it 
> further by doing something completely different than what GDB did *and* what 
> LLDB currently does?  I remain convinced that we can.

I think you misread my message.  I said:

Having a Python interface so that developers can program the debugger is very 
powerful.

As evidence, see all the work the gdb folks did to add one (you have to know a 
little bit about how gdb works to see how hard this would be, but you can 
imagine a debugger written in C primarily to dump text to a terminal, think of 
how you would wrap that in Python and you'll get a sense.)

Now forget about gdb, that was only an example of how much some folks thought a 
scripting interface was worth.

Instead, focus on this good thing, the scripting interface.  We should test 
this thing that we think is valuable.

What's a good way to make sure we test that?

USE IT FOR TESTING.

Jim


> 
> 
> On Mon, Sep 19, 2016 at 3:07 PM Jim Ingham  wrote:
> 
> > On Sep 19, 2016, at 2:11 PM, Zachary Turner via lldb-dev 
> >  wrote:
> >
> >
> >
> > On Mon, Sep 19, 2016 at 2:02 PM Greg Clayton  wrote:
> >
> > >   • Separate testing tools
> > >   • One question that remains open is how to 
> > > represent the complicated needs of a debugger in lit tests.  Part a) 
> > > above covers the trivial cases, but what about the difficult cases?  In 
> > > https://reviews.llvm.org/D24591 a number of ideas were discussed.  We 
> > > started getting to this idea towards the end, about a separate tool which 
> > > has an interface independent of the command line interface and which can 
> > > be used to test.  lldb-mi was mentioned.  While I have serious concerns 
> > > about lldb-mi due to its poorly written and tested codebase, I do agree 
> > > in principle with the methodology.  In fact, this is the entire 
> > > philosophy behind lit as used with LLVM, clang, lld, etc.
> >
> > We have a public API... Why are we going to go and spend _any_ time on 
> > doing anything else? I just don't get it. What a waste of time. We have a 
> > public API. Lets use it. Not simple enough for people? Tough. Testing a 
> > debugger should be done using the public API except when we are actually 
> > trying to test the LLDB command line in pexpect like tests. Those and only 
> > those are fine to covert over to using LIT and use text scraping. But 95% 
> > of our testing should be done using the API that our IDEs use. Using MI? 
> > Please no.
> >
> > FWIW, I agree with you about mi.
> >
> > That said, the public api is problematic.  Here you've got an API which, 
> > once you do something to, is set in stone forever.  And yet in order to 
> > test something, you have to add it to the API.  So now, in order to test 
> > something, you have to make a permanent change to a public API that can 
> > never be undone.
> >
> > It's also a public facing API, when a lot of the stuff  we need to be able 
> > to look at and inspect is not really suitable for public consumption.
> >
> > If something is a public API that can never be changed once it's added, 
> > then there should be an extremely strict review process in order to add 
> > something to it.  It should be VERY HARD to modify (it's currently not, 
> > which is a debate for another day, but anyway...).  And yet that's 
> > fundamentally incompatible with having tests be easy to write.  When it's 
> > hard to add the thing you need to add in order to write the test, then it's 
> > hard to write the test.
> >
> > Furthermore, with a system such as the one I proposed, you could even run 
> > tests with LLDB_DISABLE_PYTHON.  IDK about you, but that would be *amazing* 
> > from my point of view.  Even though I spent months making Python 3 work, I 
> > would be happy to burn it all with fire and go back to just Python 2 if we 
> > had a viable testing strategy.
> 
> It would not be amazing.  One of the primary benefits of lldb IS the Python 
> API.  If you don't think that's wonderful in a debugger, go look at what 
> effort it took to make that happen in gdb once lldb started providing it and 
> you'll see that it was really highly motivated.  So switching our testing 
> away from one of our very strong points would be a very bad choice IMHO.
> 
> On the "should I add it to the SB API to test it or not question."  Most of 
> the time, when I find I need to add an API in order write a test for 
> something, the thing I'm trying to get my hands on is something that other 
> people might 

Re: [lldb-dev] Passing std::atomics by value

[Jim Ingham via lldb-dev]

> On Aug 26, 2016, at 11:44 AM, Adrian McCarthy via lldb-dev 
>  wrote:
> 
> Methods like Address::SetOffset and Address::Slide seem to have data races 
> despite m_offset being atomic.  Callers of those methods would have to 
> guarantee that nothing else is trying to write to m_offset.  And if they're 
> doing that, then there doesn't appear to be a need for std::atomic on that 
> field.
> 
> BTW, I propose we move the member variables from protected to private.  As 
> far as I can tell, there aren't any derived classes (yet), at least none that 
> access those members.  If we need to add a mutex to the class itself, it'll 
> be better if any future derived classes access the data through accessors.

That seems fine to me.  We haven't needed to subclass it in years, and probably 
won't.

Jim


> 
> On Fri, Aug 26, 2016 at 11:36 AM, Zachary Turner via lldb-dev 
>  wrote:
> The thing is, the code is already full of data races.  I think the 
> std::atomic is actually used incorrectly and is not even doing anything.
> 
> That said, consider darwin on 32-bit, where I believe each stack frame is 
> 4-byte aligned.  I dont' think there's any way the compiler can guarantee 
> that a function parameter is 8-byte aligned without allocating from the heap, 
> which is obviously impossible for a stack variable.
> 
> On Fri, Aug 26, 2016 at 11:29 AM Greg Clayton  wrote:
> 
> > On Aug 26, 2016, at 11:24 AM, Greg Clayton via lldb-dev 
> >  wrote:
> >
> >>
> >> On Aug 26, 2016, at 10:51 AM, Zachary Turner via lldb-dev 
> >>  wrote:
> >>
> >> I recently updated to Visual Studio 2015 Update 3, which has improved its 
> >> diagnostics.  As a result of this, LLDB is uncompilable due to a slew of 
> >> errors of the following nature:
> >>
> >> D:\src\llvm\tools\lldb\include\lldb/Target/Process.h(3256): error C2719: 
> >> 'default_stop_addr': formal parameter with requested alignment of 8 won't 
> >> be aligned
> >>
> >> The issue comes down to the fact that lldb::Address contains a 
> >> std::atomic, and is being passed by value pervasively throughout 
> >> the codebase.  There is no way to guarantee that this value is 8 byte 
> >> aligned.  This has always been a bug, but until now the compiler just 
> >> hasn't been reporting it.
> >>
> >> Someone correct me if I'm wrong, but I believe this is a problem on any 
> >> 32-bit platform, and MSVC is just the only one erroring.
> >>
> >> I'm not really sure what to do about this.  Passing std::atomic's 
> >> by value seems wrong to me.
> >>
> >> Looking at the code, I don't even know why it needs to be atomic.  It's 
> >> not even being used safely.  We'll have a single function write the value 
> >> and later read the value, even though it could have been used in the 
> >> meantime. Maybe what is really intended is a mutex.  Or maybe it doesn't 
> >> need to be atomic in the first place.
> >>
> >> Does anyone have a suggestion on what to do about this?  I'm currently 
> >> blocked on this as I can't compile LLDB.
> >
> > Feel free to #ifdef around the m_offset member of Address and you can have 
> > the data race and compile. This seems like a compiler bug to me. If a 
> > struct/classe by value argument has alignment requirements, then the 
> > compiler should handle this correctly IMHO. Am I wrong
> 
> Or if this isn't a compiler bug, feel free to modify anything that was 
> passing Address by value and make it a "const Address &".
> 
> ___
> 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] Passing std::atomics by value

[Jim Ingham via lldb-dev]

> On Aug 26, 2016, at 11:36 AM, Zachary Turner via lldb-dev 
>  wrote:
> 
> The thing is, the code is already full of data races.  I think the 
> std::atomic is actually used incorrectly and is not even doing anything.
> 
> That said, consider darwin on 32-bit, where I believe each stack frame is 
> 4-byte aligned.  I dont' think there's any way the compiler can guarantee 
> that a function parameter is 8-byte aligned without allocating from the heap, 
> which is obviously impossible for a stack variable.

Why can't the compiler pad the argument slot on the stack so that the actual 
struct lives at a properly aligned location?  It's copying the value into the 
callee's stack frame, so it can put it wherever it wants.  And both caller and 
callee sites know the alignment requirements from the function signature, so 
they can both figure out where the actual struct lives in the argument slot 
based on the alignment of the stack slot.

Jim


> 
> On Fri, Aug 26, 2016 at 11:29 AM Greg Clayton  wrote:
> 
> > On Aug 26, 2016, at 11:24 AM, Greg Clayton via lldb-dev 
> >  wrote:
> >
> >>
> >> On Aug 26, 2016, at 10:51 AM, Zachary Turner via lldb-dev 
> >>  wrote:
> >>
> >> I recently updated to Visual Studio 2015 Update 3, which has improved its 
> >> diagnostics.  As a result of this, LLDB is uncompilable due to a slew of 
> >> errors of the following nature:
> >>
> >> D:\src\llvm\tools\lldb\include\lldb/Target/Process.h(3256): error C2719: 
> >> 'default_stop_addr': formal parameter with requested alignment of 8 won't 
> >> be aligned
> >>
> >> The issue comes down to the fact that lldb::Address contains a 
> >> std::atomic, and is being passed by value pervasively throughout 
> >> the codebase.  There is no way to guarantee that this value is 8 byte 
> >> aligned.  This has always been a bug, but until now the compiler just 
> >> hasn't been reporting it.
> >>
> >> Someone correct me if I'm wrong, but I believe this is a problem on any 
> >> 32-bit platform, and MSVC is just the only one erroring.
> >>
> >> I'm not really sure what to do about this.  Passing std::atomic's 
> >> by value seems wrong to me.
> >>
> >> Looking at the code, I don't even know why it needs to be atomic.  It's 
> >> not even being used safely.  We'll have a single function write the value 
> >> and later read the value, even though it could have been used in the 
> >> meantime. Maybe what is really intended is a mutex.  Or maybe it doesn't 
> >> need to be atomic in the first place.
> >>
> >> Does anyone have a suggestion on what to do about this?  I'm currently 
> >> blocked on this as I can't compile LLDB.
> >
> > Feel free to #ifdef around the m_offset member of Address and you can have 
> > the data race and compile. This seems like a compiler bug to me. If a 
> > struct/classe by value argument has alignment requirements, then the 
> > compiler should handle this correctly IMHO. Am I wrong
> 
> Or if this isn't a compiler bug, feel free to modify anything that was 
> passing Address by value and make it a "const Address &".
> ___
> 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] Passing std::atomics by value

[Jim Ingham via lldb-dev]

That seems to me a compiler bug, not: "You can't pass structures with 
std::atomic" elements in them by value.  It would crazy to add a type to the 
C++ language that you couldn't use everywhere.  There doesn't seem to be any 
official restriction.  And anecdotally there's a reference to the problem in 
gcc for PPC (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62259) but that was 
considered a bug and fixed.

Not that it matters much, you are stuck with the compiler you're stuck with, 
bugs and all.

Jim

> On Aug 26, 2016, at 12:26 PM, Zachary Turner  wrote:
> 
> It could, in theory, it just doesn't.  I compiled a quick program using 
> i686-darwin as the target and the generated assembly makes no attempt to pad 
> the arguments.
> 
> I'll post some code later
> 
> On Fri, Aug 26, 2016 at 11:42 AM Jim Ingham  wrote:
> 
> > On Aug 26, 2016, at 11:36 AM, Zachary Turner via lldb-dev 
> >  wrote:
> >
> > The thing is, the code is already full of data races.  I think the 
> > std::atomic is actually used incorrectly and is not even doing anything.
> >
> > That said, consider darwin on 32-bit, where I believe each stack frame is 
> > 4-byte aligned.  I dont' think there's any way the compiler can guarantee 
> > that a function parameter is 8-byte aligned without allocating from the 
> > heap, which is obviously impossible for a stack variable.
> 
> Why can't the compiler pad the argument slot on the stack so that the actual 
> struct lives at a properly aligned location?  It's copying the value into the 
> callee's stack frame, so it can put it wherever it wants.  And both caller 
> and callee sites know the alignment requirements from the function signature, 
> so they can both figure out where the actual struct lives in the argument 
> slot based on the alignment of the stack slot.
> 
> Jim
> 
> 
> >
> > On Fri, Aug 26, 2016 at 11:29 AM Greg Clayton  wrote:
> >
> > > On Aug 26, 2016, at 11:24 AM, Greg Clayton via lldb-dev 
> > >  wrote:
> > >
> > >>
> > >> On Aug 26, 2016, at 10:51 AM, Zachary Turner via lldb-dev 
> > >>  wrote:
> > >>
> > >> I recently updated to Visual Studio 2015 Update 3, which has improved 
> > >> its diagnostics.  As a result of this, LLDB is uncompilable due to a 
> > >> slew of errors of the following nature:
> > >>
> > >> D:\src\llvm\tools\lldb\include\lldb/Target/Process.h(3256): error C2719: 
> > >> 'default_stop_addr': formal parameter with requested alignment of 8 
> > >> won't be aligned
> > >>
> > >> The issue comes down to the fact that lldb::Address contains a 
> > >> std::atomic, and is being passed by value pervasively 
> > >> throughout the codebase.  There is no way to guarantee that this value 
> > >> is 8 byte aligned.  This has always been a bug, but until now the 
> > >> compiler just hasn't been reporting it.
> > >>
> > >> Someone correct me if I'm wrong, but I believe this is a problem on any 
> > >> 32-bit platform, and MSVC is just the only one erroring.
> > >>
> > >> I'm not really sure what to do about this.  Passing 
> > >> std::atomic's by value seems wrong to me.
> > >>
> > >> Looking at the code, I don't even know why it needs to be atomic.  It's 
> > >> not even being used safely.  We'll have a single function write the 
> > >> value and later read the value, even though it could have been used in 
> > >> the meantime. Maybe what is really intended is a mutex.  Or maybe it 
> > >> doesn't need to be atomic in the first place.
> > >>
> > >> Does anyone have a suggestion on what to do about this?  I'm currently 
> > >> blocked on this as I can't compile LLDB.
> > >
> > > Feel free to #ifdef around the m_offset member of Address and you can 
> > > have the data race and compile. This seems like a compiler bug to me. If 
> > > a struct/classe by value argument has alignment requirements, then the 
> > > compiler should handle this correctly IMHO. Am I wrong
> >
> > Or if this isn't a compiler bug, feel free to modify anything that was 
> > passing Address by value and make it a "const Address &".
> > ___
> > 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] RFC: Break/Watchpoint refactor

[Jim Ingham via lldb-dev]

> On Sep 27, 2016, at 1:09 PM, Daniel Austin Noland via lldb-dev 
>  wrote:
> 
> I have been giving study to the private and public classes for 
> break/watchpoints and I have some ideas for how to improve them.  I am 
> looking for comments from the community on this now to avoid wasted work and 
> invite suggestion for improvements and any objections you may have.
> 
> Some problems with things as they stand:
> 
> 1. The Watchpoint and SBWatchpoint classes share very little implementation 
> with the Breakpoint and SBBreakpoint classes.  Both Breakpoint and Watchpoint 
> inherit from Stoppoint, but that class provides very little functionality and 
> not much of an interface. This is both a waste and a potential hazard (in the 
> sense that we run the risk of allowing breakpoints and watchpoints to evolve 
> in parallel thus complicating the API and making things more difficult to 
> merge later).
> 2. The SBWatchpoint class lacks feature parity with SBBreakpoint (e.g. no 
> callback implementation in SBWatchpoint).

The main problem here is that Watchpoints & Breakpoints should share the 
Options class, and most of the StopInfo DoOnRemoval.  I don’t think you’ll need 
to write a lot of new code to do this, it’s mostly ripping out the 
WatchpointOptions, using BreakpointOptions instead adapting as necessary.  
Ditto for the StopInfo{Watchpoint,Breakpoint}.

> 3. The Breakpoint class has grown an ecosystem of support classes which are 
> unnecessarily specific to it.  For example, I don't see a huge reason to 
> maintain a totally distinct implementation for BreakpointList and 
> WatchpointList.
> 4. All of these classes are "old school" (not necessarily bad, but 
> potentially a problem).  For example:
>  a. lots of const char* running around.
>  b. DISALLOW_COPY_AND_ASSIGN(BreakpointEventData) to make ctors and such 
> private rather than using ctor() = delete (which provides better compiler 
> errors)
>  c. use of Error& args in function signatures as opposed to 
> Expected.

This should not be done piecemeal.  If we decide to change how we do error 
reporting in lldb, that should be done consistently throughout.

>  d. callback implementation uses function pointers (an ever confusing topic, 
> especially for new programmers) where I think we could use templated methods 
> (or just a parent Callback class) to significant effect.

Folks on the outside of the SB API’s need to be able to pass callbacks in.  We 
don’t currently have any templates you need to instantiate or classes you need 
to override to go from outside the SB API to inside it.  So whatever happens on 
the lldb_private side, for the SB API’s we’ll probably have to stick with void 
* & function pointers.

> 5. Confusing or simply wrong documentation (e.g. 
> Breakpoint::ResolveBreakpointInModules has arguments marked as @param[in] 
> when the description of those arguments clearly indicates that they will be 
> the output of the function).
> 6. We simply don't have a Finishpoint class (triggers callback at the 
> conclusion of the function or scope)
> 
> My plan:
> 
> I would like to refactor this in a few phases.
> 
> Phase 1: Low hanging fruit
> --
> 
> * Kick as much functionality as is reasonable from Breakpoint up to 
> Stoppoint.  At a minimum I would expand the Stoppoint API to include features 
> which should logically be available to Breakpoint, Watchpoint, a hypothetical 
> Finishpoint, and any future *point class.  I would also try to refactor the 
> Breakpoint support classes (e.g. BreakpointID) to derive from a new class 
> (i.e. StoppointID) and kick functionality up the chain there as well.  This 
> would include methods like GetDescription, SetOptions, GetOptions, AddName, 
> and so on.

Again, most of the overlap isn’t actually in the breakpoint and watchpoint 
classes, but in the Options classes.  After all, the setting of watchpoints and 
breakpoints are very different, but that they have conditions and callbacks are 
very similar.  Keeping the setting part separate and sharing the reaction to 
hitting the stop points seems to more closely model the objects better.

> 
> * Review and clean the source docs
> 
> * Expand test coverage where that seems easy (perhaps there are tests hiding 
> somewhere I didn't see?)

test/testcases/functionalities/breakpoint

There are lots of tests there, but feel free to add tests as you go.

> 
> I would try to break private APIs minimally if at all.  SB api will not be 
> broken.
> 
> This should go a long ways toward resolving problems 1, 2, 3, and 5.
> 
> Phase 2: Restructure / Modernize the Private API / Implementation
> -
> 
> * Change Error& out parameters to Expected.

Again, this is a larger policy change.  We shouldn’t make different sections of 
lldb handle errors differently.

> * Get rid of all the const char* vars / args in favor of a better string type 
> 

Re: [lldb-dev] RFC: Break/Watchpoint refactor

[Jim Ingham via lldb-dev]

> On Sep 27, 2016, at 2:23 PM, Zachary Turner via lldb-dev 
>  wrote:
> 
> 
> 
> 
> On Tue, Sep 27, 2016 at 1:09 PM Daniel Austin Noland via lldb-dev 
> > wrote:
> 4. All of these classes are "old school" (not necessarily bad, but
> potentially a problem).  For example:
>a. lots of const char* running around.
> We should use llvm::StringRef here.
>  
>b. DISALLOW_COPY_AND_ASSIGN(BreakpointEventData) to make ctors and
> such private rather than using ctor() = delete (which provides better
> compiler errors)
>c. use of Error& args in function signatures as opposed to
> Expected.
> LLDB already has its own class called Error, and it makes it confusing if 
> we're going to be using llvm::Error as well.  In an earlier thread I proposed 
> changing lldb::Error to LLDBError for exactly this reason.  I would suggest 
> doing this first.

I don’t think we want different parts of lldb handling errors differently.  
That would be even more confusing.

>  
>d. callback implementation uses function pointers (an ever confusing
> topic, especially for new programmers) where I think we could use
> templated methods (or just a parent Callback class) to significant effect.
> We should consider using llvm::function_ref<> here.
> 
> More details on each of these below.
>  
> 
> Phase 2: Restructure / Modernize the Private API / Implementation
> -
> 
> * Change Error& out parameters to Expected.
> As mentioned, we should rename lldb::Error first so as to avoid naming 
> conflicts with llvm.  Granted, they are each in their own namespace, but 
> still, it will lead to confusion, and prevents the use of "using namespace 
> llvm;" as it currently stands.
>  
> * Get rid of all the const char* vars / args in favor of a better string
> type (which?)
> llvm::StringRef.  Anyone returning a const char* is saying they don't own the 
> backing memory.  That's exactly what a StringRef is for, but it has many 
> other benefits such as very efficient searching, substring, and parsing 
> methods.  
>  
> * Prefer explicitly deleted copy ctor / assignments over multiline macro
> DISALLOW_COPY_AND_ASSIGN
> * Try to reduce the (perhaps excessive) use of friendship between the
> support classes.  For instance, is it necessary to give
> BreakpointLocation access to private data members from
> BreakpointLocationList, Process, BreakpointSite, and
> StopInfoBreakpoint?  Wouldn't it be better to expand the functionality
> of those other classes?
> 
> A more significant change could be a rewrite of the callback functionality.
> 
> There are some problems with the way callbacks are implemented in terms
> of maintainability and extensibility.  I think that using templates and
> simple inheritance we could shift to using callback objects instead of
> function pointers.  I have a crude code sketch of this plan in the works
> now, and I will submit that if there is interest in this idea.
> Essentially, the idea is to let the user define their own Breakpoint or
> Watchpoint (or whatever) child class which overrides a pure virtual run
> method from a parent StoppointCallback templated class.  The template
> parameter of StoppointCallback would allow us to define a
> std::unique_ptr member where the user can hang any data they
> want for the callback.  That saves us from void pointers (which I find
> very awkward).
> I'm not a huge fan of this.  Inheriting from Breakpoint or Watchpoint sounds 
> old school to me.  Implementation inheritance in general should be avoided 
> wherever possible IMO.  Also, you've mentioned that StoppointCallback would 
> only have a template argument, but it's possible that different types of 
> callback take completely incompatible types and numbers of arguments.  This 
> is something that can't be described by a single function with a template 
> parameter.
> 
> I think the canonical pattern for what you want here is "double dispatch".  
> You've got something like this:
> 
> struct CallbackArgs {
>   virtual void dispatch(StoppointBase ) = 0;
> };
> struct WatchpointArgs : public CallbackArgs {
> private:
>   int Old;
>   int New;
> public:
>   void dispatch(StoppointBase ) override {
> static_cast(point).Callback(Old, New);
>   };
> };
> 
> struct BreakpointArgs : public CallbackArgs {
> private:
>   int id;
> public:
>   void dispatch(StoppointBase ) override {
> static_cast(point).Callback(id);
>   }
> };
> 
> It's a little bit awkward though, so you can perhaps simplify this by making 
> use of llvm's casting infrastructure.  Check out llvm/include/Casting.h.  But 
> basically you could move all this dispatch logic into a single function that 
> looks like this:
> 
> if (auto wp = llvm::dyn_cast(stop_point)) {
>   wp->Callback( ... );
> } else if (auto bp = llvm::dyn_cast(stop_point)) {
>   

Re: [lldb-dev] RFC: Break/Watchpoint refactor

[Jim Ingham via lldb-dev]

> On Sep 27, 2016, at 2:55 PM, Daniel Austin Noland  
> wrote:
> 
>>> The main problem here is that Watchpoints & Breakpoints should share the 
>>> Options class, and most of the StopInfo DoOnRemoval.  I don’t think you’ll 
>>> need to write a lot of new code to do this, it’s mostly ripping out the 
>>> WatchpointOptions, using BreakpointOptions instead adapting as necessary.  
>>> Ditto for the StopInfo{Watchpoint,Breakpoint}.
>> So you would avoid inheritance and just make Watchpoint and Breakpoint take 
>> the same StoppointOptions class?
>>> 
> 

That is the way I would approach it.  The other half of this is 
StopInfoBreakpoint vrs. StopInfoWatchpoint classes.  These aren’t going to be 
exactly equivalent so you will probably have to find some way express what 
needs to be different, but those differences should be pretty small.  The 
Breakpoint side of this works pretty well, so I’d start from there.

Jim

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