Re: [lldb-dev] how to attach to process with python scripting on lldb?
Try target.AttachToProcessWithID() instead of target.LaunchSimple(). LaunchSimple tells lldb to run, creating a new process, instead of attaching to an existing one. See the SBTarget Python documentation here: https://lldb.llvm.org/python_reference/lldb.SBTarget-class.html . You should also be able to attach using the lldb command line, then go into the scripting interface and get the debugger object with lldb.debugger . Or attach using debugger.HandleCommand() to run an lldb command from the scripting interface. Ted From: lldb-dev On Behalf Of Pi Pony via lldb-dev Sent: Wednesday, November 3, 2021 10:20 AM To: lldb-dev@lists.llvm.org Subject: [lldb-dev] how to attach to process with python scripting on lldb? WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros. Hello, I have been trying for some days to resolve a symbol of address using lldb python api but I haven't found how to do that. So I think that I need to attach to the PID using python but it's not working, I tried: target = lldb.debugger.FindTargetWithProcessID(71321) process = target.LaunchSimple(None, None, os.getcwd()) process.GetState() --> Returns 0 ... Why? So I could use the ResolveSymbolAddress function because if I attach it outside of scripting then I do not own the self – debugger object. I appreciate your help. ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [RFC] lldb integration with (user mode) qemu
> 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 port" platform you can sub in almost anything that talks GDB. > Having some mechanism to resolve ambiguities might also help with that. Cool, I figured someone would have thought about it on the ELF side. So as long as Linux remains the standout things work ok. Most importantly, the way it's currently handled doesn't contradict anything you want to do here. On Wed, 3 Nov 2021 at 10:34, Pavel Labath wrote: > > 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 include > > the other person, and it does have its ambiguities. > > > > What I was proposing is, if I was correct (which I wasn't) then having > > the user "platform select qemu-user" would solve things. (which it > > doesn't) > Great, thanks for clarifying. > > >> If we do have a prompt, then this may not be so critical, though I expect > >> that most users would still prefer it we automatically selected qemu. > > > > Seems reasonable to put qemu-user above remote-linux. Only claiming if > > qemu-user has been configured sufficiently. I guess architecture would > > be the minimum setting, given we can't find the qemu binary without > > it. > Yeah, I think we can start with that. > > > Is this similar in any way to how the different OS remote platforms > > work? For example there is a remote-linux and a remote-netbsd, is > > there enough information in the program file itself to pick just one > > or is there an implicit default there too? > This is actually one of the pain points in lldb. The overall design > assumes that you can precisely identify the platform(triple) that the > file is meant to be run on by looking at the object file. This is > definitely true on Apple platforms (where lldb originated) as even the > "simulator" binaries have their own triples. > > The situation is more fuzzy in the elf world. TTe *bsd oses have (and > use) a ELFOSABI_ constant to identify the binary. Linux uses > ELFOSABI_NONE even though there is a dedicated constant it could use > (there's probably an interesting story in there). This makes it hard to > positively identify a file as a linux binary, but we can mostly get away > with it because there's just one OS like that. Having some mechanism to > resolve ambiguities might also help with that. > > I'm also not sure how much do the OSes actually validate the contents of > the elf headers. I wouldn't be surprised if one could create "polyglot" > elf binaries that can run on multiple operating systems. > > > (I see that platform CreateInstance gets an ArchSpec but having > > trouble finding where that comes from) > It gets called from > TargetList::CreateTargetInternal->Platform::CreateTargetForArchitecture->Platform::Create. > There may be other callers, but I think this is the relevant one. > > pl ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] The two PDB plugins in LLDB
CC Nico On Wed, 3 Nov 2021, Pavel Labath wrote: [+ aleksandr] On 03/11/2021 09:18, Martin Storsjö via lldb-dev wrote: As far as I know, this is clearly the intended direction, but my understanding is also that the native PDB plugin isn't quite on the same functionality level yet. While that has been the intended direction all along, there has been very little progress made on this front in the last couple of years (D110172 is the only recent change in this direction). Yes, afaik the only one actively working on it changed jobs to work on something else. At this point, I'm not sure if anyone even knows what the missing functionality is. Obviously, this is not a good situation to be in. So, even if it is possible for Raphael to make progress here without actually deleting the DIA plugin, I'd still say we should at least start the process of its deprecation/removal. Sure, I guess that's the only practical way forward (and anybody interested in it can build an old version anyway). But it would indeed be great if someone who has a setup to actually use it (Aleksandr? Nico?) could at least try to test out both of them and enumerate what's expected to be working and what's not, in both of them. // Martin ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
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 include the other person, and it does have its ambiguities. What I was proposing is, if I was correct (which I wasn't) then having the user "platform select qemu-user" would solve things. (which it doesn't) Great, thanks for clarifying. If we do have a prompt, then this may not be so critical, though I expect that most users would still prefer it we automatically selected qemu. Seems reasonable to put qemu-user above remote-linux. Only claiming if qemu-user has been configured sufficiently. I guess architecture would be the minimum setting, given we can't find the qemu binary without it. Yeah, I think we can start with that. Is this similar in any way to how the different OS remote platforms work? For example there is a remote-linux and a remote-netbsd, is there enough information in the program file itself to pick just one or is there an implicit default there too? This is actually one of the pain points in lldb. The overall design assumes that you can precisely identify the platform(triple) that the file is meant to be run on by looking at the object file. This is definitely true on Apple platforms (where lldb originated) as even the "simulator" binaries have their own triples. The situation is more fuzzy in the elf world. TTe *bsd oses have (and use) a ELFOSABI_ constant to identify the binary. Linux uses ELFOSABI_NONE even though there is a dedicated constant it could use (there's probably an interesting story in there). This makes it hard to positively identify a file as a linux binary, but we can mostly get away with it because there's just one OS like that. Having some mechanism to resolve ambiguities might also help with that. I'm also not sure how much do the OSes actually validate the contents of the elf headers. I wouldn't be surprised if one could create "polyglot" elf binaries that can run on multiple operating systems. (I see that platform CreateInstance gets an ArchSpec but having trouble finding where that comes from) It gets called from TargetList::CreateTargetInternal->Platform::CreateTargetForArchitecture->Platform::Create. There may be other callers, but I think this is the relevant one. pl ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
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 propose we delete it and only keep the native PDB plugin in LLDB which seems far less work to maintain. As far as I know, this is clearly the intended direction, but my understanding is also that the native PDB plugin isn't quite on the same functionality level yet. I've been meaning to dive into it, try it out and see if there's something I could do help it along, but I haven't gotten to it, and I can't realistically take it on right now... While that has been the intended direction all along, there has been very little progress made on this front in the last couple of years (D110172 is the only recent change in this direction). At this point, I'm not sure if anyone even knows what the missing functionality is. Obviously, this is not a good situation to be in. So, even if it is possible for Raphael to make progress here without actually deleting the DIA plugin, I'd still say we should at least start the process of its deprecation/removal. pl ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] The two PDB plugins in LLDB
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 propose we delete it and only keep the native PDB plugin in LLDB which seems far less work to maintain. As far as I know, this is clearly the intended direction, but my understanding is also that the native PDB plugin isn't quite on the same functionality level yet. I've been meaning to dive into it, try it out and see if there's something I could do help it along, but I haven't gotten to it, and I can't realistically take it on right now... // Martin ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
