Page MenuHomePhabricator
Feed Advanced Search

Today

jingham committed rGe337350be9d6: This is a refinement on 96601ec28b7efe5abf3479a1aa91bcedb235bbbd. The intent of… (authored by jingham).
This is a refinement on 96601ec28b7efe5abf3479a1aa91bcedb235bbbd. The intent of…
Fri, Jul 10, 11:12 AM
jingham closed D83450: Delegate UpdateChildrenPointerType to the Root ValueObject.
Fri, Jul 10, 11:12 AM · Restricted Project
jingham added a comment to D83450: Delegate UpdateChildrenPointerType to the Root ValueObject.

Right. It does bug me a little that this has no test, but I don't think it's the worst that could happen. And you're the one who's going to have to debug this all over again if the next value object change breaks swift again.

Fri, Jul 10, 10:23 AM · Restricted Project
jingham added a comment to D83446: [WIP][lldb/Reproducers] Synchronize the command interpreter with asynchronous events.

Seems like my thoughts got lost a bit with all the inline replies: we can solve this particular issue by making process connect block in synchronous mode. The fact that that's not happening today is a bug beyond the reproducers. I don't think we should change the current behavior in asynchronous mode. I think it's probably worthwhile to do that even if we decide to add extra synchronization for the reproducers in which case this would no longer be an example of a problem solved by the current patch.

I'm starting to understand why you say "process connect" is not blocking/synchronous. Although it is waiting for the "stopped" event to be sent to the public queue (here), it is not waiting for it to be processed by the public queue. The "process continue" command OTOH, is kind of waiting for the public queue processing to finish. I say only "kind of" because it does not actually process it on the _real_ public queue -- instead it "hijacks" the events and processes then on its own little event loop. The part that I got wrong was that I was assuming that the hijacked event loop would rebroadcast the stop event to the real public queue. In fact, it doesn't, which means that the stop event processing is completely finished by the time that the "process continue" command returns.

It seems reasonable that "process connect" (and it's SB equivalent) should behave the same way. This would also explain why so many of the "gdb-client" tests need to use lldbutil.expect_state_changes when connecting to the mock server, even though they are running in synchronous mode (the only other tests using this function explicitly choose to use the async mode).

For async mode, we can say that the user needs to ensure that the event is handled before he can issue other commands -- this is the same situation as with "process continue". Of course, in the asynch case, the reproducers are "the user" and they will need to do something about this. But maybe we don't need to cross that bridge right now?

Fri, Jul 10, 8:56 AM

Yesterday

jingham added a comment to D83433: Fix how we handle bit-fields for Objective-C when creating an AST.

IIRC from when Shafik and I were looking at this the ObjC runtime data lists the same offset for all the members of the bitfield: the offset of the first member of the bitfield. Apparently the ObjC runtime doesn't need to know where the individual members are dynamically - the offsets are baked into the code or something? So to find where the member actually is you have to take the offset into the field - which is given in the DWARF, and add it to the dynamic offset you get from the runtime for the first member.

Thu, Jul 9, 2:25 PM
jingham added a comment to D83446: [WIP][lldb/Reproducers] Synchronize the command interpreter with asynchronous events.

I want to be careful not to conflate lldb's general event behavior with the way the command interpreter happens to run things.

Thu, Jul 9, 1:46 PM
jingham added a comment to D83446: [WIP][lldb/Reproducers] Synchronize the command interpreter with asynchronous events.

I think the proper way to gate this sort of "race" is to use the process state. If the current process state is "stopped" then that means we're done with the stop processing and ready to allow commands that require the process to be stopped.

When I originally did this, the plan was that the the Public state would not be set to stopped until the stop event was consumed by the process listener. So if you tried to "continue" the process before the work to handle the stop event was done, you would see the state as "running" and the continue would not succeed.

However, that ran up against the problem that part of the "asynchronous" work that you might do on stop can involve running commands and SB API. Those need to see a public stop state or they won't work correctly. So the public state gets set to stopped too early, and then it's possible for this to be racy. IMO the solution to this problem should be for the Event Handler to be able to run its commands "as if" the public state were stopped, but everybody else who is trying to run commands will still see it as running. Then when the event handler is done with it's job, the process Public state is switched to stopped, and now commands coming from other sources will run in the stopped state.

How would that work with the reproducer issue? How would you prevent the command interpreter from processing the next command before the event handler thread issues the process info packet?

Thu, Jul 9, 1:36 PM
jingham added a comment to D83446: [WIP][lldb/Reproducers] Synchronize the command interpreter with asynchronous events.

I think the proper way to gate this sort of "race" is to use the process state. If the current process state is "stopped" then that means we're done with the stop processing and ready to allow commands that require the process to be stopped.

Thu, Jul 9, 11:54 AM
jingham added a comment to D83450: Delegate UpdateChildrenPointerType to the Root ValueObject.

I am not selling this as the correct long-term structure for ValueObjects. So far as I can see, in all cases it should be possible to tell a ValueObject where it's going to find both its own store and the storage for pointer children when the ValueObject is created. It's not like that's a feature we discover as we go through the process of creating the ValueObject. That isn't how it is currently done. Now we almost always start off an incorrect setting, and often goes through several rounds of resetting before it settles on the final value. That's what I meant by saying it is "frustratingly self-healing".

Thu, Jul 9, 10:24 AM · Restricted Project

Wed, Jul 8

Herald added a project to D83450: Delegate UpdateChildrenPointerType to the Root ValueObject: Restricted Project.
Wed, Jul 8, 7:51 PM · Restricted Project

Tue, Jul 7

jingham accepted D83327: [lldb/Core] Fix incomplete type variable dereferencing crash..

Other than a quibble about using _sp suffix, this is fine.

Tue, Jul 7, 11:33 AM · Restricted Project
jingham added a comment to D83327: [lldb/Core] Fix incomplete type variable dereferencing crash..

Aside from cosmetics, I'm not entirely sure this is the correct fix. Why are we calling this code _at all_ if the type is incomplete?

Tue, Jul 7, 11:05 AM · Restricted Project
jingham accepted D83306: [lldb/API] Overwrite variables with SBLaunchInfo::SetEnvironment(append=true).

This is fine. If there were a universal convention (e.g. : separated lists) for environment variables, it would be reasonable for "append" behavior to extend rather than replace extant variables, but in the absence of the universality of such a convention, the best we can do is overwrite.

Tue, Jul 7, 9:46 AM · Restricted Project

Tue, Jun 16

jingham added a comment to D81810: LLDB step-instruction gets stuck on jump to self.

Yes, I wasn't sure what the exact semantics were for step-inst for LLDB. I think the issue is not mainly the mimicking of GDB behavior, but rather that it is inconvenient for some use-cases.

To give some context on why I propose this change: the current behavior is pretty cumbersome when doing automated testing with LLDB of unknown/ generated programs. For example making use of the Python API, AFAIK, there is no interface where you can run a bounded number of instructions if lldb.SBThread.StepInstruction is not guaranteed to return (the current hack around it would be run this in a separate thread with a timeout).

Tue, Jun 16, 9:54 AM · Restricted Project

Mon, Jun 15

jingham added a comment to D81810: LLDB step-instruction gets stuck on jump to self.

Just to be clear, the lldb -> gdb command map doesn't prescribe behavior for lldb commands. It just suggests the analogous command in gdb. We are still free to implement lldb behavior however seems best to us.

Mon, Jun 15, 3:29 PM · Restricted Project

Thu, Jun 11

jingham accepted D80112: Check if thread was suspended during previous stop added..

LGTM

Thu, Jun 11, 11:32 AM · Restricted Project
jingham added a comment to D74136: [LLDB] WIP: Follow DW_AT_decl_file when setting breakpoint.

I need to read this in more detail at this point but I'm caught up in something else.

One of the not so great design decisions I made was to try to have "break set" be a single command governed by flags. The way the command turned out, there are some flags that tell you what kind of breakpoint you are setting, and then other flags that qualify that kind of search. But that means --file can mean "I'm specifying the file to use to set a file & line breakpoint" or it can be a narrowing specifier for a source regex or function name based breakpoint. Doing it this way makes it hard to have consistent meanings for the flags in all contexts.

If I had it to do over, I would make:

(lldb) break set source
(lldb) break set symbol
(lldb) break set source-pattern
(lldb) break set address

Thu, Jun 11, 9:53 AM · Restricted Project
jingham added a comment to D74136: [LLDB] WIP: Follow DW_AT_decl_file when setting breakpoint.

I need to read this in more detail at this point but I'm caught up in something else.

Thu, Jun 11, 9:53 AM · Restricted Project

Jun 10 2020

jingham accepted D81499: [Debugger] Use FileSystem instead of calling llvm::sys::fs::openFileForWrite directly..

LGTM then.

Jun 10 2020, 3:39 PM · Restricted Project
jingham added a comment to D81499: [Debugger] Use FileSystem instead of calling llvm::sys::fs::openFileForWrite directly..

This looks okay to me though I'm not very familiar with the llvm file system interfaces.

Jun 10 2020, 3:35 PM · Restricted Project
jingham added a comment to D80112: Check if thread was suspended during previous stop added..

Thanks, this is looking good. I have a bunch of nits, but nothing substantial.

Jun 10 2020, 3:35 PM · Restricted Project

Jun 8 2020

jingham added a comment to D80112: Check if thread was suspended during previous stop added..

I thought I was just repeating your original description of the problem in a scenario orchestrated by breakpoint actions. I must have missed something in your description if it's true that the scenario I described doesn't match your initial problem. But regardless, if there was a problem you should be able to actually drive lldb, either through the command-line or the SB API to the point of failure. And if so, you should be able to write a test that does the same thing.

Jun 8 2020, 4:39 PM · Restricted Project
jingham added a comment to D80112: Check if thread was suspended during previous stop added..

Humm... So you'll have to test the continue behavior instead, which after all was your original issue. That shouldn't be too hard, however. Just make a breakpoint action that calls "thread suspend" on its thread and returns false for should_stop the first time it is called, and just returns true every time thereafter. Then the program should stop at the second hit of the breakpoint rather than continuing to the exit.

Jun 8 2020, 2:58 PM · Restricted Project
jingham added a comment to D80112: Check if thread was suspended during previous stop added..

If I understand the problem you are describing, it is that you suspended a thread as a user-level suspend, so it's stop reason got stuck. That seems okay, its probably useful to keep the stop reason of the thread at what it was when you suspended it. But that means when gets asked to do its action again, the action is stale and does the wrong thing. If that's what's going wrong,

Yes, you understood right, that's exactly what was going wrong.

Actually, you can more easily do that. The thread iteration where we call PerformAction etc. works on a copy of the thread list (since one thread's action could cause the thread list to change). So if you just change the copy operation to only copy over threads which aren't user-suspended, then you should be set.

I don't see that's a copy, it seems that's a reference on the actual thread list:

ThreadList &curr_thread_list = process_sp->GetThreadList();
Jun 8 2020, 12:08 PM · Restricted Project

Jun 4 2020

jingham added a comment to D80112: Check if thread was suspended during previous stop added..

Adding a ShouldStop to that if test doesn't seem right. You should still run the stop actions even if the thread doesn't want to stop.

If I understand the problem you are describing, it is that you suspended a thread as a user-level suspend, so it's stop reason got stuck. That seems okay, its probably useful to keep the stop reason of the thread at what it was when you suspended it. But that means when gets asked to do its action again, the action is stale and does the wrong thing. If that's what's going wrong, then it would make more sense short-circuit suspended threads earlier on in the iteration, like:

lldb::ThreadSP thread_sp = curr_thread_list.GetThreadAtIndex(idx);
// This thread was suspended by the user during this run, so it's actions are stale:
if (thread_sp->GetResumeState() == eStateSuspended)
    continue;

That mirrors what the ThreadList::ShouldStop does. You actually probably don't want to do it quite this way, because it is possible that one thread's breakpoint action could resume another thread. So you should probably first run through the thread list and get all the suspended threads, then run through again doing the actions and skipping the suspended threads you found in the first iteration.

Jun 4 2020, 6:46 PM · Restricted Project
jingham added a comment to D80112: Check if thread was suspended during previous stop added..

Adding a ShouldStop to that if test doesn't seem right. You should still run the stop actions even if the thread doesn't want to stop.

Jun 4 2020, 6:14 PM · Restricted Project
jingham added a comment to D80112: Check if thread was suspended during previous stop added..

It bugs me a little bit that we are doing work masking the stop info when in fact the ShouldStop mechanism is the one that shouldn't be consulting threads that were suspended by the user during the last run.

Jun 4 2020, 2:23 PM · Restricted Project
jingham added a comment to D80112: Check if thread was suspended during previous stop added..

Sorry, now that I'm thinking about this more, I'm confused as to why you are seeing the symptoms you describe. Thread::ShouldStop starts with:

Jun 4 2020, 2:23 PM · Restricted Project
jingham committed rGa976a7fcae44: Disable this test for Windows. (authored by jingham).
Disable this test for Windows.
Jun 4 2020, 11:03 AM

Jun 3 2020

jingham committed rGf4d427326539: Add a test for preserving state on the non-expr thread across expression… (authored by jingham).
Add a test for preserving state on the non-expr thread across expression…
Jun 3 2020, 2:56 PM
jingham added a comment to D80112: Check if thread was suspended during previous stop added..

The one scenario I can think of where this might do the wrong thing is:

Jun 3 2020, 2:55 PM · Restricted Project

May 29 2020

jingham added a comment to D80848: [lldb/Bindings] Raise a Runtime error when using SBAddress properties that rely on lldb.target.

Looks even better.

May 29 2020, 4:24 PM · Restricted Project
jingham accepted D80848: [lldb/Bindings] Raise a Runtime error when using SBAddress properties that rely on lldb.target.

I think "This resolves the SBAddress" is better than "This resolves SBAddress". Other than that LGTM.

May 29 2020, 3:52 PM · Restricted Project
jingham added a comment to D80848: [lldb/Bindings] Raise a Runtime error when using SBAddress properties that rely on lldb.target.

Ooh, test would be good. Just use it in a python command.

May 29 2020, 3:52 PM · Restricted Project
jingham added a comment to D78801: [LLDB] Add class WasmProcess for WebAssembly debugging.

Hello @clayborg , @labath,
Any thoughts on this latest patch? :-)

Sorry about the delay. I think that in terms of the design we've come as far as we can without making substantial changes to a lot of lldb interfaces. The question on my mind is.. is that enough?

Here, I am mainly thinking about the introduction of the ExecutionContext argument to ReadMemory. In a universe with static flat address spaces, the argument looks flat out wrong. If one thinks of "memory" as something more dynamic, it does not seem to be that bad, as it can be viewed as the context in which to interpret the memory addresses. However, I am having trouble assigning a semantic to it besides saying "it does what webassembly needs". Maybe it's just because I live in a flat universe and lack address space intuition...

Anyway, I think it would be good to get more people's opinions on this. For start, I nominate Jim. :)

The problem with "looking forward to implementing more cleanly in the future with AddressSpecifiers" is that _everyone_ is looking forward to having address spaces, but noone is actually working on implementing them. And I want to be careful about accumulating technical debt like this upstream, because it's the technical debt which makes future implementations hard.

May 29 2020, 12:00 PM · Restricted Project
jingham added inline comments to D80724: [lldb] Only set the executable module for a target once.
May 29 2020, 10:53 AM

May 28 2020

jingham added inline comments to D74136: [LLDB] WIP: Follow DW_AT_decl_file when setting breakpoint.
May 28 2020, 3:25 PM · Restricted Project
jingham requested changes to D80724: [lldb] Only set the executable module for a target once.

I don't think that test is right. There's no guarantee that your GetExecutable().GetFilename() runs before or after the dlopen in the process has run. If it runs before you aren't testing anything.

May 28 2020, 3:25 PM
jingham committed rG723a1caa377b: Fix the crashlog.py script's use of the load_address property. (authored by jingham).
Fix the crashlog.py script's use of the load_address property.
May 28 2020, 10:25 AM
jingham closed D80680: save_crashlog should not be using the load_addr property of an SBAddress.
May 28 2020, 10:25 AM · Restricted Project
jingham added a comment to D79929: [lldb] Tab completion for process plugin name.

That does make sense. I will split it into eArgTypeProcessPlugin and eArgTypeDisassemblePlugin along with the corresponding completion function names at the time I implement the disassemble related completion function.

May 28 2020, 9:50 AM · Restricted Project

May 27 2020

jingham created D80680: save_crashlog should not be using the load_addr property of an SBAddress.
May 27 2020, 6:02 PM · Restricted Project
jingham added a comment to D79929: [lldb] Tab completion for process plugin name.

This change makes the eArgTypePlugin be the completion for process plugins. Shouldn't we change the enum name and completion name to indicate that?

May 27 2020, 10:17 AM · Restricted Project

May 26 2020

jingham added a comment to D79823: [lldb][Core] Remove dead codepath in Mangled.

Note that there is no guarantee that ObjC names won't be mangled. They aren't on macOS because the macOS linker grew up along with objC so all the weird characters it introduces into the symbol namespace ([,],-,+, ,etc...) are allowed. Way back in the day when WebObjects ran on Windows ObjC names weren't legal, and were mangled. Just saying...

May 26 2020, 5:28 PM · Restricted Project

May 21 2020

jingham committed rG54c2c2add7ad: Maybe I need ENABLE_THREADS in the Makefile. (authored by jingham).
Maybe I need ENABLE_THREADS in the Makefile.
May 21 2020, 6:57 PM
jingham committed rG1583766ed23b: This very simple .c file is failing on the Debian bot wit the error (authored by jingham).
This very simple .c file is failing on the Debian bot wit the error
May 21 2020, 6:57 PM
jingham committed rGdbbed971e3a2: Handle the case where a thread exits while we are running a function on it. (authored by jingham).
Handle the case where a thread exits while we are running a function on it.
May 21 2020, 6:26 PM
jingham updated the diff for D80350: Handle the case where a thread exits while we were running a function on it.

Address review comments

May 21 2020, 3:44 PM · Restricted Project
jingham added inline comments to D80350: Handle the case where a thread exits while we were running a function on it.
May 21 2020, 3:43 PM · Restricted Project
jingham updated the diff for D80350: Handle the case where a thread exits while we were running a function on it.

clang-format

May 21 2020, 2:38 PM · Restricted Project
jingham added a comment to D80165: [lldb/Driver] Fix handling on positional arguments.

We should make sure if we do exit that we don't output any other text that would obscure the error message. It should be easy to spot the error both so you can easily fix it and to prevent you from typing lldb commands into your shell. If libOption had a "nearest option name to the one you typed" facility that would be useful in this case as well.

That facility exists. Clang uses it for command-line "fix-its". I am not sure what it takes to make use of it.

Jonas said this wasn't part of libOption, but was done by hand in clang.

Oh, that's too bad.

Does anybody remember what gdb does when you mistype a command-line option? We're not at all required to model their behavior, but it would be interesting to consider.

$ gdb -foobar
gdb: unrecognized option '-foobar'
Use `gdb --help' for a complete list of options.

You omitted the bit of text that would show whether it quit or not...

It did quit. With exit code 1. :)

May 21 2020, 10:15 AM · Restricted Project

May 20 2020

jingham created D80350: Handle the case where a thread exits while we were running a function on it.
May 20 2020, 6:15 PM · Restricted Project
jingham added a comment to D80165: [lldb/Driver] Fix handling on positional arguments.

We should make sure if we do exit that we don't output any other text that would obscure the error message. It should be easy to spot the error both so you can easily fix it and to prevent you from typing lldb commands into your shell. If libOption had a "nearest option name to the one you typed" facility that would be useful in this case as well.

That facility exists. Clang uses it for command-line "fix-its". I am not sure what it takes to make use of it.

May 20 2020, 10:54 AM · Restricted Project

May 19 2020

jingham accepted D80159: [lldb/Properties] Move OSPluginReportsAllThreads from Target to Process.

Excellent! Thanks for doing this.

May 19 2020, 11:28 AM · Restricted Project
jingham added a comment to D80165: [lldb/Driver] Fix handling on positional arguments.

I agree with Pavel, reporting an error and exiting seems like a good behavior. When I mistype a command line option, I generally immediately quit lldb, up-arrow and fix and resubmit, so this would save keystrokes.

May 19 2020, 10:55 AM · Restricted Project

May 18 2020

jingham accepted D80165: [lldb/Driver] Fix handling on positional arguments.

LGTM. These were useful behaviors, thanks for restoring them!

May 18 2020, 5:22 PM · Restricted Project
jingham added a comment to D80165: [lldb/Driver] Fix handling on positional arguments.

Not sure why you need to track "beginning and end". Does libOption not pull out all the options (and their option values if they have them) before handing you the command line? If not, then this probably is not worth doing. But if it does, this should be straightforward since the only arguments lldb takes (prior to seeing a --) are meant to be arguments to the program when you run it.

May 18 2020, 4:17 PM · Restricted Project

May 14 2020

jingham added a comment to D79722: Correct the argument list of command `breakpoint read`.

Yes, the most serious omission is that it doesn't complete against breakpoint names. But that is a little orthogonal to this discussion. The Breakpoint ID completer should receive a list of breakpoints and a list of breakpoint names, and complete against those. Then for something like break delete the completer should get fed the current target's list of breakpoints and breakpoint names. But for break list --filename and for break read --filename, it should get passed the list of breakpoints and names read from the file. So in the fullness of time there would be two independent bits of work.

May 14 2020, 11:23 AM · Restricted Project
jingham added a comment to D78972: Treat hasWeakODRLinkage symbols as external in REPL computations.

For expression evaluation in a REPL (which we only have for Swift, but if somebody wants to make such a thing for C++ we wouldn't be displeased) the model is compiling into a single translation unit. I think that's the only thing that makes sense. You don't want to have to artificially make everything public in the REPL so that you could use it in a subsequent REPL session.

May 14 2020, 10:50 AM · Restricted Project

May 13 2020

jingham added a comment to D79722: Correct the argument list of command `breakpoint read`.

Yes, that's right. What you describe is doable. The lldb command completer actually sees the whole command line, not just the argument being completed. We use that in a couple of places in lldb, for instance if you do:

May 13 2020, 11:57 AM · Restricted Project
jingham accepted D79789: [lldb] Don't dissasemble large functions by default.

If you have --force, then the address range is informational, in which case having the full command would be more confusing than anything. So this is fine, thanks for adding it.

May 13 2020, 11:25 AM · Restricted Project
jingham added a comment to D79722: Correct the argument list of command `breakpoint read`.

I'm not sure I agree with you. If the workflow is that you use "break list --filename" to see what is in the saved breakpoint file - which would presumably produce exactly the same listing as "break list" with any other specifier would - then it would be very natural to expect that you pick out of the list results in "break read" exactly as you would other breakpoint commands.

May 13 2020, 10:50 AM · Restricted Project

May 12 2020

jingham added a comment to D79789: [lldb] Don't dissasemble large functions by default.

Instead of just printing out the range, can we print out the disassemble command you would run to actually disassemble the range?

May 12 2020, 11:49 AM · Restricted Project
jingham added a comment to D79722: Correct the argument list of command `breakpoint read`.

It is fine to take this out for now. I didn't get to finish this when I was last working on it. In the finished design you would say:

May 12 2020, 11:17 AM · Restricted Project

May 11 2020

jingham added a comment to D79666: Complete breakpoint enable/disable/delete/modify with a list of breakpoint IDs.

This is great, but you can also specify breakpoints by name. Should be possible to also complete on the list of breakpoint names.

May 11 2020, 10:12 AM · Restricted Project

May 8 2020

jingham added a comment to D79659: [lldb/Commands] Add ability to run shell command on the host..

I do something similar with CommandObjectThreadStepWithTypeAndScope so that I can share most of that command code, if you want to see an example of doing that.

May 8 2020, 7:21 PM · Restricted Project
jingham added a comment to D79659: [lldb/Commands] Add ability to run shell command on the host..

We certainly shouldn't duplicate the code for CommandObjectPlatformShell.

May 8 2020, 7:21 PM · Restricted Project
jingham requested changes to D79659: [lldb/Commands] Add ability to run shell command on the host..
May 8 2020, 7:21 PM · Restricted Project

May 7 2020

jingham added inline comments to D79554: [lldb/Dataformatter] Add support to CF{Dictionary,Set}Ref types.
May 7 2020, 3:14 PM · Restricted Project
jingham added a comment to D79554: [lldb/Dataformatter] Add support to CF{Dictionary,Set}Ref types.

The way the ValueObject code works w.r.t. Synthetic child providers is that you first look up and make a ValueObject for the actual value the user requested, (for instance a ValueObjectVariable or a ValueObjectChild or a ValueObjectConstResult for expressions, etc.), then you hand that to the printer. The printer will look at whether the current settings prefer Synthetic Values, and if they do they ask the actual value if it has any Synthetic children. So when you do something like:

May 7 2020, 11:20 AM · Restricted Project
jingham accepted D78798: [lldb] Add missing nullptr checks to AppleObjCRuntime::GetBacktraceThreadFromException.

Excellent, thanks!

May 7 2020, 10:47 AM · Restricted Project
jingham accepted D79308: [lldb-server] Reset stop reason of all threads when resuming.

LGTM too!

May 7 2020, 10:47 AM · Restricted Project

May 4 2020

jingham added a comment to D78798: [lldb] Add missing nullptr checks to AppleObjCRuntime::GetBacktraceThreadFromException.

Yes, we shouldn't fall over if we can't get the exception backtrace out of the exception message.

May 4 2020, 11:48 AM · Restricted Project

Apr 30 2020

jingham added a comment to D78972: Treat hasWeakODRLinkage symbols as external in REPL computations.

That one does work all the way, including calling the function. That should be surprising. It shouldn't with an unpatched lldb, right?

Yep, I realized that is not the best example after posting that comment.

We do this whole dance again every time we run this expression. It looks like we don't look for instances of a template if we know how to make it, we just make it again. That actually makes sense. When you are compiling, you don't know if you will find an instantiation, so you have to make it. Then you leave it to the linker to remove duplicates.

You're describing the "normal" linkonce semantics. Things get more complex once you start having explicit instantiations: template void f<int>(); forces a compiler to emit an instantiation even though it is not needed (this results in the weak_odr linkage. extern template void f<int>(); inhibits instantiation -- the compiler will assume you have an explicit instantiation elsewhere. The fact that the explicit instantiation is "weak" allows for some interesting effects, but it's tricky to demonstrate them, as they all involve UB. Once can see some of that with normal compilation like this:

$ head a.cc b.cc c.cc
==> a.cc <==
#include <cstdio>

template<typename T> void f() { printf("Hello T\n"); }

template void f<int>(); // weak

==> b.cc <==
#include <cstdio>

extern "C" void _Z1fIiEvv() { printf("Hello _Z1fIiEvv\n"); } // strong

==> c.cc <==
#include <cstdio>

template<typename T> void f() { printf("Hello T\n"); }

extern template void f<int>(); // inhibit instantiation

int main() {
  f<int>();
}
$ c++ a.cc c.cc
$ ./a.out 
Hello T
$ c++ a.cc c.cc b.cc
$ ./a.out 
Hello _Z1fIiEvv

I don't know whether any of this is relevant for top-level expressions.

Apr 30 2020, 12:21 PM · Restricted Project

Apr 29 2020

jingham added a comment to D78972: Treat hasWeakODRLinkage symbols as external in REPL computations.

I don't have a way to write a C-based test for this as I don't know how to craft a user expression in C that will make such a thing. I asked around a bit and nobody had an easy way to do this.

Grepping clang's tests for weak_odr was very educational. The most portable way to produce this linkage seems to be:

template<typename T> void f() {}
template void f<int>();

As for whether this patch is correct -- I don't know. The weak_odr functions are allowed to be replaced (that's the weak part), but the replacement is supposed to be equivalent (the odr part). So, strictly speaking, it may be ok to just export this function, but if we wanted to be closer to what happens for realz, we should check first if there isn't a more definitive version available elsewhere...

I can't get the expression parser to successfully run this code and then call the function in a later evaluation. Apparently we're not all the way up to creating & instantiating templates. I tried it with and without this patch and it didn't make any difference.

It seems to work for me:

$ bin/lldb bin/lldb
(lldb) target create "bin/lldb"
Current executable set to 'bin/lldb' (x86_64).
(lldb) b main
Breakpoint 1: where = lldb`main, address = 0x00000000000099d0
(lldb) r
Process 4504 launched: 'bin/lldb' (x86_64)
Process 4504 stopped
* thread #1, name = 'lldb', stop reason = breakpoint 1.1
    frame #0: 0x000055555555d9d0 lldb`main
lldb`main:
->  0x55555555d9d0 <+0>: pushq  %r15
    0x55555555d9d2 <+2>: xorl   %ecx, %ecx
    0x55555555d9d4 <+4>: pushq  %r14
    0x55555555d9d6 <+6>: pushq  %r13
(lldb) expr --top-level -- template<typename T> void f() { (int)printf("hello world\n"); } template void
f<int>();
(lldb) expr f<int>()
hello world

In the context of the REPL & top-level, I'm not sure how we would find the "equivalent version". But if it is supposed to be equivalent, is that important for functions the REPL & top-level are generating?

I don't know about REPL, but top-level expressions can interact with (call) target functions. If a top-level expression defines a weak symbol that is also has a strong definition in the target (or maybe in another top level expression), the maybe one would expect that we call the strong definition.

As to why, I guess the reason is that the only thing which enforces this "supposed" equivalence is the spectre of undefined behavior. The user will (unknowingly) do that anyway, things will go wrong and then they'll try to debug it...

Apr 29 2020, 4:46 PM · Restricted Project

Apr 28 2020

jingham added a comment to D78972: Treat hasWeakODRLinkage symbols as external in REPL computations.

I don't have a way to write a C-based test for this as I don't know how to craft a user expression in C that will make such a thing. I asked around a bit and nobody had an easy way to do this.

Grepping clang's tests for weak_odr was very educational. The most portable way to produce this linkage seems to be:

template<typename T> void f() {}
template void f<int>();

As for whether this patch is correct -- I don't know. The weak_odr functions are allowed to be replaced (that's the weak part), but the replacement is supposed to be equivalent (the odr part). So, strictly speaking, it may be ok to just export this function, but if we wanted to be closer to what happens for realz, we should check first if there isn't a more definitive version available elsewhere...

Apr 28 2020, 10:11 AM · Restricted Project

Apr 27 2020

jingham created D78972: Treat hasWeakODRLinkage symbols as external in REPL computations.
Apr 27 2020, 5:16 PM · Restricted Project

Apr 20 2020

jingham added a comment to D78421: Fix out of sync source code/executable when debugging.

I can see the cases where this would help, but the way you are doing it could lead to some odd behavior that might be confusing.

Apr 20 2020, 1:00 PM · Restricted Project

Apr 15 2020

jingham added a comment to D78242: [lldb/Docs] Add some more info about the test suite layout.

This is great, thanks for doing this. You point people at lldbutils.py as a source for utility functions (like print_stacktrace, etc...) But it is maybe also worth pointing them at the lldbtest.py for extensions runCmd and some of the other testing primitives we've added to the unittest2 framework.

Apr 15 2020, 5:06 PM · Restricted Project

Apr 10 2020

jingham committed rGaa4b37b2acda: Convert the ThreadPlanCommands test to use a scripted plan that pushes a step… (authored by jingham).
Convert the ThreadPlanCommands test to use a scripted plan that pushes a step…
Apr 10 2020, 6:21 PM
jingham committed rGf7de4b5d6bce: Thread Plans pushed by a scripted plan should be private plans. (authored by jingham).
Thread Plans pushed by a scripted plan should be private plans.
Apr 10 2020, 6:21 PM

Apr 8 2020

jingham accepted D77698: [DWARF] Assign the correct scope to constant variables.

The code looks good to me. I'll defer to Adrian as to whether the test is robust, though it also seems reasonable to deal with a failure caused by llvm changes when it happens.

Apr 8 2020, 11:24 AM
jingham accepted D77444: [commands] Support autorepeat in SBCommands.

LGTM

Apr 8 2020, 10:51 AM · Restricted Project

Apr 7 2020

jingham added a comment to D77444: [commands] Support autorepeat in SBCommands.

This looks good to me, except that instead of leaving all the other variants of AddCommand, they should funnel through the one that takes the most arguments. It was poor form to leave two around and more so now that there's three.

Apr 7 2020, 4:22 PM · Restricted Project
jingham added inline comments to D77662: [lldb/test] Make TestLoadUnload compatible with windows.
Apr 7 2020, 11:55 AM · Restricted Project
jingham added a comment to D77582: [CommandInterpreter] Implement UserCommandExists.

I think the part of the patch that adds documentation to the existing method should go in (In general all patches that just add documentation have my blanket approval, so please just commit those).

About that... the existing practice has been to attach documentation to the python versions of these interfaces (bindings/interface/*.i). Now we started to add it to the c++ headers too. More documentation is always better, but OTOH repetition creates maintenance problems and increases the risk of it going stale. Should choose one of the two interfaces and put all documentation there (and maybe have a way to auto-generate the other one) ?

Apr 7 2020, 10:18 AM · Restricted Project
jingham added a comment to D77153: [lldb/DataFormatters] Display null C++ pointers as nullptr.

ValueObjects know their execution context, and so they can get to their frame, if they have one. The language of the frame seems like the best thing to clue off here.

Apr 7 2020, 10:18 AM · Restricted Project

Apr 3 2020

jingham committed rG327074812707: The thread plan list test is failing at least on Ubuntu Linux. Mark it expected… (authored by jingham).
The thread plan list test is failing at least on Ubuntu Linux. Mark it expected…
Apr 3 2020, 8:34 PM
jingham added a comment to D77444: [commands] Support autorepeat in SBCommands.

For instance, maybe instead of passing in a bool, you could pass in the repeat command? So when you create the command, if you pass in None, you get no repeat, if you pass in "" you get the exact command line repeated, and if you pass in anything else, that will be the repeat command. Or maybe use an enum with "noRepeat, exactRepeat, commandNameRepeat"?

Apr 3 2020, 8:34 PM · Restricted Project
jingham added a comment to D77444: [commands] Support autorepeat in SBCommands.

It's great to add this capability. But if you pass a nullptr, then the exact previous command will be repeated. That's sometimes what you want, but often not. For instance:

Apr 3 2020, 8:02 PM · Restricted Project
jingham accepted D77450: Fix LLDB debug builds.

Ah, great, thanks. Looks like the standalone Xcode debug build doesn't pass LDB_CONFIGURATION_DEBUG. That's a little odd, but the patch is fine.

Apr 3 2020, 8:02 PM · Restricted Project
jingham committed rG48ba745eacf8: This test is failing on the Ubuntu bot but the bot log doesn't capture the test… (authored by jingham).
This test is failing on the Ubuntu bot but the bot log doesn't capture the test…
Apr 3 2020, 6:27 PM
jingham committed rG2d658c56d57c: Disable two new tests on Windows. They are failing but the logs are not… (authored by jingham).
Disable two new tests on Windows. They are failing but the logs are not…
Apr 3 2020, 5:22 PM
jingham committed rG1893065d7bf5: Allow the ThreadPlanStackMap to hold the thread plans for threads that were not… (authored by jingham).
Allow the ThreadPlanStackMap to hold the thread plans for threads that were not…
Apr 3 2020, 3:12 PM
jingham committed rG61e8e6882de7: Move thread plan stacks into the Process, indexed by TID. (authored by jingham).
Move thread plan stacks into the Process, indexed by TID.
Apr 3 2020, 3:12 PM
jingham closed D76814: Preserve ThreadPlanStacks for unreported threads.
Apr 3 2020, 3:12 PM · Restricted Project
jingham closed D75880: [NFC} Move ThreadPlans stacks into their own class, store it in Process by TID.
Apr 3 2020, 3:12 PM · Restricted Project
jingham committed rG2c1c57a1df81: Make ThreadPlanTracers use TID & Process rather than Thread *. (authored by jingham).
Make ThreadPlanTracers use TID & Process rather than Thread *.
Apr 3 2020, 3:12 PM
jingham committed rGe4598dc04a1f: Make ThreadPlans use TID and Process, rather than Thread *. (authored by jingham).
Make ThreadPlans use TID and Process, rather than Thread *.
Apr 3 2020, 3:12 PM
jingham closed D75720: Make ThreadPlanTracer use {Process,TID} rather than Thread to find it's underlying thread....
Apr 3 2020, 3:12 PM · Restricted Project