The driver used to have a bunch of lldb_private stuff in it, mostly to run the
event loop, which Greg abstracted into SB API’s a while ago. If it can be
avoided, I’d rather not add it back in. Our claim is folks should be able to
write their own debugger interfaces (command line or gui) using
The only similar case we ran into was a situation where our kernel was playing
tricks and essentially re-loading a module at the same location. So what would
happen is:
1 - kernel would load a.out's .text section at 0x1
2 - LLDB would notice via a module loaded notification and would set a
If I were writing a Pure Python interface to lldb, could I use the Python
signal facilities to abstract the functionality you are trying to abstract
through Host::Signal? If so, then I’d have no objection to only doing it in
the C++ API’s (maybe with a note to that effect in the headers.)
If n
Please file bugs where the lldb implementation of the MI doesn't support
features documented in the GDB MI documentation.
Jim
> On Mar 16, 2016, at 11:01 AM, RISHABH GUPTA via lldb-dev
> wrote:
>
> 2.-var-update command ,In GDB/MI "-var-update *" works fine but the same
> command in LLDB/MI
Seems like the crashes happens because of abi::__cxa_demangle() for mangled
symbol name "
_ZNSt9_Any_data9_M_accessIPPZN5folly6fibers12FiberManager16runInMainContextIZN8facebook8memcache15CacheClientImplINS6_17CControllerCommonINS1_7dynamic11multiOpSyncINS6_11McOperationILi11EEESt6vect
".
This
I have a simulator for a custom ["toy"] CPU running on Linux, to which I
want to add at least basic debugging support (e.g. stepping instructions,
reading/writing registers and memory), then driving this from lldb over a
local TCP socket.
I could implement this as a custom socket server handling t
The cxa_demangle implementation definitely consumes stack aggressively,
especially when compiled -O0. I’d definitely recommend an 8MB+ stack for any
thread that may wind up demangling arbitrary C++ symbols. The new “fast
demangler” is much more conservative with stack space but doesn’t yet sup
> On Mar 17, 2016, at 5:01 AM, Tyro Software via lldb-dev
> wrote:
>
> I have a simulator for a custom ["toy"] CPU running on Linux, to which I want
> to add at least basic debugging support (e.g. stepping instructions,
> reading/writing registers and memory), then driving this from lldb over
On Wed, Mar 16, 2016 at 10:13 PM, Ted Woodward
wrote:
> Hi Rishabh,
>
>
>
Hi Ted,
> It looks like you’re trying to use lldb commands when running lldb-mi.
> lldb-mi is the gdb-mi command layer on top of lldb, primarily used by tools
> like Eclipse to talk to lldb or gdb using a similar command s
Dear all,
as a follow-up, are there any plans to make lldb support CUDA, OpenCL or
SPIR-V based platforms in the near future?
Best,
P
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Anything exception that is done by the implementation in order to implement
normally stopping at the entry point should be covered up and not sent to the
user. A thread has the notion of a private stop info and one that is produced
for the public consumption. If this exception is indeed only sho
Sounds like something is going wrong when resolving the address. I am guessing
that your sections got unloaded when you attached to your GDB remote target. So
try this:
(lldb) file u:\lldb_test\dlopen
Current executable set to 'u:\lldb_test\dlopen' (hexagon).
(lldb) target modules load -f dlopen
FWIW all the debuggers that people normally use on windows show it this way
as well. The reason is that by default, if you do nothing and simply
launch a program under a debugger, you hit a breakpoint. There's no way to
avoid it, it's done by the loader at the OS level. If someone doesn't want
t
Hi Rishabh,
It looks like you’re trying to use lldb commands when running lldb-mi. lldb-mi
is the gdb-mi command layer on top of lldb, primarily used by tools like
Eclipse to talk to lldb or gdb using a similar command set. These commands are
documented here: https://sourceware.org/gdb/onlin
On many platforms (OS X for sure) there’s no guarantee that when you stop you
will only have hit one breakpoint on one thread. On OS X in multithreaded
programs, it is not at all uncommon to have many threads hit breakpoint(s) by
the the time the stop gets reported. So you just have to iterate
The code that has gotten itself into an infinite loop here is the libiberty
cp-demangle.c, which is part of the C++ runtime libraries for the system you
are on. So we can't do anything to fix bugs with that. You might make sure
there isn't a newer version of that than the one on your system, b
Note this would also fix several longstanding warnings when compiling on
windows that there's really no other way to fix.
On Fri, Mar 18, 2016 at 10:19 AM Zachary Turner wrote:
> Is it ok to add a public API that isn't interfaced to Python? In this
> case the culprit is the signal() function.
> On Mar 18, 2016, at 9:54 AM, Zachary Turner via lldb-dev
> wrote:
>
> I notice everything uses SB classes only. Is this a hard requirement?
I would prefer to try and get all of our tools to use the public API if at all
possible and avoid pulling in lldb_private stuff for things like "lld
All this logic is handled in Process::HandleProcessStateChangedEvent (see
around line 1215 in Process.cpp) You shouldn’t have to reimplement the logic
for setting the selected thread unless you don’t like our heuristics. Note,
that’s in generic code, so I don’t know why it wouldn’t be working
I notice everything uses SB classes only. Is this a hard requirement? We
have a bit of cruft in all of the top-level executables (lldb-server,
lldb-mi, lldb) that could be shared if we could move it into Host, but then
the 3 drivers would have to #include "lldb/Host/Host.h". Note that lldb-mi
an
The cxa_demangle implementation definitely consumes stack aggressively,
especially when compiled -O0. I’d definitely recommend an 8MB+ stack for any
thread that may wind up demangling arbitrary C++ symbols. The new “fast
demangler” is much more conservative with stack space but doesn’t yet sup
> On Mar 16, 2016, at 3:34 PM, Zachary Turner wrote:
>
> Hi Greg,
>
> could you clarify the difference between the functions ParseTypes,
SymbolFile::ParseTypes() is only used for debugging, don't worry about this one
unless you need a way to say "parse all types in the supplied context". It c
Ok, sounds like there is platform level precedence to support this flow and
things should stay this way to keep Windows user experience consistent with
other debuggers. Thanks for the info.
Greg
> On Mar 18, 2016, at 11:42 AM, Zachary Turner wrote:
>
> FWIW all the debuggers that people norma
https://llvm.org/bugs/show_bug.cgi?id=26978
Bug ID: 26978
Summary: LLDB stack overflow while dealing with symbols for a
process on Linux
Product: lldb
Version: 3.8
Hardware: PC
OS: Linux
Status:
Thanks Jim. This is very helpful.
We have double checked the libiberty we are building against which seems
already be updated two weeks ago so this bug might not been fixed yet.
Rebuilding LLDB_USE_BUILTIN_DEMANGLER fixed this stack overflow.
Questions:
1. Any reason LLDB_USE_BUILTIN_DEMANGLER is
Not all platforms use the same C++ name mangling. Clang follows the Itanium
ABI specification which is what both the built-in LLDB demanglers understand.
Kate Stone k8st...@apple.com
Xcode Low Level Tools
> On Mar 18, 2016, at 3:50 PM, Jeffrey Tan via lldb-dev
> wrote:
>
> Thanks Jim. This
> On Mar 18, 2016, at 10:20 AM, Zachary Turner via lldb-dev
> wrote:
>
> Is it ok to add a public API that isn't interfaced to Python? In this case
> the culprit is the signal() function. Windows doesn't really support signal
> in the same way that other platforms do, so there's some code i
So you will need to find out who is sliding the shared library incorrectly. It
might be a packet that is received through the GDB remote protocol, so there
might be a bug in your GDB server.
Greg
> On Mar 18, 2016, at 11:45 AM, Ted Woodward
> wrote:
>
> Your guess is right - the sections mov
I don't see anything in the packet log that would cause the change. Most of the
interesting packets (like qShlibInfoAddr, qProcessInfo or qHostInfo) return an
empty reply.
Where should I set a breakpoint to see the load addresses moving?
--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovati
Is it ok to add a public API that isn't interfaced to Python? In this case
the culprit is the signal() function. Windows doesn't really support
signal in the same way that other platforms do, so there's some code in
each driver that basically defines a signal function, and then if you're
unlucky
Hi Greg,
could you clarify the difference between the functions ParseTypes,
FindTypes, ResolveTypeUID, and CompleteType from the SymbolFile plugin?
On Mon, Mar 14, 2016 at 1:33 PM Zachary Turner wrote:
> Bleh, it looks like some abstraction will be needed at this level too,
> because ClangASTCo
On Wed, Mar 16, 2016 at 10:41 PM, Greg Clayton wrote:
>
> > On Mar 11, 2016, at 9:30 AM, RISHABH GUPTA via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> >
> > Hello all,
> >
> > I have started using LLDB/MI but there are some commands that are not
> working .I start the MI in terminal as "lldb-m
SectionLoadList::SetSectionLoadAddress() in SectionLoadList.cpp
> On Mar 18, 2016, at 1:54 PM, Ted Woodward wrote:
>
> I don't see anything in the packet log that would cause the change. Most of
> the interesting packets (like qShlibInfoAddr, qProcessInfo or qHostInfo)
> return an empty reply.
This is crazy. I tried 10MB, not working, then 20MB still not working. I
got around 80K frames stack overflow, this is clearly an infinitely loop in
"d_print_comp":
(gdb) bt
#0 0x7f35925511e1 in d_print_comp (dpi=0x7f3586747c00, options=17,
dc=0x7f3586743bb0) at cp-demangle.c:4324
#1 0x7
Your guess is right - the sections moved. Before attaching:
0x0008 code [0x0003-0x00068d5c)
0x00011000 0x00038d5c 0x0006 dlopen..text
After attaching:
0x0008 code [0x0001-0x00048d5c)
0x00011000 0x00038d5c 0x0
ah yes! Disabling that fixed it. Thanks
Op 2016-03-18 om 19:29 schreef Zachary Turner:
Are you launching the process with -s (stop at entry)?
On Fri, Mar 18, 2016 at 11:24 AM Carlo Kok via lldb-dev
mailto:lldb-dev@lists.llvm.org>> wrote:
When starting a process on Win32 there's an internal
36 matches
Mail list logo
