Re: [lldb-dev] lldb warning or developer options

2019-09-27 Thread Pavel Labath via lldb-dev
On 27/09/2019 07:52, Sourabh Singh Tomar via lldb-dev wrote: Hi Folks, Is their a developer switch or diagnostic switch, that we can set in lldb, to show warnings and other useful stuff when lldb process the binary, building table and utilizing DWARF. I stumble upon, a rather trivial test

Re: [lldb-dev] RFC: full support for python files, and avoid using FILE* internally

2019-09-24 Thread Pavel Labath via lldb-dev
On 23/09/2019 20:54, Larry D'Anna wrote: On Sep 23, 2019, at 7:11 AM, Pavel Labath wrote: On 20/09/2019 17:35, Larry D'Anna via lldb-dev wrote: Hi lldb-dev. I want to be able to use LLDB inside of iPython, so I can have mixed python and LLDB debug session. To this end, I’d like to update

Re: [lldb-dev] https://reviews.llvm.org/D69273

2019-11-04 Thread Pavel Labath via lldb-dev
On 31/10/2019 20:51, Jim Ingham via lldb-dev wrote: It looks like this change is causing problems with swift. I was talking a little bit with Davide about this and it seems like it wasn't obvious how this was designed to work. So here's what this was intended to do (apologies if this is at

Re: [lldb-dev] https://reviews.llvm.org/D69273

2019-11-04 Thread Pavel Labath via lldb-dev
On 04/11/2019 18:19, Jim Ingham wrote: Sorry, my brain is not working this morning, I answered your question in the review comments… Jim NP, maybe let's continue the discussion there? I find it useful to have the actual code change around.. ___

Re: [lldb-dev] issue with lldb9 and python3.5

2019-10-30 Thread Pavel Labath via lldb-dev
On 29/10/2019 21:40, Christos Zoulas wrote: On Oct 29, 6:54pm, pa...@labath.sk (Pavel Labath) wrote: -- Subject: Re: [lldb-dev] issue with lldb9 and python3.5 | On 29/10/2019 09:31, Serge Guelton via lldb-dev wrote: | > On Mon, Oct 28, 2019 at 10:09:53AM -0700, Adrian McCarthy wrote: | >> +1

Re: [lldb-dev] issue with lldb9 and python3.5

2019-10-30 Thread Pavel Labath via lldb-dev
On 30/10/2019 11:18, Kamil Rytarowski wrote: On 30.10.2019 11:06, Pavel Labath wrote: On 29/10/2019 21:40, Christos Zoulas wrote: On Oct 29,  6:54pm, pa...@labath.sk (Pavel Labath) wrote: -- Subject: Re: [lldb-dev] issue with lldb9 and python3.5 | On 29/10/2019 09:31, Serge Guelton via

Re: [lldb-dev] https://reviews.llvm.org/D69273

2019-10-31 Thread Pavel Labath via lldb-dev
(Just writing to say that tomorrow is a public holiday in most of Europe, so I wont be able to meaningfully reply to this until monday/tuesday. But if, in the mean time, you want to revert this, or just limit the scope of that patch somehow, then that's fine with me.) On 31/10/2019 20:51, Jim

Re: [lldb-dev] The pre-built Windows LLDB binary has a dependency on an external python36.dll?

2019-11-20 Thread Pavel Labath via lldb-dev
On 20/11/2019 23:53, Adrian McCarthy via lldb-dev wrote: That said, I didn't expect an explicit dependency on python36.dll. What kind of behavior did you expect? pl ___ lldb-dev mailing list lldb-dev@lists.llvm.org

Re: [lldb-dev] [RFC] Supporting Lua Scripting in LLDB

2019-12-09 Thread Pavel Labath via lldb-dev
I think this would be a very interesting project, and would allow us to flesh out the details of the script interpreter interface. A lot of the complexity in our python code comes from the fact that python can be (a) embedded into lldb and (b) lldb can be embedded into python. It's been a while

Re: [lldb-dev] [RFC] Supporting Lua Scripting in LLDB

2019-12-10 Thread Pavel Labath via lldb-dev
On 09/12/2019 18:27, Jonas Devlieghere wrote: > On Mon, Dec 9, 2019 at 1:55 AM Pavel Labath wrote: >> >> I think this would be a very interesting project, and would allow us to >> flesh out the details of the script interpreter interface. >> >> A lot of the complexity in our python code comes

Re: [lldb-dev] The future of modern-type-lookup in LLDB

2019-12-12 Thread Pavel Labath via lldb-dev
Thanks for the nice summary Raphael, this isn't exactly my playground (though I may end up having to poke in this soon), but it overall, it sounds to me like this "modern" thingy is a better overall design. However, your penultimate bullet point seems pretty important to me. I don't think we can

Re: [lldb-dev] issue with lldb9 and python3.5

2019-10-29 Thread Pavel Labath via lldb-dev
On 29/10/2019 09:31, Serge Guelton via lldb-dev wrote: On Mon, Oct 28, 2019 at 10:09:53AM -0700, Adrian McCarthy wrote: +1 Yes, for Windows, I'd be happy if we said Python 3.6+. I investigated the bug yesterday, and filled some of my discoveries in

Re: [lldb-dev] Inconsistencies in CIE pointer in FDEs in .debug_frame

2019-11-25 Thread Pavel Labath via lldb-dev
On 24/11/2019 23:16, Martin Storsjö via lldb-dev wrote: Hi, I'm looking into something that seems like an inconsistency in handling of the CIE pointer in FDEs in .debug_frame, between how debug info is generated in LLVM and consumed in LLDB. For FDEs in .eh_frame, the CIE pointer/cie_id

Re: [lldb-dev] SBValues referencing deallocated memory

2019-11-27 Thread Pavel Labath via lldb-dev
On 27/11/2019 08:47, Raphael “Teemperor” Isemann via lldb-dev wrote: This can also be reproduced in the command line like this: (lldb) expr "foo" (const char [4]) $0 = "foo" (lldb) expr "bar" (const char [4]) $1 = "bar" (lldb) expr $0 (const char [4]) $0 = “bar” This however works just fine:

Re: [lldb-dev] Inconsistencies in CIE pointer in FDEs in .debug_frame

2019-11-25 Thread Pavel Labath via lldb-dev
On 25/11/2019 10:46, Martin Storsjö wrote: On Mon, 25 Nov 2019, Pavel Labath wrote: On 24/11/2019 23:16, Martin Storsjö via lldb-dev wrote: Hi, I'm looking into something that seems like an inconsistency in handling of the CIE pointer in FDEs in .debug_frame, between how debug info is

Re: [lldb-dev] The pre-built Windows LLDB binary has a dependency on an external python36.dll?

2019-11-21 Thread Pavel Labath via lldb-dev
On 22/11/2019 01:26, Adrian McCarthy wrote: Yes, that sounds plausible, but I don't recall for sure.  I think there's a build-time option to say you don't want Python at all, but I can't remember if there was a load-as-needed option. I'm pretty sure we have never had explicit support for

Re: [lldb-dev] help, how to get a debug build on windows (python37_d.lib)

2019-09-23 Thread Pavel Labath via lldb-dev
On 22/09/2019 20:20, Larry D'Anna via lldb-dev wrote: Hi lldb-dev. I can’t seem to figure out how to build a debug lldb on windows.   It wants to link against a debug version of Python, which isn’t there. My cmake line looks like this: cmake -G Ninja `         "-DPYTHON_HOME=C:\Program

Re: [lldb-dev] RFC: full support for python files, and avoid using FILE* internally

2019-09-23 Thread Pavel Labath via lldb-dev
On 20/09/2019 17:35, Larry D'Anna via lldb-dev wrote: Hi lldb-dev. I want to be able to use LLDB inside of iPython, so I can have mixed python and LLDB debug session. To this end, I’d like to update LLDB to have full support for python file objects, so the outputs of debugger commands can

Re: [lldb-dev] [RFC] Adding a clang-style LLVM.h (or, "Are you tired of typing 'llvm::' everywhere ?")

2019-10-08 Thread Pavel Labath via lldb-dev
On 08/10/2019 02:45, Larry D'Anna via lldb-dev wrote: Pavel Labath said some llvm classes, are so well-known and widely used, that qualifying them with "llvm::" serves no useful purpose and only adds visual noise. I'm thinking here mainly of ADT classes like String/ArrayRef, Optional/Error,

Re: [lldb-dev] [llvm-dev] Continuing from dbgtrap on different targets

2020-03-04 Thread Pavel Labath via lldb-dev
On 04/03/2020 21:45, Jim Ingham via llvm-dev wrote: > As you have seen, different machine architectures do different things after > hitting a trap. On x86_64, the trap instruction is executed, and then you > stop, so the PC is left after the stop. On arm64, when execution halts the > pc is

Re: [lldb-dev] Odd behavior with Python on Windows (loading 2 copies of liblldb.dll/_lldb.pyd)

2020-02-24 Thread Pavel Labath via lldb-dev
On 21/02/2020 23:32, Ted Woodward via lldb-dev wrote: > Looking into differences, I’m using swig 3.0.12 and the bot is using > swig 3.0.2. I’m building with 3.0.2 on my machine right now, but it will > take a while to finish! I think this could very likely be the cause. We use a different

Re: [lldb-dev] gdb-remote protocol questions

2020-01-28 Thread Pavel Labath via lldb-dev
On 27/01/2020 19:43, Alexander Zhang via lldb-dev wrote: > Hi, > > Thanks for pointing me towards stack unwinding. I don't have debug > information much of the time, so I'm depending on the architecture rules > for backtracing. A look at the mips ABI plugin shows it uses dwarf > register numbers

Re: [lldb-dev] How to tell if an address belongs to the heap?

2020-02-06 Thread Pavel Labath via lldb-dev
In general, getting this kind of information is pretty hard, so lldb does not offer you an out-of-the-box solution for it, but it does give you tools which you can use to approximate that. If I wanted to do something like this, the first thing I'd try to do is run "image lookup -a 0xaddr". If

Re: [lldb-dev] How to tell if an address belongs to the heap?

2020-02-07 Thread Pavel Labath via lldb-dev
Thanks for the explanation, Vangelis. It sounds like binary instrumentation would be the best approach for this, as this is pretty much exactly what msan does. If recompilation is not an option, then you might be able to get something to work via lldb, but I expect this to be _incredibly_ slow

Re: [lldb-dev] LLDB problem about building with Python

2020-03-12 Thread Pavel Labath via lldb-dev
On 12/03/2020 10:50, Rui Hong via lldb-dev wrote: > Hi LLDB devs, > > I'm working on porting LLDB to my own architecture. > I choose to use the target-definition-file(python) to let LLDB support > my architecture based on my situation(already have a workable GDB-stub > and the target is an

Re: [lldb-dev] [RFC] Upstreaming Reproducer Capture/Replay for the API Test Suite

2020-04-07 Thread Pavel Labath via lldb-dev
Hi Jonas, Davide, I am not exactly thrilled by the ever-growing number of "modes" our test suite can be run in. However, it seems that's a battle I am destined to loose, so I'll just repeat what I've been saying for some time now. I don't believe that either of these funny "modes" should be the

Re: [lldb-dev] Saving and restoring STDIN in the ScriptInterpreter

2020-04-07 Thread Pavel Labath via lldb-dev
Hi Davide, I believe your guess about background processes is correct. I think that the lldb process is stopped (or is continually getting stopped and restarted) by SIGTTOU. Macro: int SIGTTOU This is similar to SIGTTIN, but is generated when a process in a background job attempts to

Re: [lldb-dev] Default script language

2020-04-02 Thread Pavel Labath via lldb-dev
+1 for making this a cmake option. That said, I don't think we can implement this using #ifdefs. lldb-enumerations.h is a part of our public api, Config.h isn't (it theoretically could be, but I don't think we want that). I think the simplest way to achieve this would be to make

Re: [lldb-dev] How to associate a bug and CL?

2020-03-26 Thread Pavel Labath via lldb-dev
On 26/03/2020 00:36, Emre Kultursay via lldb-dev wrote: > llvm-project dev noob here. > > I opened a Bug  and have > some CLs  to fix them. How do I link > the CL with the bug so that the code reviewer sees what bug I'm

Re: [lldb-dev] Is there a just-my-code like debugging mode for LLDB?

2020-05-11 Thread Pavel Labath via lldb-dev
Hi Emre, I have to say I'm pretty sceptical about this approach, for all the reasons that Jim already mentioned. Making it so that lldb pretends the other shared libraries don't exist (which is what I assume your prototype does) is fairly easy, but it does create a very long tail of "feature X

Re: [lldb-dev] Is there a just-my-code like debugging mode for LLDB?

2020-05-14 Thread Pavel Labath via lldb-dev
On 14/05/2020 03:50, Emre Kultursay via lldb-dev wrote: > One thing I want to try is "settings set > plugin.process.gdb-remote.use-libraries-svr4 true". Isn't that the default? The reason this setting was added was so we could test the !svr code path without forcibly disabling xml support (and

Re: [lldb-dev] Is there a just-my-code like debugging mode for LLDB?

2020-05-14 Thread Pavel Labath via lldb-dev
On 14/05/2020 11:56, Jaroslav Sevcik wrote: > > The svr4 support seems to be off by > default:  > https://github.com/llvm/llvm-project/blob/2974b3c566d68f1d7c907f891137cf0292dd35aa/lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemoteProperties.td#L14 > > It would definitely make sense to turn

Re: [lldb-dev] Pre-merge lldb testing

2020-05-19 Thread Pavel Labath via lldb-dev
I believe pre-merge testing would be very useful. The thing which I would find very useful (let's call it a feature request) is to be able to get some sort of an overview/dashboard of all the runs on this infrastructure and their results. It doesn't have to be super detailed -- the question which

Re: [lldb-dev] RFC: Processor Trace Support in LLDB

2020-10-02 Thread Pavel Labath via lldb-dev
On 01/10/2020 22:32, Walter wrote: > After a chat with Greg, we agreed on this set of commands > > > trace load /path/to/json process trace start/stop process trace save > /path/to/json thread trace start/stop thread trace dump [instructions | > functions] > Thanks. The new commands look good

Re: [lldb-dev] lldb 11.0.0-rc2 different behavior then gdb.

2020-10-07 Thread Pavel Labath via lldb-dev
On 07/10/2020 21:01, Jim Ingham wrote: On Oct 7, 2020, at 11:44 AM, Pavel Labath > wrote: On 07/10/2020 20:42, Jim Ingham via lldb-dev wrote: There isn’t a built-in summary formatter for two dimensional arrays of chars, but the type is matching the regex for the

Re: [lldb-dev] lldb 11.0.0-rc2 different behavior then gdb.

2020-10-07 Thread Pavel Labath via lldb-dev
On 07/10/2020 20:42, Jim Ingham via lldb-dev wrote: There isn’t a built-in summary formatter for two dimensional arrays of chars, but the type is matching the regex for the one-dimensional StringSummaryFormat, but that doesn’t actually know how to format two dimensional arrays of chars.  The

Re: [lldb-dev] Deadlock loading DWARF symbols

2020-10-05 Thread Pavel Labath via lldb-dev
On 02/10/2020 23:13, Greg Clayton wrote: Yes this is bad, and GetDescription() is used as a convenience to print out the module path (which might be a .o file within a .a file) and optionally architecture of the module. It probably shouldn't be taking the module lock as the only member

Re: [lldb-dev] LLDB got SIGCHLD on hitting the breakpoint

2020-09-29 Thread Pavel Labath via lldb-dev
When you say "execute binary code", where exactly is this code being executed? Is it executed by launching another process? Lldb will not automatically debug all child process spawned by your process -- they will run freely. The SIGCHLDs are not coming from lldb -- they are signals which all

Re: [lldb-dev] RFC: Processor Trace Support in LLDB

2020-10-01 Thread Pavel Labath via lldb-dev
Thank you for writing this Walter. I think this document will be a useful reference both now and in the future. The part that's not clear to me is what is the story with multi-process traces. The file format enables those, but it's not clear how are they going be created or used. Can you

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

2020-10-20 Thread Pavel Labath via lldb-dev
There's a lot of things that are unclear to me about this proposal. The mechanics of representing an segmented address are one thing, but I I think that the really interesting part will be the interaction with the rest of lldb. Like - What's going to be the source of this address space

Re: [lldb-dev] RFC: -flimit-debug-info + frame variable

2020-07-21 Thread Pavel Labath via lldb-dev
On 20/07/2020 23:25, Jim Ingham wrote: > It seems like you are having to work hard in the ValueObject system because > you don’t want to use single AST Type for the ValueObject’s type. Seems like > it be much simpler if you could cons up a complete type in the > ScratchASTContext, and then use

Re: [lldb-dev] Break setting aliases...

2020-07-22 Thread Pavel Labath via lldb-dev
I use "b" for file+line breakpoints and "br set -n" for function breakpoints, mainly because I couldn't be bothered to figure out how that works with the "b" command. Now that I have studied the command once again, I may try using it for function breakpoints as well... I don't have any hard

Re: [lldb-dev] Deprecating Python2 and adding type-annotations to the python API

2020-08-11 Thread Pavel Labath via lldb-dev
On 04/08/2020 02:37, Jonas Devlieghere via lldb-dev wrote: > Hi Nathan, > > Thanks for bringing this up. I've been expecting this question for a > while now.  > > Python 2 is end-of-life and we should move to Python 3. I'm pretty sure > nobody here disagrees with that. Unfortunately though, we

Re: [lldb-dev] Break setting aliases...

2020-07-23 Thread Pavel Labath via lldb-dev
On 22/07/2020 19:50, Jim Ingham wrote: >> On Jul 22, 2020, at 12:34 AM, Pavel Labath wrote: >> >> The "--" is slightly unfortunate, but it's at least consistent with our >> other commands taking raw input. We could avoid that by making the >> command not take raw input. I think most of the

Re: [lldb-dev] RFC: -flimit-debug-info + frame variable

2020-07-23 Thread Pavel Labath via lldb-dev
On 22/07/2020 01:31, Jim Ingham wrote: > > >> On Jul 21, 2020, at 9:27 AM, Pavel Labath > > wrote: >> I do see the attractiveness of constructing of a full compiler type. The >> reason I am hesitant to go that way, because it seems to me that this >> would negate the two

[lldb-dev] RFC: -flimit-debug-info + frame variable

2020-07-20 Thread Pavel Labath via lldb-dev
Hello all, With the expression evaluation part of -flimit-debug-info nearly completed, I started looking at doing the same for the "frame variable" command. I have thought this would be simpler than the expression evaluator, since we control most of that code. However, I have hit one snag, hence

Re: [lldb-dev] Remote connection expansion?

2020-11-18 Thread Pavel Labath via lldb-dev
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

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

2020-11-02 Thread Pavel Labath via lldb-dev
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] [RFC] Improving protocol-level compatibility between LLDB and GDB

2021-04-27 Thread Pavel Labath via lldb-dev
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'

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

2021-02-09 Thread Pavel Labath via lldb-dev
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,

Re: [lldb-dev] Removing linux mips support

2021-03-30 Thread Pavel Labath via lldb-dev
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

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

2021-03-30 Thread Pavel Labath via lldb-dev
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

[lldb-dev] Removing linux mips support

2021-03-09 Thread Pavel Labath via lldb-dev
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

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

2021-04-21 Thread Pavel Labath via lldb-dev
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

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

2021-02-04 Thread Pavel Labath via lldb-dev
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] Duplicate use of "sp" register name on x86 targets

2021-09-06 Thread Pavel Labath via lldb-dev
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

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

2021-09-06 Thread Pavel Labath via lldb-dev
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

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

2021-10-08 Thread Pavel Labath via lldb-dev
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

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

2021-10-08 Thread Pavel Labath via lldb-dev
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

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

2021-10-06 Thread Pavel Labath via lldb-dev
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

[lldb-dev] Semantics of SBValue::CreateChildAtOffset

2021-10-22 Thread Pavel Labath via lldb-dev
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; };

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

2021-12-06 Thread Pavel Labath via lldb-dev
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

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

2021-11-24 Thread Pavel Labath via lldb-dev
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:02AM +

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

2021-10-29 Thread Pavel Labath via lldb-dev
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

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

2021-10-29 Thread Pavel Labath via lldb-dev
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 already

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

2021-10-28 Thread Pavel Labath via lldb-dev
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

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

2021-11-05 Thread Pavel Labath via lldb-dev
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

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

2021-11-05 Thread Pavel Labath via lldb-dev
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] The two PDB plugins in LLDB

2021-11-03 Thread Pavel Labath via lldb-dev
[+ 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

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

2021-11-03 Thread Pavel Labath via lldb-dev
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

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

2021-10-29 Thread Pavel Labath via lldb-dev
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] Adding support for FreeBSD kernel coredumps (and live memory lookup)

2021-12-14 Thread Pavel Labath via lldb-dev
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

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

2022-01-12 Thread Pavel Labath via lldb-dev
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

2022-01-16 Thread Pavel Labath via lldb-dev
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

[lldb-dev] Multiple platforms with the same name

2022-01-17 Thread Pavel Labath via lldb-dev
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

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

2022-01-28 Thread Pavel Labath via lldb-dev
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

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

2022-01-20 Thread Pavel Labath via lldb-dev
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

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

2022-01-19 Thread Pavel Labath via lldb-dev
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] Multiple platforms with the same name

2022-01-19 Thread Pavel Labath via lldb-dev
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,

<    1   2   3   4   5