Yes, that looks like a bug. Inheriting the target environment in the
default case sounds like a good thing to do. I had a feeling it used
to work at some point, but I could be wrong...
On 6 July 2017 at 05:04, Christopher Book via lldb-dev
wrote:
> Yes, exactly. So things like LD_LIBRARY_PATH, P
Hi Gustavo,
I don't see anything which should prevent you from doing that.
Probably the first place you should look at is
"source/Plugins/Process/Linux/NativeRegisterContext_***". This is the
thing which defines what a "register" is and how to read/write it, and
it's the main thing you will need
https://bugs.llvm.org/show_bug.cgi?id=25785
lab...@google.com changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
Hi Pavel,
> -Original Message-
> From: Pavel Labath [mailto:lab...@google.com]
> Sent: quinta-feira, 6 de julho de 2017 07:13
> To: Gustavo Serra Scalet
> Cc: lldb-dev@lists.llvm.org
> Subject: Re: [lldb-dev] Port LLDB to ppc64le (ABIv2) on linux
>
> Hi Gustavo,
>
> I don't see anything
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, I'm remote debugging to linux (from windows), and I'm trying to launch
a binary that already exists on both the client and target machines.
Regardless of what I do, it always wants to transfer the (very large)
executable to the remote machine and run it. Is there a way to avoid this?
I'm runn
Hi,
> -Original Message-
> From: Howard Hellyer [mailto:hhell...@uk.ibm.com]
> Sent: quinta-feira, 6 de julho de 2017 09:59
> To: Gustavo Serra Scalet
> Cc: lldb-dev@lists.llvm.org
> Subject: Re: [lldb-dev] Port LLDB to ppc64le (ABIv2) on linux
>
> Hi Gustavo,
>
> Were you interested in
> > 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
I'm not actually too sure of the compatibility situation between Python
versions, but I think forcing a user to install a Python 3.5.x version is
quite reasonable for LLDB use.
I can also upstream this if the community is interested.
Ted if you have a patch to fix the scripting feature for LLD