Hi everyone,
I have lldb crashing since I've updated to lldb9. Seems like there is a
issue with python3.5. Everything seems to work fine with python3.7.
Am I missing something? Or is it a known issue?
$ lldb
(lldb) script
#0 0x7f3d324c9c2a llvm::sys::PrintStackTrace(llvm::raw_ostream&)
(/hom
Hi everyone,
I'm trying to have my lldb-server to print a message, but in the terminal
of the lldb (client) it is connected with. Is it possible?
My lldb-server and the client are connected through the gdb-remote Plugin.
Thanks,
Romaric
___
lldb-dev mai
Hi everyone,
I'm trying to run the test suite on lldb and I'm having some issues with
Python. I'm on branch 7.0.
When I build lldb, I've got a folder "python3.5/site-packages" generated.
So I believe that the build system found python3 in my environment.
But when I run the testsuite (using "ninja
ostArchitectureSupport" (
https://github.com/upmem/lldb/commit/d35bbb8376096fd3ab3047b1c5ec507c96731deb#diff-7a05d638d592248e1fbb10192911affbR298
)
Seems to work well for the moment.
Romaric
On Fri, Jul 12, 2019 at 11:11 PM Greg Clayton wrote:
>
>
> On Jun 18, 2019, at 7:08 A
53 PM Jim Ingham wrote:
> It looks like you don't have a DynamicLoader plugin that tells lldb where
> your binaries ended up in memory when the process ran. The [ADDRESS] means
> we are reading instructions from memory not from the on-disk binary.
>
> Jim
>
>
> > O
HI everyone,
I'm adding my architecture into lldb.
I'm having some trouble with the debug information on the stack frame.
LLDB is never displaying any source code. It seems that we I get in
"StackFrame::GetSymbolContext" "m_flags" is always set to "0x" but
my "m_sc" does not contains the i
Hello everyone,
I am trying to add a new architecture into LLDB.
My architecture is a accelerator with its own ISA for which we have a LLVM
backend (release 7.1).
I have started by creating a new NativeProcessProtocol for my architecture.
So I have a lldb-server that run on a x86, but which takes
: jnzid, 0x8020
>
> 0x8008: move r0, 0xff
>
> 0x8010: release r0, 0x0, nz, 0x8018
>
> 0x8018: subr0, r0, 0x1, pl, 0x8010
>
>
>
> Any ideas about it?
>
> Thanks,
>
> Romaric
>
>
>
> On Wed, Jun 12, 201
r your architecture. The call to
> Disassembler::FindPlugin fails.
>
> My guess is something in the call to MCDisasmInstance::Create in
> source/Plugins/Disassembler/llvm/DisassemblerLLVMC.cpp is failing. Step
> through that and make sure everything there is working.
>
Hi everyone,
I'm trying to have lldb being able to debug my architecture. It does it
well after loading my elf. But then I run it, stop it in middle, try to
disassemble and at that point it seems that I lost some information about
my architecture. lldb tries to disassemble it for x86, which in not
10 matches
Mail list logo