Thank you Jim! Sounds like this should work!
On 8/30/16, 8:45 AM, "jing...@apple.com on behalf of Jim Ingham"
wrote:
The "dsymForUUID" tool doesn't handle copying source files around - we tend
to just remote mount them. But we do include these keys in the return plist so
that lldb can au
Hello,
I'm having an issue setting breakpoints using lldb-mi.
I am trying to run a C++ program (which is itself a brainfsck interpreter),
compiled for MIPS32r6 using Clang, linked with lld, and am trying to use
lldb-mi as the debugger. I am using lldb-mi as my primary use for it is as
an in
This is my output from that:
https://paste.ee/p/iGKZr
Though I am admittedly unsure what I am looking for.
Michael
-Original Message-
From: jing...@apple.com [mailto:jing...@apple.com]
Sent: Tuesday, August 30, 2016 2:40 PM
To: Michael Kuklinski
Cc: Greg Clayton ; lldb-dev@lists.llvm.
The addresses for the two breakpoints are reported differently in your "break
list" output. The successful one is given as:
0x00013488
but the one that isn't sent is still given as:
MipsTest.bin[0x000134a0]
That's a file offset address, not a load address. It sounds like we don't know
where
Those are the same results I get - however, when actually attached to the
remote target, line 70 sends a Z0 packet, whereas line 72 sends absolutely
nothing, regardless of the order.
I am on LLDB revision 279920, and LLVM revision 279925.
Michael
-Original Message-
From: Greg Clayton [
I never see a Z0 or a Z1 packet for those addresses. Anything above Line 70, it
never tries to send a packet to my stub to indicate that it wishes to place a
breakpoint. I get the same behavior using -H that I do without. The system the
stub is attached to is an emulator, so there's absolutely n
I never see a Z0 or a Z1 packet for those addresses. Anything above Line 70, it
never tries to send a packet to my stub to indicate that it wishes to place a
breakpoint. I get the same behavior using -H that I do without. The system the
stub is attached to is an emulator, so there's absolutely n
https://llvm.org/bugs/show_bug.cgi?id=30192
Eugene Zelenko changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://llvm.org/bugs/show_bug.cgi?id=30191
Eugene Zelenko changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
"unresolved" means that we know what address we want to set a breakpoint at,
but for some reason can't. For instance, if you were using -H and ran out of
hardware breakpoints, then the subsequent breakpoints would never get resolved,
since we can't implement them.
Anyway, going from unresolved
> On Aug 30, 2016, at 7:33 AM, Howard Hellyer via lldb-dev
> wrote:
>
> "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
The "dsymForUUID" tool doesn't handle copying source files around - we tend to
just remote mount them. But we do include these keys in the return plist so
that lldb can automatically remap the source files from where they were at
build time to where they are at debug time. So if your symbol se
Seems to work for me just fine with your binary:
lldb /Volumes/work/gclayton/Downloads/MipsTest.bin
(lldb) target create "/Volumes/work/gclayton/Downloads/MipsTest.bin"
Current executable set to '/Volumes/work/gclayton/Downloads/MipsTest.bin'
(mipsr6el).
(lldb) break set -H -f Main.cpp -l 70
Brea
https://llvm.org/bugs/show_bug.cgi?id=11714
Tamas Berghammer changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
"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
Thanks a lot Greg for such a detailed response! Locating dSYM bundles is indeed
very similar and in fact, since it's probably more popular than inlined
symbols, it will have to be extended to look for symbols on a symbol server as
well.
The only reason I didn't consider Symbols.h initially was
Yes, Zachary, design does not have any platform constraints, as long as we have
a reliable way to identify a binary, which can always be arranged.
From: Zachary Turner
Sent: Friday, August 26, 2016 10:01:30 PM
To: Taras Tsugrii; lldb-dev@lists.llvm.org
Cc: Kevin
Hi Zachary, Peter
On 30/08/16 00:14, Zachary Turner via lldb-dev wrote:
Right, the existing version that is built and what you are using links
directly against a 2.7 libpython at compile time. So you would probably
need to build LLDB from source and tweak the build system to make it
possible to
https://llvm.org/bugs/show_bug.cgi?id=30192
Bug ID: 30192
Summary: Talking:1.800.681.7208 webrööt antivirus customer
service Phone number
Product: lldb
Version: unspecified
Hardware: PC
OS: Windows NT
https://llvm.org/bugs/show_bug.cgi?id=30191
Bug ID: 30191
Summary: ! ⫸! 1-80Ö-681-7208 ⫸ Webroot tech support
phone number USA⫸⫸
Product: lldb
Version: unspecified
Hardware: PC
OS: Windows NT
Hello,
I'm having an issue setting breakpoints using lldb-mi.
I am trying to run a C++ program (which is itself a brainfsck interpreter),
compiled for MIPS32r6 using Clang, linked with lld, and am trying to use
lldb-mi as the debugger. I am using lldb-mi as my primary use for it is as
an in
We don't have any immediate plans to make lldb work with python 3 on
linux. However, I would be willing to guide you through making that
work. As Zachary pointed out, it should be fairly simple, given that
it already works on windows.
I don't think you'll be able to avoid building your own copy of
I would definitely welcome more prolific usage of early returns, but I
don't think we can do that before the big reformat. At least some of
those changes will be pretty non-trivial and risky. I'd vote for
making these changes after the reformat. Hopefully the uglyness of the
code will also encourag
23 matches
Mail list logo
