Hi Paul,
I took it rather as a set of suggested topics depending on who is
interested rather than a proposed agenda.
-eric
On Wed, Sep 23, 2020 at 7:20 AM Robinson, Paul
wrote:
> Hi Eric & Orlando,
>
>
>
> It’s great to see interest in a lot of different aspects of debug info. At
> the same
I would suggest using python here. You can make a new LLDB command in a python
file and then "command script import /path/to/my/file.py". This python script
would install a new command and you can then just run that command. Happy to
help you get this script working off the mailing lists if
This must be a valgrind issue, there would be major problems if the OS isn't
able to lock mutex objects correctly ("mutex is locked simultaneously by two
threads"). It is getting confused by a recursive mutex? LLDB uses recursive
mutexes.
> On Sep 24, 2020, at 1:55 AM, Dmitry Antipov via
I have a very simple lldb script:
thread select 1
disassemble --start-address $pc-24 --end-address $pc+24
When I run lldb with -o "process launch -s" and -s "dis.lldb", I get odd output
- the disassembly from "thread select 1" and from the disassemble command run
together.
This is what I see
Tom Weaver will answer the councils call!
count me in, can't wait to have a good chin wag (talk for our non brit
brethren) about debug info and it's many faceted forms.
I somewhat agree with Paul's concern about discussing everything, but we
can make a judgement call on the day about what we
Does anyone has an explanation of this weird run of 'valgrind --tool=drd':
==2715== drd, a thread error detector
==2715== Copyright (C) 2006-2017, and GNU GPL'd, by Bart Van Assche.
==2715== Using Valgrind-3.16.1 and LibVEX; rerun with -h for copyright info
==2715== Command:
Forwarding to lldb-dev now that I’ve signed up.
From: llvm-dev On Behalf Of Cazalet-Hyams,
Orlando via llvm-dev
Sent: 24 September 2020 08:54
To: Robinson, Paul ; Eric Christopher
; LLDB Dev ;
'llvm-...@lists.llvm.org'
Subject: Re: [llvm-dev] Optimised-code debugging experience Round Table
