Hi,
We are building an IDE debugger on top of lldb python API. In order to get
the source remapping work(the source path embedded in the symbol may be
different from the real source path), user needs to use "settings set
target.source-map" command to remap the source.
I would like users to do sim
Hi,
My colleague downloaded and built 3.7.1 version of lldb on Linux. When we
used it to attach to a normal process(like sleep), it just hangs forever:
bin/lldb -n sleep
(lldb) process attach --name "sleep"
And my private built 3.8.0 version works fine.
Just to confirm, is 3.7.1 a bad version?
Btw: here is the source that we built lldb from:
http://llvm.org/releases/download.html#3.7.1
direct link http://llvm.org/releases/3.7.1/lldb-3.7.1.src.tar.xz
On Mon, Jan 25, 2016 at 2:37 PM, Jeffrey Tan
wrote:
> Hi,
>
> My colleague downloaded and built 3.7.1 version of lldb on Linux. When we
Jan 25, 2016 at 4:12 PM, David Jones wrote:
> This is a known problem with 3.7.1.
>
> It should be fixed for 3.8. You should be able to try out 3.8rc1 right now.
>
>
>
> On Mon, Jan 25, 2016 at 5:37 PM, Jeffrey Tan via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
.
>>
>> It should be fixed for 3.8. You should be able to try out 3.8rc1 right
>> now.
>>
>>
>>
>> On Mon, Jan 25, 2016 at 5:37 PM, Jeffrey Tan via lldb-dev <
>> lldb-dev@lists.llvm.org> wrote:
>>
>>> Hi,
>>>
>>> M
Hi,
On mac OS, I am having difficulty understanding the launch debugger events
sequence of lldb. I used the following code to play around LLDB. I found,
for some binaries, debugger will enter stopped/paused mode, waiting for my
further input, print stack shows:
dbg> bt
* thread #1: tid = 0x15153e,
quot;stopped"
> >> event with a special "restarted" bit set (see
> >> SBProcess.GetRestartedFromEvent, and
> >> <http://lists.llvm.org/pipermail/lldb-dev/2016-January/009291.html>)
> >>
> >> hope that helps,
> >> pl
> >&g
gt;> >> that is why you get nondeterministic behavior. You should use the
>> >> SBTarget.Launch function to specify the listener from the start.
>> >>
>> >> The second problem is the handling of the Stopped events. Sometimes
>> >> LLDB needs
;> own listener, some of these events have already been broadcast, and
>>> >> that is why you get nondeterministic behavior. You should use the
>>> >> SBTarget.Launch function to specify the listener from the start.
>>> >>
>>> >> The second problem is the handlin
Hi,
Normally if you want to attach to a process you only have the pid/name of
the process. How do you get SBTarget? Am I supposed to call
SBDebugger.CreateTargetWithFileAndArch() against a dummy executable? Why do
we require a dummy SBTarget before attaching? This seems to be a wrong
design to me.
What event_mask should be used for the thread event class? I did not find
any. (Sorry for hijacking the thread)
On Fri, Jan 29, 2016 at 4:02 PM, Jim Ingham via lldb-dev <
lldb-dev@lists.llvm.org> wrote:
> It’s unclear to me why it would be a problem to listen to every thread
> object? They aren’
Never mind, found the thread event_mask in threads.h. They are just not in
the python API reference page.
On Sat, Jan 30, 2016 at 10:28 PM, Jeffrey Tan
wrote:
> What event_mask should be used for the thread event class? I did not find
> any. (Sorry for hijacking the thread)
>
> On Fri, Jan 29, 2
for the executable, and use that to attach (see
> > CommandObjectProcessAttach::DoExecute).
> >
> > BTW, if you find the existing API documentation too vague, we'd be
> > happy to accept any improvements.
> >
> > cheers,
> > pl
> >
> >
>
Hi,
I found that if I am using synchronous mode, some times there are no debug
events generated during launch. For example, for the code
below, LLDBListenerThread will receive no debug events.
Is this expected? What is the rule of debug events in synchronous mode?
def main():
debugger = lldb
, or
>> something else, you can check process.GetState() to find that out). No
>> need to play around with listeners...
>>
>> cheers,
>> pl
>>
>> On 4 February 2016 at 06:41, Jeffrey Tan via lldb-dev
>> wrote:
>>> Hi,
>>>
>>> I fo
Hi,
I am revising our lldb automation tests into async mode. However, I found
it randomly crashes depends on timing. And the crash happens mostly while
launching lldb twice in a row. I have narrowed down the code into a simple
repro below. Any assumption I made wrong with the LLDB API here?
The c
0x00010f83c144
> lldb::SBDebugger::Destroy(lldb::SBDebugger&) + 116
> 12 _lldb.so 0x00010f884daf
> _wrap_SBDebugger_Destroy(_object*, _object*) + 120
> 13 org.python.python 0x00010e53e75f PyEval_EvalFrameE
hread and listener thread, the race
condition seems to go away after running it 10 times in a loop. I will
integrate this logic into our unit test to see if it fixed the race crash.
On Fri, Feb 5, 2016 at 1:42 AM, Pavel Labath wrote:
> On 5 February 2016 at 05:09, Jeffrey Tan via lldb-dev
>
Hi,
I have been spending long time troubleshooting a race condition in our lldb
python test. I finally narrowed down to one code change that caused the
race: basically, whenever I store SBTarget in DebuggerTestCase's
self.target field lldb will randomly crash during destruction(see below).
In the
Hi,
I have got lldb launch working fine on my macbook for sometime. But when I
try the same code on Linux, it failed to emit any stopping events during
initial launch.
When I run the reproduce code(listed at the end), I got the following
different results:
The key difference is that Macbook will
> If the linux side is not obeying "stop_at_entry" then that is a bug.
>
> Jim
>
>
> > On Feb 23, 2016, at 1:49 PM, Jeffrey Tan via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> >
> > Hi,
> >
> > I have got lldb launch working fi
Hi,
I am trying to listen for module/symbol load/unload events and display them
in output UI so that debugger users can have a basic clue what is debugger
busy doing while launching a big executable linking many shared libraries.
Questions:
1. I did not find an API to get current load/unload modu
This is very useful, thanks for the info!
On Mon, Feb 29, 2016 at 10:36 AM, Jim Ingham wrote:
>
> On Feb 27, 2016, at 8:34 PM, Jeffrey Tan via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
> Hi,
>
> I am trying to listen for module/symbol load/unload events and dis
nfo!
>
> On Mon, Feb 29, 2016 at 10:36 AM, Jim Ingham wrote:
>
>>
>> On Feb 27, 2016, at 8:34 PM, Jeffrey Tan via lldb-dev <
>> lldb-dev@lists.llvm.org> wrote:
>>
>> Hi,
>>
>> I am trying to listen for module/symbol load/unload events and di
static lldb::SBTarget
> GetTargetFromEvent (const lldb::SBEvent &event);
>
> static uint32_t
> GetNumModulesFromEvent (const lldb::SBEvent &event);
>
> static lldb::SBModule
> GetModuleAtIndexFromEvent (const uint32_t idx, const lldb::SBEvent
> &e
Ingham wrote:
>>
>>>
>>> On Feb 27, 2016, at 8:34 PM, Jeffrey Tan via lldb-dev <
>>> lldb-dev@lists.llvm.org> wrote:
>>>
>>> Hi,
>>>
>>> I am trying to listen for module/symbol load/unload events and display
>>> th
s
> > Jeffrey
> >
> > On Mon, Feb 29, 2016 at 11:59 AM, Jeffrey Tan
> wrote:
> > This is very useful, thanks for the info!
> >
> > On Mon, Feb 29, 2016 at 10:36 AM, Jim Ingham wrote:
> >
> >> On Feb 27, 2016, at 8:34 PM, Jeffrey Tan via lldb-dev <
&
works.
>>>
>>> Can you send me your ELF file that contains the DWARF so I can look at
>>> it?
>>>
>>> > I think we should fix this full path matching issue. It is totally
>>> reasonable for debugger user to move source file from build location
e should have a
> complete path that works.
> >
> > Can you send me your ELF file that contains the DWARF so I can look at
> it?
> >
> > > I think we should fix this full path matching issue. It is totally
> reasonable for debugger user to move source file from bu
the DWARF using DW_AT_comp_dir.
> What should happen is your DWARF should have a compile unit like:
> > >
> > >
> > > 0x000b: DW_TAG_compile_unit [1] *
> > > DW_AT_producer( "Apple LLVM version 7.x.x" )
> > > DW_AT_language(
tr);
> > > >
> > > > To remove the redundant slashes and it might make things work. The
> thing that really worries me is that you still have a relative location in
> your sources:
> > > >
> > > >
> ".//
Hi,
In lldb, when I try to "target create [invalid_target]", I got some
meaningful error message like:
error: 'XXX' doesn't contain any 'host' platform architectures: x86_64h,
x86_64, i386
What is the python API to get this from? I tried to check
SBTarget.IsValid() and then use
SBTarget.GetDescri
t; So if you have an iOS binary that was targeting a device (not a
> simulator), you could create your target with:
>
> lldb::SBError error;
> lldb::SBTarget target = debugger.CreateTarget("/tmp/a.out",
> "armv7-apple-ios", "remote-ios", false, error);
>
Hi,
My colleague is trying to use our lldb IDE attaching to app run/build from
Xcode which failed. I can reproduce this with lldb console:
jeffreytan-mbp:$ ps aux | grep iOSApp
jeffreytan 61816 0.0 0.0 2432772676 s002 S+3:00PM
0:00.00 grep iOSApp
jeffreytan 61806 0.0 0.2
you built and are running with, and
> then we will fall back to using the one that is installed inside
> /Applications/Xcode.app as that one is Apple code signed.
>
> Greg
>
> > On Mar 9, 2016, at 3:04 PM, Jeffrey Tan via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
Thanks for the info Jim. That answers my questions. I will file a bug for
lldb error message.
On Wed, Mar 9, 2016 at 5:57 PM, Jim Ingham wrote:
>
> > On Mar 9, 2016, at 3:04 PM, Jeffrey Tan via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> >
> > Hi,
> >
&
Hi,
As the title said, what is the recommended way to attach a process under
different user account?
On Mac OS, when I try to use python binding to attach a root process, I got
a dialog saying "python is trying to take control of a root process ...".
After inputing password into the dialog, I got
Hi,
Our IDE(wrapping lldb using python) works fine on Linux for simple hello
world cases. While trying a real world case, I found whenever we set a
source line breakpoint, then trigger the code path, lldb will send a
stopped state process event, with thread.GetStopReason() being None and
with weir
Btw: the breakpoint I set is:
"b BigGrepMasterAsync.cpp:171" which is not in any of the stopped stack
frames.
On Fri, Mar 18, 2016 at 3:47 PM, Jeffrey Tan
wrote:
> Hi,
>
> Our IDE(wrapping lldb using python) works fine on Linux for simple hello
> world cases. While trying a real world case, I fo
>
> Jeffrey
>
>
> On Fri, Mar 18, 2016 at 4:12 PM, Jim Ingham wrote:
>
>> You only show one thread in your example. Did another thread have a
>> valid stop reason? lldb shouldn’t be stopping for no reason anywhere…
>>
>> Jim
>>
>> On Mar 18, 2
8, 2016, at 4:08 PM, Jeffrey Tan via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
> Btw: the breakpoint I set is:
> "b BigGrepMasterAsync.cpp:171" which is not in any of the stopped stack
> frames.
>
> On Fri, Mar 18, 2016 at 3:47 PM, Jeffrey Tan
> wrote:
&g
Seems like the crashes happens because of abi::__cxa_demangle() for mangled
symbol name "
_ZNSt9_Any_data9_M_accessIPPZN5folly6fibers12FiberManager16runInMainContextIZN8facebook8memcache15CacheClientImplINS6_17CControllerCommonINS1_7dynamic11multiOpSyncINS6_11McOperationILi11EEESt6vect
".
This
e any more luck. IIRC,
> FreeBSD uses the llvm one in favor of the libiberty one.
>
> Jim
>
>
> > On Mar 17, 2016, at 6:09 PM, Jeffrey Tan via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> >
> > This is crazy. I tried 10MB, not working, then 20MB still not
Xcode Low Level Tools
>
> On Mar 17, 2016, at 2:19 PM, Greg Clayton via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
> Make stacks bigger when making threads on linux?
>
> On Mar 17, 2016, at 1:
layton wrote:
> >>
> >> It is really up to the IDE to decide this so the logic belongs in your
> IDE. We do things as follows:
> >>
> >> If no thread was selected before, display the first thread that has a
> stop reason other than none. If no threads have sto
Follow-up for the previous question:
Our python code is trying to call json.dumps to serialize the variable
evaluation result into string block and send to IDE via RPC, however it
failed with "UnicodeDecodeError: 'utf8' codec can't decode byte 0xc9 in
position 10: invalid continuation byte" becaus
Sorry, sent to the wrong alias.
-- Forwarded message --
From: Jeffrey Tan
Date: Sat, Mar 26, 2016 at 3:19 PM
Subject: DW_TAG_member extends beyond the bounds error on Linux
To: llvm-...@lists.llvm.org
Hi,
While dogfooding our lldb based IDE on Linux, I am seeing a lot of variab
Thanks David. I meant to send to lldb maillist, but glad to hear response
here.
Our binary is built from gcc:
String dump of section '.comment':
[ 1] GCC: (GNU) 4.9.x-google 20150123 (prerelease)
Is there any similar flags we should use? By doing "strings -a [binary] |
grep -i gcc", I foun
Btw: after patching with Siva's fix http://reviews.llvm.org/D18008, the
first field 'small_' is fixed, however the second field 'ml_' still emits
garbage:
(lldb) fr v corpus
(const string &const) corpus = error: summary string parsing error: {
store_ = {
= {
small_ = "www"
ml_ =
Thanks Siva. All the *DW_TAG_member *related errors seems to go away after
patching with your fix. The current problem is handling the decoding.
Here is the correct decoding from gdb whic might be useful:
(gdb) p corpus
$3 = (const std::string &) @0x7fd133cfb888: {
static npos = 1844674407370955
DW_TAG_member
> '_M_pod_data' refers to type 0x10bb1e99 which extends beyond the bounds of
> 0x10b9a901
> >
> > So if you dump the DWARF and look for the DIE at 0x10b9a91a, you will be
> able to see the DWARF that is causing the problem. On MacOSX, I would do
> this:
>
[15] = '\0'
> [16] = '\0'
> [17] = '\0'
> [18] = '\0'
> [19] = '\0'
> [20] = '\0'
> [21] = '\0'
> [22] = &#x
Thanks, I will try this escape mechanism for the returned C string.
On Mon, Mar 28, 2016 at 1:04 PM, Greg Clayton wrote:
>
> > On Mar 28, 2016, at 11:38 AM, Jeffrey Tan
> wrote:
> >
> > Thanks Greg for the detailed explanation, very helpful.
> > 1. Just to confirm, the weird string displayed is
Hi,
When user tries to stop debugging, we call SBDebugger.Destroy(), then
SBDebugger.Terminate() and exit the python process. This works well on mac,
but on linux in running mode. However, I found if the debugger hits
breakpoint first, then user stops debugging, the inferior is killed with
siginal
og gdb-remote packets), so
> I can get a better idea of what is going on.
>
> cheers,
> pl
>
>
> On 29 March 2016 at 00:21, Jeffrey Tan via lldb-dev
> wrote:
> > Hi,
> >
> > When user tries to stop debugging, we call SBDebugger.Destroy(), then
> >
27;\0'
> [14] = '\0'
> [15] = '\0'
> [16] = '\0'
> [17] = '\0'
> [18] = '\0'
> [19] = '\0'
> [20] = '\0'
>
__data_ = {
>> [0] = 'h'
>> [1] = 'e'
>> [2] = 'l'
>> [3] = 'l'
>> [4] = 'o'
>> [5] = '\0'
>> [6] = &#
ead.GetStopReason()
> > if event_type == lldb.SBProcess.eBroadcastBitSTDOUT:
> > print 'Stdout:'
> > while True:
> > output = process.GetSTDOUT(1024)
> > if output is None or len(output) == 0:
&
e raw we see:
>>>
>>> (lldb) fr var --raw h
>>> (std::__1::string) h = {
>>> __r_ = {
>>>std::__1::__libcpp_compressed_pair_imp>> std::__1::char_traits, std::__1::allocator >::__rep,
>>> std::__1::allocator, 2> = {
>>> __fi
; std_string_summary_sp);
>>>>
>>>> Special flags are set on std::string to say "don't show children of
>>>> this and just show a summary" So if a std::string contained "hello". So for
>>>> the following code:
>>>>
000). "data_" seems to be some random pointer.
>>>>>
>>>>> On MacOSX, we have a special formatting code that displays std::string
>>>>> in CPlusPlusLanguage.cpp that gets installed in the LoadLibCxxFormatters()
>>>>> or Lo
0x1000-0x2000), but it actually is [0x1200-0x2000). If we read a
>>>>>> variable in this case, a std::string might contain bogus data and the
>>>>>> bytes
>>>>>> might not make sense. So you always have to be prepared for bad data.
>>&g
Hi,
I call SBFrame.name to get function name and display in our debugger
callstack window. However, this seems to include arguments types
sometimes.(Btw: why it includes arguments types for subFunction but not
main() in screenshot?)
[image: Inline image 1]
This is fine for small function, but ca
gt;>>>>>> If one were signing up for more infrastructure work, they could
>>>>>>> decide to try and detect shared library loads and load formatters that
>>>>>>> match with whatever libraries are being loaded.
>>>>>>
Hi,
I followed instructions in http://lldb.llvm.org/build.html to build lldb on
Mac.
I opened "*lldb/lldb.xcworkspace*" in Xcode7.3.1, select lldb-tools scheme
and build, I always got build error below. I have tried "brew install
cmake" but the installed cmake version does not match what build sc
Nevermind, I was finally unable to build by "git pull" and
"xcodebuild -configuration Debug"
On Mon, Jun 27, 2016 at 9:55 PM, Jeffrey Tan
wrote:
> Hi,
>
> I followed instructions in http://lldb.llvm.org/build.html to build lldb
> on Mac.
>
> I opened "*lldb/lldb.xcworkspace*" in Xcode7.3.1, sele
Hi,
O ur company is using Buck(https://buckbuild.com/) to build internal
service. Recently the build team made a change in buck to not merge dwarf
symbols from each object file into final binary so debugger needs to read
source/symbol table from compilation unit itself.
This seems to break the lld
2017 at 1:57 PM, Greg Clayton wrote:
> Comments below.
>
> On Jan 9, 2017, at 1:10 PM, Jeffrey Tan via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
> Hi,
>
> O ur company is using Buck(https://buckbuild.com/) to build internal
> service. Recently the build te
Hi,
I am writing a python script to set source line breakpoint in ObjC on Mac
OSX.
But
self.debugger.GetSelectedTarget().BreakpointCreateByLocation("EATAnimatedView.m",
line) always fail. Any ideas?
Also, can I use full path instead of file basename? In lldb, I found "b
/Users/jeffreytan/fbsourc
69 matches
Mail list logo
