Re: [lldb-dev] [RFC] Segmented Address Space Support in LLDB

On 22/10/2020 10:25, Jason Molenda wrote: Hi Greg, Pavel. I think it's worth saying that this is very early in this project. We know we're going to need the ability to track segments on addresses, but honestly a lot of the finer details aren't clear yet. It's such a fundamental change that

Re: [lldb-dev] Need help with failing LLDB tests on Windows

On 04/11/2020 01:53, Adrian McCarthy via lldb-dev wrote: For the past couple weeks, I've been trying to figure out why approximately 900+ LLDB tests have been failing for me on my local Windows builds.  Bisect turned up nothing--the "good" version that was working for me no longer works.  Since

Re: [lldb-dev] Remote connection expansion?

On 11/11/2020 20:11, Mike Mestnik via lldb-dev wrote: On Mon, Nov 9, 2020 at 5:37 PM Greg Clayton wrote: On Nov 4, 2020, at 1:28 PM, Mike Mestnik via lldb-dev wrote: I'm looking for support running lldb over ssh. I can forward the originating connection, but the run command is attemptin

Re: [lldb-dev] Help fixing deadlock in DWARF symbol preloading

Please have a look at , which is the last time this came up. One quick'n'dirty solution would be to have `Module::ReportError` _try_ to get the module lock, and if it fails, just bail out. That obviously means you won't get

Re: [lldb-dev] Help fixing deadlock in DWARF symbol preloading

On 05/02/2021 00:38, Jorge Gorbe Moya wrote: Wouldn't it be preferable to try_lock in GetDescription (which is the one currently acquiring the mutex) instead? I'd be uncomfortable with a function like GetDescription "randomly" doing nothing (returning an empty string, or whatever). OTOH, while

[lldb-dev] Removing linux mips support

Hi all, I propose to remove support for linux mips debugging. This basically amounts to deleting source/Plugins/Process/Linux/NativeRegisterContextLinux_mips64.{cpp,h}. My reasons for doing that are: - This code is unmaintained (last non-mechanical change was in 2017) and untested (no publi

Re: [lldb-dev] Removing linux mips support

On 16/03/2021 00:37, Ed Maste via lldb-dev wrote: On Mon, 15 Mar 2021 at 16:00, Ed Maste wrote: A brief note on the FreeBSD mips support - the FreeBSD Foundation is sponsoring Michał to do this work, but our primary non-x86 focus is amd64. Oops, that doesn't make a lot of sense. I meant arm6

Re: [lldb-dev] RFC: packet to identify a standalone aka firmware binary UUID / location

On 23/03/2021 07:01, Jason Molenda wrote: Hi, I'm working with an Apple team that has a gdb RSP server for JTAG debugging, and we're working to add the ability for it to tell lldb about the UUID and possibly address of a no-dynamic-linker standalone binary, or firmware binary. Discovery of th

Re: [lldb-dev] [RFC] Improving protocol-level compatibility between LLDB and GDB

I am very happy to see this effort and I fully encourage it. On 20/04/2021 09:13, Michał Górny via lldb-dev wrote: On Mon, 2021-04-19 at 16:29 -0700, Greg Clayton wrote: I think the first blocker towards this project are existing implementation bugs in LLDB. For example, the vFile implementatio

Re: [lldb-dev] [RFC] Improving protocol-level compatibility between LLDB and GDB

On 25/04/2021 22:26, Jason Molenda wrote: I was looking at lldb-platform and I noticed I implemented the A packet in it, and I was worried I might have the same radix error as lldb in there, but this code I wrote made me laugh: const char *p = pkt.c_str() + 1; // skip the 'A' std::

Re: [lldb-dev] Duplicate use of "sp" register name on x86 targets

On 25/08/2021 21:13, Michał Górny via lldb-dev wrote: Hi, While working on improving gdbserver compatibility, I've noticed that "sp" is used twice: 1. as an alt_name for esp/rsp register (giving full 32/64-bit stack pointer), 2. and as the name of sp pseudo-register (giving ESP/RSP truncated t

Re: [lldb-dev] who is maintaining lldb-x86_64-debian

On 03/09/2021 07:00, Omair Javaid via lldb-dev wrote: Hi Jan, On Thu, 2 Sept 2021 at 17:29, Jan Kratochvil > wrote: On Thu, 02 Sep 2021 12:42:37 +0200, Raphael “Teemperor” Isemann via lldb-dev wrote: > If this is about the TestGuiBasicDebug failure

Re: [lldb-dev] Serial port support in LLDB

Thanks for the nice summary Michał. I've found it very helpful. The thing I am missing from this proposal is how would those settings translate into actual termios calls? Like, who would be responsible reading those settings and acting on them? Currently we have some tty code in ConnectionFile

Re: [lldb-dev] Serial port support in LLDB

On 06/10/2021 14:59, Michał Górny wrote: On Wed, 2021-10-06 at 14:32 +0200, Pavel Labath wrote: Let me try to make a counterproposal. Since the serial parameters are a property of a specific connection, and one could theoretically have be debugging multiple processes with different connection p

Re: [lldb-dev] Serial port support in LLDB

On 08/10/2021 11:06, Pavel Labath via lldb-dev wrote: On 06/10/2021 14:59, Michał Górny wrote: On Wed, 2021-10-06 at 14:32 +0200, Pavel Labath wrote: Let me try to make a counterproposal. Since the serial parameters are a property of a specific connection, and one could theoretically have be

[lldb-dev] Semantics of SBValue::CreateChildAtOffset

Hello Jim, everyone, I recently got a question/bug report about python pretty printers (synthetic child providers) that I couldn't answer. The actual script is of course more complicated, but the essence boils down to this. There's a class, something like: struct S { ... T member; }; T

[lldb-dev] [RFC] lldb integration with (user mode) qemu

Hello everyone, I'd like to propose a new plugin for better lldb+qemu integration. As you're probably aware qemu has an integrated gdb stub. Lldb is able to communicate with it, but currently this process is somewhat tedious. One has to manually start qemu, giving it a port number, and then sepa

Re: [lldb-dev] [RFC] lldb integration with (user mode) qemu

Thanks for reading this. Responses inline. On 28/10/2021 16:28, David Spickett wrote: Glad to hear the gdb server in qemu plays nicely with lldb. Perhaps some of that is the compatibility work that has been going on. The introduction of a qemu platform would introduce such an ambiguity, since

Re: [lldb-dev] [RFC] lldb integration with (user mode) qemu

On 29/10/2021 12:39, David Spickett wrote: So there wouldn't be a three-way tie, but if you actually wanted to debug a native executable under qemu, you would have to explicitly select the qemu platform. This is the same thing that already happens when you want to debug a native executable rem

Re: [lldb-dev] [RFC] lldb integration with (user mode) qemu

On 29/10/2021 14:00, Pavel Labath via lldb-dev wrote: On 29/10/2021 12:39, David Spickett wrote: So there wouldn't be a three-way tie, but if you actually wanted to debug a native executable under qemu, you would have to explicitly select the qemu platform. This is the same thing that al

Re: [lldb-dev] The two PDB plugins in LLDB

[+ aleksandr] On 03/11/2021 09:18, Martin Storsjö via lldb-dev wrote: On Tue, 2 Nov 2021, Raphael Isemann via lldb-dev wrote: Unless removing the non-native PDB plugin has some negative impact on users (e.g., missing features in native plugin that work with the non-native plugin), I would prop

Re: [lldb-dev] [RFC] lldb integration with (user mode) qemu

On 29/10/2021 14:55, David Spickett wrote: I don't think it does. Or at least I'm not sure how do you propose to solve them (who is "you" in the paragraph above?). I tend to use "you" meaning "you or I" in hypotheticals. Same thing as "if I had" but for whatever reason I phrase it like that to

Re: [lldb-dev] [RFC] lldb integration with (user mode) qemu

On 03/11/2021 14:53, David Spickett wrote: Yeah, I think we can start with that. No need to consider this now but it could easily be adapted to qemu-system as well. Spinning up qemu-system for Cortex-M debug might be a future use case. Once you've got a "run this program and connect to this por

Re: [lldb-dev] [RFC] lldb integration with (user mode) qemu

On 04/11/2021 22:46, Jessica Clarke via lldb-dev wrote: On Fri, Oct 29, 2021 at 05:55:02AM +, David Spickett via lldb-dev wrote: I don't think it does. Or at least I'm not sure how do you propose to solve them (who is "you" in the paragraph above?). I tend to use "you" meaning "you or I"

Re: [lldb-dev] [RFC] lldb integration with (user mode) qemu

mething this work needs to consider. Just me relating the idea to something I have more experience with and has some parallels with the qemu-user idea. On Fri, 5 Nov 2021 at 14:08, Pavel Labath via lldb-dev wrote: On 04/11/2021 22:46, Jessica Clarke via lldb-dev wrote: On Fri, Oct 29, 2021 at 05:55:

Re: [lldb-dev] Adding support for FreeBSD kernel coredumps (and live memory lookup)

On 30/11/2021 14:49, Michał Górny via lldb-dev wrote: Hi, I'm working on a FreeBSD-sponsored project aiming at improving LLDB's support for debugging FreeBSD kernel to achieve feature parity with KGDB. As a part of that, I'd like to improve LLDB's ability of working with kernel coredumps ("vmco

Re: [lldb-dev] Adding support for FreeBSD kernel coredumps (and live memory lookup)

On 10/12/2021 11:12, Michał Górny wrote: On Mon, 2021-12-06 at 14:28 +0100, Pavel Labath wrote: The live kernel debugging sounds... scary. Can you explain how would this actually work? Like, what would be the supported operations? I presume you won't be able to actually "stop" the kernel, but wh

Re: [lldb-dev] RFC: siginfo reading/writing support

I kinda like the cleanliness (of the design, not the implementation) of a $siginfo variable, but you're right that implementing it would be tricky (I guess we'd have to write the struct info the process memory somewhere and then read it back when the expression completes). I don't expect that

Re: [lldb-dev] Source-level stepping with emulated instructions

Hi Kjell, if you say these instructions are similar to function calls, then it sounds to me like the best option would be to get lldb to treat them like function calls. I think (Jim can correct me if I'm wrong) this consists of two things: - make sure lldb recognizes that these instructions ca

[lldb-dev] Multiple platforms with the same name

Hello all, currently our code treats platform name more-or-less as a unique identifier (e.g. Platform::Find returns at most one platform instance --the first one it finds). This is why I was surprised that the "platform select" CLI command always creates a new instance of the given platform

Re: [lldb-dev] Multiple platforms with the same name

On 19/01/2022 00:38, Greg Clayton wrote: Platforms can contain connection specific setting and data. You might want to create two different "remote-linux" platforms and connect each one to a different remote linux machine. Each target which uses this platform would each be able to fetch files,

[lldb-dev] Is GetLogIf**All**CategoriesSet useful?

Hi all, In case you haven't noticed, I'd like to draw your attention to the in-flight patches (https://reviews.llvm.org/D117382, https://reviews.llvm.org/D117490) whose goal clean up/improve/streamline the logging infrastructure. I'm don't want go into technical details here (they're on the

Re: [lldb-dev] Is GetLogIf**All**CategoriesSet useful?

On 20/01/2022 00:30, Greg Clayton wrote: I also vote to remove and simplify. Sounds like it's settled then. I'll fire up my sed scripts. On 20/01/2022 01:38, Greg Clayton wrote: On Jan 19, 2022, at 6:40 AM, Pavel Labath wrote: If we got rid of this, we could simplify the logging calls eve

Re: [lldb-dev] Multiple platforms with the same name

I'm sorry for the slow response. I had to attend to some other things first. It sounds like there's agreement to support multiple platform instances, so I'll try to move things in that direction. Further responses inline On 20/01/2022 01:19, Greg Clayton wrote: On Jan 19, 2022, at 4:28 AM,

Re: [lldb-dev] test results look typical?

There is no separate option, it should just work. :) I'm betting you are still missing some package there (we should document the prerequisites better). Could you send the error message you are getting so we can have a look. cheers, pl On 25 August 2015 at 16:20, Todd Fiala via lldb-dev wrote:

Re: [lldb-dev] test results look typical?

There's no need to do anything fancy (yet :) ). For initial diagnosis the output of `./dotest.py $your_usual_options -p SomeLibcxxTest.py -t` should suffice. pl On 25 August 2015 at 16:45, Todd Fiala wrote: > Thanks, Pavel! I'll dig that up and get back. > > On Tue, Aug 25, 2015 at 8:30 AM, Pav

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

On 26 August 2015 at 06:14, Zachary Turner via lldb-dev wrote: > > I'll wait and see if anyone can remember which tests rebuild binaries on > purpose. Otherwise I will try to look through them and see if I can figure > it out. TestInferiorChanged is one that I remember. I think this is a good t

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

The main issue I see with all these APIs is that they are non-blocking. That is, the test executable cannot simply say "wait until a debugger attaches", but it will have to do something like: while (! attached) { sleep(X); attached = figure_out_if_i_am_attached_using_architecture_specific_metho

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

Ah yes, our old friend TestHelloWorld. This guy definitely needs to be fixed. I haven't actually looked at the code before to see why it was so flaky, but now it all makes sense I would just use the "usual" protocol of "expr release_child = 1" here, but if you wanna go crazy, then go ahead...

lldb-dev@lists.llvm.org

I think it should be a weak_ptr if anything. Target already holds a shared_ptr of the process, and you will get pointer loops otherwise. Couldn't you make sure the debug thread exits (and processes all events) before the Target gets deleted (e.g. shut it down in Process::Finalize() or somewhere...

Re: [lldb-dev] Portable tests that create threads

+1 for the naming idea. It sounds like the a more reliable solution than crawling backtraces to me. pl On 3 September 2015 at 06:32, Todd Fiala via lldb-dev wrote: > I think the thread naming is a reasonable way to go. > >> 1) Linux and MacOSX inferiors can use pthread_setname_np >> 2) FreeBSD i

Re: [lldb-dev] Difference of behaviour of process.Continue() between MacOSX and Linux

Hi, thanks for your report. Let me first ask you a question. Which version of lldb are you using? If it's anything less than 3.7, then I strongly recommend to upgrade, since linux support was not in a very good state there. If you are using 3.7 or svn, then the thing you are describing should wo

Re: [lldb-dev] Looking for info on two rdars: 18684124, 15367233

On 9 September 2015 at 14:21, Ed Maste via lldb-dev wrote: > Also, are these tests passing on Linux? The tests seem to be passing for linux as well. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-de

Re: [lldb-dev] lldb::SBDebugger::Terminate() hangs in deadlock

Hi, Thanks for the report. Since you are suspecting a deadlock, could you post a backtrace of all the threads (thread apply all backtrace). It would be best to move this discussion to a bug in llvm.org/bugs. > I am currently using svn revision 247535 of llvm and lldb, and I know that my > code w

Re: [lldb-dev] possible test runner speedup

Hi, Interesting results. We were discussing the same thing last week. I was somewhat skeptical to the ideal as I am afraid of increased flakyness -- LLDB has hardcoded timeout values in a lot of places, and with increased cpu contention, we might start to see this code failing because the other si

[lldb-dev] correct event sequence on process detach

Hello all, The following question came up while fixing up handling of process detach. when detaching from a running process, on some platforms LLDB needs to stop it first. Is this stop something that should be hidden from the public view or not? I.e. if the process state is Running, and I do a p

Re: [lldb-dev] Thread resumes with stale signal after executing InferiorCallMmap

Hi, I believe the SIGILL problem you are referring to is the problem described in bug . This was fixed in r244875, but unfortunately, this was after 3.7 branch so this patch did not make it there. I recommend to try the master branch, I think this shoul

Re: [lldb-dev] Thread resumes with stale signal after executing InferiorCallMmap

On 8 October 2015 at 17:08, Eugene Birukov wrote: > Yes, that's exactly what I see, thanks a lot! You're wellcome. > > Does it explain why I see SIGILL reappear when I let process continue after > mmap execution? I.e. do I need to look into this more? No. That could still be a bug somewhere. Feel

Re: [lldb-dev] Thread resumes with stale signal after executing InferiorCallMmap

Sure, fair enough. If you have made a small repro case already though, it would be great if you could file a bug about it, so we don't forget it. pl On 12 October 2015 at 23:23, Eugene Birukov wrote: > I tried to repro it using standard LLDB client on a simple program that I > could share. Well

Re: [lldb-dev] TestRaise.py test_restart_bug flakey stats

I have created this test to reproduce a race condition in ProcessGDBRemote. Given that it tests a race condition, it cannot be failing 100% of the time, but I agree with Tamas that we should keep it as XFAIL to avoid noise in the buildbots. pl On 19 October 2015 at 12:30, Tamas Berghammer via lld

Re: [lldb-dev] lldb tests and tear down hooks

I think we can remove these, provided there is a way to mimic the functionality they are used for now, which I think shouldn't be hard. Anything which was set up in the setUp() method should be undone in tearDown(). Anything which was set up in the test method, can be undone using a try-finally blo

Re: [lldb-dev] [Lldb-commits] [lldb] r248028 - Make libc++ tests skip themselves if libc++ is not actually loaded in the target

[moving this to lldb-dev for more visibility.] Sorry, I was in a hurry yesterday, so I did not explain myself fully. Let me try to elaborate. > What I am trying to avoid here is getting useless noise in build automation where test cases proclaim their failure, which however tells us nothing of va

Re: [lldb-dev] Inquiry for performance monitors

[ Moving this discussion back to the list. I pressed the wrong button when replying.] Thanks for the explanation Ravi. It sounds like a very useful feature indeed. I've found a reference to the debugserver profile data in GDBRemoteCommunicationClient.cpp:1276, so maybe that will help with your inv

<    1   2   3   4   5   6