I'm working on a plugin for lldb and need to scan the memory of a crashed
process. Using the API to read chunks of memory and scan (via
SBProcess::Read*) for what I'm looking for is easy but I haven't been able
to find a way to find which address ranges are accessible. The
SBProcess::Read* call
t; I would love to see this functionality exported through our public
> API. Let me know if you are up for making a patch. If you are, you
> might want to quickly read the following web page to see the rules
> that we apply to anything going into our public API:
>
> http://lldb.llv
Apologies, I don't mean either of those.
This was working on a debug tool for the IBM JVM. When we added the MiniDumpWithFullMemoryInfo to our calls to MiniDumpWriteDump we found it inserted blank ranges to keep the regions in the MINIDUMP_MEMORY_INFO_LIST structure contiguous. I checked a dump j
a large section.
>
> Are you saying that's a bug in the minidump itself or in LLDB's
> handling of it? If the latter, please send me the details (e.g.,
> which flags trigger this behavior), and I'll see what I can do about it.
>
> Adrian.
>
> On Fri, May 13,
>> - Using GetMemoryRegionInfo to iterate might be quite expensive if
there are many small memory regions.
>
> Remember that the other use for GetMemoryRegionInfo() might be a user
just asking about an address they have in a register or variable that is a
pointer. So if we do add a more complex
I've been trying to understand why some Linux core files fail to load in
lldb.
The problem seems to be that in the ELF header Linux uses the
ELFOSABI_NONE (0x0) value rather than ELFOSABIT_LINUX (0x3).If I either
change the e_ident[EI_OSABI] byte to 0x3 in the header or the code in
ArchSpec.cp
> I would change it so that the "os" doesn't get set to anything when
> it detects this in the core file. When an OS is not specified, the
> llvm::Triple will return OSUnknown as the enumeration value for the
> OS _and_ the llvm::StringRef value will return an empty string. This
> is known in LL
"Ted Woodward" wrote on 22/08/2016 21:03:02:
> We don't want to make ELFOSABI_NONE mean Linux. ELFOSABI_NONE is
> historically ELFOSABI_SYSV, and used by a lot of things. So not all
> core files identified as ELFOSABI_NONE are Linux.
I agree that other OS's may use it or have used it in the p
Todd Fiala wrote on 25/08/2016 20:42:31:
> FWIW, I've taken a few whacks at getting Linux detected better over
> the last few years, and haven't yet found a reliable way to detect
> it from quite a few samples of cores from a number of different
> systems. We can spend more time looking into
"Ted Woodward" wrote on 26/08/2016 16:17:18:
> That works fine for host debug, but not so much for embedded. On
> Hexagon, we support 2 OS cases – standalone (which means no OS, or
> an OS that lldb doesn’t know anything about) and Linux. Both our
> standalone simulator and our Linux generate
I've been hitting a hang when lldb loads some core dumps created on Linux,
generally those created via gcore.
I found an open bug for this here:
https://llvm.org/bugs/show_bug.cgi?id=26322
and the fix that was suggested there still works. (The patch needs some
tidying up due to the code formatti
Hi Jim
I was afraid someone would say that but I've done some digging and found a
difference in the core files I get generated by gcore to those generated
by a crash or abort.
Most of the core files have one SIGINFO structure in the core, I think it
belongs to the preceding thread (the one tha
-dev@lists.llvm.org
> Date: 11/11/2016 18:07
> Subject: Re: [lldb-dev] LLDB hang loading Linux core files from live
> processes (Bug 26322)
>
> I think both are valid fixes. Threads in core files can have a non-
> zero signal. See comments below.
>
> > On Nov 11,
Hi,
I’ve been hitting issues connecting to lldb-server. I’ve been trying from
Mac to Linux running in a Virtual Box VM on the same machine. Once I’ve
created a target and issued the “run” command lldb immediately disconnects
with “error: connect remote failed (failed to get reply to handshake
Greg Clayton wrote on 16/02/2017 17:17:41:
> Sounds like a race condition we need to solve.
It seemed likely but I thought I'd confirm that before I investigated too
deeply just in case there was anything obvious I'd missed.
> This sounds like a very common VM issue. If you can elaborate on
Greg Clayton wrote on 16/02/2017 17:17:41:
> this is just the first packet we send after sending the "ack" down
> to the remote server. When we send the "ack", we don't need a
> response, then we send the "QStartNoAckMode" packet and actually
> wait for a response. If we don't get one, then w
Greg Clayton wrote on 16/02/2017 17:17:41:
> We seem to have a race condition here. Any help figuring out what
> that might be would be great.
I think I've now identified the problem.
Normally in lldb-server when the child lldb-server process is launched
inside GDBRemoteCommunication::StartDe
I'm building an lldb plugin on Mac OS X and Linux using the SB API. This
means downloading the right headers to build against for the level of lldb
installed on the machine building the plugin.
On Linux it is trivial to work out which lldb headers to build against,
you just run lldb -version an
Hi Gustavo,
Were you interested in support for live debugging via ptrace or reading
from core files? (Or both!)
I did have a look at what it would take to add support for Power PC little
endian core files. I didn't seem too bad as the existing code for PPC 64
support just needed to be aware of
> > Hi Gustavo,
> >
> > Were you interested in support for live debugging via ptrace or
reading
> > from core files? (Or both!)
>
> Mainly live debugging, but I have the feeling that implementing
> post-mortem wouldn't be such a hassle afterwards. (register read/
> write, stack walk... they wou
"lldb-dev" wrote on 24/07/2017 16:19:19:
> From: Mark Nelson via lldb-dev
> To: lldb-dev@lists.llvm.org
> Date: 24/07/2017 16:19
> Subject: [lldb-dev] Remote debugging - unix socket and/or specific port
> Sent by: "lldb-dev"
>
> Has there been any change in this since reported here :
>
> http
21 matches
Mail list logo
