(Peter and Stephen on CC since you've previously asked about this sort of thing)
This relates to https://reviews.llvm.org/D103626 and other recent
patches about non-address bits.
On AArch64 we've got a few extensions that use "non address bits".
These are bits beyond the (in most cases) 48 bit vi
Can you link to/provide the build commands you used? It will help in
the case this is not a simple issue.
> there is no embedded script interpreter in this mode.
Probably because it didn't find Python (and/or LUA but I don't have
experience with that). To find out why, try passing
"-DLLDB_ENABLE_
> 1. The (older) "full memory" coredumps that use an ELF container.
>
> 2. The (newer) minidumps that dump only the active memory and use
a custom format.
Maybe a silly question, is the "minidumps" here the same sort of
minidump as lldb already supports
(https://chromium.googlesource.com/breakpad/
> Right now, the idea is that when the kernel crashes, the developer can
> take the vmcore file use LLDB to look the kernel state up.
Thanks for the explanation. (FWIW your first email is clear now that I
read it properly but this still helped me :))
> 2) How to integrate "live kernel" support in
Can you give an example workflow of how these core files are used by a
developer? For some background.
Most of my experience is in userspace, the corefile is "offline" debug
and then you have "live" debug of the running process. Is that the
same here or do we have a mix since you can access some o
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 +, David Spickett via lldb-dev wrote:
> >>> I don't think it does. Or at least I'm not sure how do you
> 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 t
> 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 hav
> 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 remotely, but there it's kind of expecte
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
> (when running on a linux host) a linux executable would be claimed by both
> the qem
up. Your scheme
> seems reasonable to me. I see that "addressing_bits" is in the
> upstream qHostInfo but only in the RNBRemote, does that mean that
> upstream already uses this in some way? (presumably just for Apple
> platforms?)
>
> > I am working on a kernel patch
Hi Omar, welcome!
"Embedded Command Line Interface" is something I miss compared to GDB
so I'm looking forward to seeing what you come up with.
On Fri, 21 May 2021 at 09:31, Omar Emara via lldb-dev
wrote:
>
> Hi everyone,
>
> I was asked to share my accepted GSoC project in the appropriate maili
Thanks for the info.
If I get some time soon I can at least see what the current results
are with that updated module. If not I'll pitch in sometime after the
13 branch.
On Thu, 28 Jan 2021 at 17:52, Jonas Devlieghere wrote:
>
> Hey David,
>
> On Thu, Jan 28, 2021 at 2:46 AM D
I came across a minor bug writing some lldb-server tests where single
line diffs weren't handled correctly by unittest2. Turns out they are
in the latest version but the third_party/ version is older than that.
https://bugs.python.org/issue9174
https://hg.python.org/unittest2/rev/96e432563d53 (tho
t mean that
upstream already uses this in some way? (presumably just for Apple
platforms?)
> I am working on a kernel patch which will make this information available via
> siginfo, and once the tag becomes available from the kernel you shouldn't
> need to decode the instruction.
Great!
Hi all,
What follows is my proposal for supporting AArch64's memory tagging
extension in LLDB. I think the link in the first paragraph is a good
introduction if you haven't come across memory tagging before.
I've also put the document in a Google Doc if that's easier for you to
read:
https://doc
16 matches
Mail list logo
