[lldb-dev] FW: [llvm-dev] Optimised-code debugging experience Round Table
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 Hi Paul, Eric, lists, FWIW I agree with Paul here. Given the limited time available for the discussions I think it makes sense to split up the conversations to keep them focused. Though, it'd be good to coordinate non-overlapping time slots. As you say, it is likely that people (including me) would want to attend more than one of these. Saying that, I've only had 3 people outside of Sony express an interest in the Round Table that I proposed. At this rate we may not have the requisite numbers to split. Of course, if that number is indicative of actual turn out then we won't need to split anyway, but I suspect that there will be more attendees on the day. We must also remember that the Round Table submission deadline is tomorrow (tonight?). Unless more people express an interest very soon, I think we might need to fall back onto the single Round Table. Thanks, Orlando From: Robinson, Paul mailto:paul.robin...@sony.com>> Sent: 23 September 2020 15:21 To: Eric Christopher mailto:echri...@gmail.com>>; Cazalet-Hyams, Orlando mailto:orlando.hy...@sony.com>>; LLDB Dev mailto:lldb-dev@lists.llvm.org>>; 'llvm-...@lists.llvm.org' mailto:llvm-...@lists.llvm.org>> Subject: RE: [llvm-dev] Optimised-code debugging experience Round Table Hi Eric & Orlando, It’s great to see interest in a lot of different aspects of debug info. At the same time, I’m concerned about a risk to making the topic so broad that we don’t have time to get through all the things people want to get through. I’m thinking there’s a different way to slice the topics, hopefully without much overlap, but that will allow a bit more focus. No doubt a lot of the same people would be interested in multiple slices, but by limiting the scope of each conversation I’m hoping we’ll get more accomplished. I daresay a lot of people interested in debug-info quality in general might totally tune out a DWARF-nerd discussion 😊 The slicing could be something like this: 1. Getting LLVM to do a better job of tracking info internally, so what gets emitted in the end is more representative of the original program. This should improve the debugging experience by letting the debugger do a better job of mapping the executing program to the original source, because the data it works with is more accurate/complete. * This is basically about IR/Metadata handling and representation, although it might leak into things like the “is_stmt” flag, and doing better with “prologue_end,” which are currently handled by AsmPrinter. * Better handling of induction variables, entry-values, variables with multiple locations, etc. 2. Changes to optimization passes/pipelines and codegen, to avoid borking the source-location and value/variable tracking; again this should improve the debugging experience by letting the debugger do a better job of mapping the executing program back to the original source, because that mapping is simpler. * This is basically about IR/MIR transforms, and is where an Og/O1 kind of topic would fit. * Also things like extended lifetimes, limiting code motion/duplication, etc. 3. Changing the DWARF spec itself to improve the completeness and efficiency of the information it contains. This should improve the debugging experience by making the DWARF itself a richer information source, to the extent that it can describe more of what happened to the original program; also hopefully any efficiency improvements will allow the debugger to be more responsive. * This is obviously about DWARF itself, although to some extent how we go about generating it. * Take better advantage of ranges and the .debug_addr table. dblaikie and clayborg have put up ideas about this. * Figure out a way to allow tracking multiple source locations for an individual instruction. Right now we mostly give up and set locations to line-0 when this happens. * Understand the competing needs of profiling and debugging consumers, and see what might be doable there. (Although this might be tough enough to be its own topic.) 4. Debug-info testing/validation. How do we decide what is “correct”? * What are the tools we have, what are they good/bad at, what’s missing? I hear that round-tables can be proposed for either ~half hour or ~full hour, so with more focused topics we might rather have shorter sessions? Thanks, --paulr From: llvm-dev mailto:llvm-dev-boun...@lists.llvm.org>> On Behalf Of Eric Christopher via llvm-dev Sent: Tuesday, September 22, 2020 2:42 PM To: Cazalet-Hyams, Orlando mailto:orlando.hy...@sony.com>>; LLDB Dev mailto:lldb-dev@lists.llvm.org>> Cc: llvm-...@lists.l
[lldb-dev] Weird results running lldb under Valgrind
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: /home/antipov/.local/llvm-12.0.0/bin/lldb ==2715== Parent PID: 1702 In LLDB, do 'process attach --pid [PID of running Firefox]', then: ==2715== Thread 5: ==2715== The impossible happened: mutex is locked simultaneously by two threads: mutex 0xe907d10, recursion count 1, owner 1. ==2715==at 0x4841015: pthread_mutex_lock_intercept (drd_pthread_intercepts.c:893) ==2715==by 0x4841015: pthread_mutex_lock (drd_pthread_intercepts.c:903) ==2715==by 0x504FBEE: __gthread_mutex_lock (gthr-default.h:749) ==2715==by 0x504FBEE: lock (std_mutex.h:100) ==2715==by 0x504FBEE: lock_guard (std_mutex.h:159) ==2715==by 0x504FBEE: SetValue (Predicate.h:91) ==2715==by 0x504FBEE: lldb_private::EventDataReceipt::DoOnRemoval(lldb_private::Event*) (Event.h:121) ==2715==by 0x5113644: lldb_private::Listener::FindNextEventInternal(std::unique_lock&, lldb_private::Broadcaster*, lldb_private::ConstString const*, unsigned int, unsigned int, std::shared_ptr&, bool) (Listener.cpp:309) ==2715==by 0x5113DD1: lldb_private::Listener::GetEventInternal(lldb_private::Timeout > const&, lldb_private::Broadcaster*, lldb_private::ConstString const*, unsigned int, unsigned int, std::shared_ptr&) (Listener.cpp:357) ==2715==by 0x5113F4A: lldb_private::Listener::GetEventForBroadcaster(lldb_private::Broadcaster*, std::shared_ptr&, lldb_private::Timeout > const&) (Listener.cpp:395) ==2715==by 0x506ADD4: lldb_private::Process::RunPrivateStateThread(bool) (Process.cpp:3872) ==2715==by 0x506B3F5: lldb_private::Process::PrivateStateThread(void*) (Process.cpp:3857) ==2715==by 0x483DB9A: vgDrd_thread_wrapper (drd_pthread_intercepts.c:449) ==2715==by 0x488B3F8: start_thread (in /usr/lib64/libpthread-2.32.so) ==2715==by 0xDFCEA92: clone (in /usr/lib64/libc-2.32.so) ==2715== mutex 0xe907d10 was first observed at: ==2715==at 0x4840F55: pthread_mutex_lock_intercept (drd_pthread_intercepts.c:890) ==2715==by 0x4840F55: pthread_mutex_lock (drd_pthread_intercepts.c:903) ==2715==by 0x5058502: __gthread_mutex_lock (gthr-default.h:749) ==2715==by 0x5058502: lock (std_mutex.h:100) ==2715==by 0x5058502: lock (unique_lock.h:138) ==2715==by 0x5058502: unique_lock (unique_lock.h:68) ==2715==by 0x5058502: WaitFor::WaitForValueEqualTo:: > (Predicate.h:123) ==2715==by 0x5058502: WaitForValueEqualTo (Predicate.h:157) ==2715==by 0x5058502: WaitForEventReceived (Event.h:114) ==2715==by 0x5058502: lldb_private::Process::ControlPrivateStateThread(unsigned int) (Process.cpp:3698) ==2715==by 0x505BC61: lldb_private::Process::StartPrivateStateThread(bool) (Process.cpp:3647) ==2715==by 0x5065B96: lldb_private::Process::Attach(lldb_private::ProcessAttachInfo&) (Process.cpp:2961) ==2715==by 0x544DBB8: PlatformPOSIX::Attach(lldb_private::ProcessAttachInfo&, lldb_private::Debugger&, lldb_private::Target*, lldb_private::Status&) (PlatformPOSIX.cpp:401) ==2715==by 0x509F531: lldb_private::Target::Attach(lldb_private::ProcessAttachInfo&, lldb_private::Stream*) (Target.cpp:3008) ==2715==by 0x54C3F17: CommandObjectProcessAttach::DoExecute(lldb_private::Args&, lldb_private::CommandReturnObject&) (CommandObjectProcess.cpp:386) ==2715==by 0x4FC0ACD: lldb_private::CommandObjectParsed::Execute(char const*, lldb_private::CommandReturnObject&) (CommandObject.cpp:993) ==2715==by 0x4FBCBD7: lldb_private::CommandInterpreter::HandleCommand(char const*, lldb_private::LazyBool, lldb_private::CommandReturnObject&, lldb_private::ExecutionContext*, bool, bool) (CommandInterpreter.cpp:1803) ==2715==by 0x4FBDB96: lldb_private::CommandInterpreter::IOHandlerInputComplete(lldb_private::IOHandler&, std::__cxx11::basic_string, std::allocator >&) (CommandInterpreter.cpp:2838) ==2715==by 0x4EF21C0: lldb_private::IOHandlerEditline::Run() (IOHandler.cpp:579) ==2715==by 0x4ED02B0: lldb_private::Debugger::RunIOHandlers() (Debugger.cpp:861) Hopefully this is an issue with valgrind and not lldb. But still curious whether someone else can reproduce something similar. Dmitry ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] FW: [llvm-dev] Optimised-code debugging experience Round Table
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 wish to focus on the most. thanks for sorting this out Orlando, looking forward to it. Tom W On Thu, 24 Sep 2020 at 09:00, Cazalet-Hyams, Orlando via lldb-dev < lldb-dev@lists.llvm.org> wrote: > 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 < > echri...@gmail.com>; LLDB Dev ; ' > llvm-...@lists.llvm.org' > *Subject:* Re: [llvm-dev] Optimised-code debugging experience Round Table > > > > Hi Paul, Eric, lists, > > > FWIW I agree with Paul here. Given the limited time available for the > discussions I think it makes sense to split up the conversations to keep > them focused. Though, it'd be good to coordinate non-overlapping time > slots. As you say, it is likely that people (including me) would want to > attend more than one of these. > > > Saying that, I've only had 3 people outside of Sony express an interest in > the Round Table that I proposed. At this rate we may not have the requisite > numbers to split. Of course, if that number is indicative of actual turn > out then we won't need to split anyway, but I suspect that there will be > more attendees on the day. > > We must also remember that the Round Table submission deadline is tomorrow > (tonight?). Unless more people express an interest very soon, I think we > might need to fall back onto the single Round Table. > > > Thanks, > > Orlando > > *From:* Robinson, Paul > *Sent:* 23 September 2020 15:21 > *To:* Eric Christopher ; Cazalet-Hyams, Orlando < > orlando.hy...@sony.com>; LLDB Dev ; ' > llvm-...@lists.llvm.org' > *Subject:* RE: [llvm-dev] Optimised-code debugging experience Round Table > > > > Hi Eric & Orlando, > > > > It’s great to see interest in a lot of different aspects of debug info. At > the same time, I’m concerned about a risk to making the topic so broad that > we don’t have time to get through all the things people want to get > through. I’m thinking there’s a different way to slice the topics, > hopefully without much overlap, but that will allow a bit more focus. No > doubt a lot of the same people would be interested in multiple slices, but > by limiting the scope of each conversation I’m hoping we’ll get more > accomplished. I daresay a lot of people interested in debug-info quality > in general might totally tune out a DWARF-nerd discussion 😊 > > The slicing could be something like this: > > > >1. Getting LLVM to do a better job of tracking info internally, so >what gets emitted in the end is more representative of the original >program. This should improve the debugging experience by letting the >debugger do a better job of mapping the executing program to the original >source, because the data it works with is more accurate/complete. > 1. This is basically about IR/Metadata handling and representation, > although it might leak into things like the “is_stmt” flag, and doing > better with “prologue_end,” which are currently handled by AsmPrinter. > 2. Better handling of induction variables, entry-values, variables > with multiple locations, etc. >2. Changes to optimization passes/pipelines and codegen, to avoid >borking the source-location and value/variable tracking; again this should >improve the debugging experience by letting the debugger do a better job of >mapping the executing program back to the original source, because that >mapping is simpler. > 1. This is basically about IR/MIR transforms, and is where an Og/O1 > kind of topic would fit. > 2. Also things like extended lifetimes, limiting code > motion/duplication, etc. >3. Changing the DWARF spec itself to improve the completeness and >efficiency of the information it contains. This should improve the >debugging experience by making the DWARF itself a richer information >source, to the extent that it can describe more of what happened to the >original program; also hopefully any efficiency improvements will allow the >debugger to be more responsive. > 1. This is obviously about DWARF itself, although to some extent > how we go about generating it. > 2. Take better advantage of ranges and the .debug_addr table. > dblaikie and clayborg have put up ideas about this. > 3. Figure out a way to allow tracking multiple source locations for > an individual instruction. Right now we mostly give up and set > locations > to line-0 when this happens. > 4. Understand the competing needs of profiling and debugging > consumers, and see what might be doable
[lldb-dev] Odd output issue with lldb -s
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 with top-of-tree on Ubuntu 16: bin/lldb /bin/ls -o "process launch -s" -s dis.lldb (lldb) target create "/bin/ls" Current executable set to '/bin/ls' (x86_64). (lldb) process launch -s Process 32258 launched: '/bin/ls' (x86_64) (lldb) command source -s 0 'dis.lldb' Executing commands in '/local/mnt/ted/tip/full/dis.lldb'. (lldb) thread select 1 (lldb) disassemble --start-address $pc-24 --end-address $pc+24 * thread #1, name = 'ls', stop reason = signal SIGSTOP frame #0: 0x77dd7c30 ld-2.23.so`_start ld-2.23.so`_start: -> 0x77dd7c30 <+0>: movq %rsp, %rdi 0x77dd7c33 <+3>: callq 0x77dd89b0; _dl_start at rtld.c:353 ld-2.23.so`_dl_start_user: 0x77dd7c38 <+0>: movq %rax, %r12 0x77dd7c3b <+3>: movl 0x225037(%rip), %eax ; _dl_skip_args ld-2.23.so`oom: 0x77dd7c18 <+13>: xorl %eax, %eax 0x77dd7c1a <+15>: callq 0x77de88f0; _dl_dprintf at dl-misc.c:275 0x77dd7c1f <+20>: movl $0x7f, %edi 0x77dd7c24 <+25>: callq 0x77df24f0; __GI__exit at _exit.c:27 0x77dd7c29: nopl (%rax) ld-2.23.so`_start: -> 0x77dd7c30 <+0>: movq %rsp, %rdi 0x77dd7c33 <+3>: callq 0x77dd89b0; _dl_start at rtld.c:353 ld-2.23.so`_dl_start_user: 0x77dd7c38 <+0>: movq %rax, %r12 0x77dd7c3b <+3>: movl 0x225037(%rip), %eax ; _dl_skip_args 0x77dd7c41 <+9>: popq %rdx 0x77dd7c42 <+10>: leaq (%rsp,%rax,8), %rsp 0x77dd7c46 <+14>: subl %eax, %edx (lldb) Note that the address goes from c3b to c18 right after ld-2.23.so`oom. How can I separate the outputs of thread select and disassemble? If I stick in something like "register read pc" in between the thread select and the dis, I get the output from it before the output from the thread select and dis. ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Weird results running lldb under Valgrind
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 lldb-dev
> wrote:
>
> 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: /home/antipov/.local/llvm-12.0.0/bin/lldb
> ==2715== Parent PID: 1702
>
> In LLDB, do 'process attach --pid [PID of running Firefox]', then:
>
> ==2715== Thread 5:
> ==2715== The impossible happened: mutex is locked simultaneously by two
> threads: mutex 0xe907d10, recursion count 1, owner 1.
> ==2715==at 0x4841015: pthread_mutex_lock_intercept
> (drd_pthread_intercepts.c:893)
> ==2715==by 0x4841015: pthread_mutex_lock (drd_pthread_intercepts.c:903)
> ==2715==by 0x504FBEE: __gthread_mutex_lock (gthr-default.h:749)
> ==2715==by 0x504FBEE: lock (std_mutex.h:100)
> ==2715==by 0x504FBEE: lock_guard (std_mutex.h:159)
> ==2715==by 0x504FBEE: SetValue (Predicate.h:91)
> ==2715==by 0x504FBEE:
> lldb_private::EventDataReceipt::DoOnRemoval(lldb_private::Event*)
> (Event.h:121)
> ==2715==by 0x5113644:
> lldb_private::Listener::FindNextEventInternal(std::unique_lock&,
> lldb_private::Broadcaster*, lldb_private::ConstString const*, unsigned int,
> unsigned int, std::shared_ptr&, bool) (Listener.cpp:309)
> ==2715==by 0x5113DD1:
> lldb_private::Listener::GetEventInternal(lldb_private::Timeout 100l> > const&, lldb_private::Broadcaster*, lldb_private::ConstString
> const*, unsigned int, unsigned int, std::shared_ptr&)
> (Listener.cpp:357)
> ==2715==by 0x5113F4A:
> lldb_private::Listener::GetEventForBroadcaster(lldb_private::Broadcaster*,
> std::shared_ptr&, lldb_private::Timeout 100l> > const&) (Listener.cpp:395)
> ==2715==by 0x506ADD4: lldb_private::Process::RunPrivateStateThread(bool)
> (Process.cpp:3872)
> ==2715==by 0x506B3F5: lldb_private::Process::PrivateStateThread(void*)
> (Process.cpp:3857)
> ==2715==by 0x483DB9A: vgDrd_thread_wrapper (drd_pthread_intercepts.c:449)
> ==2715==by 0x488B3F8: start_thread (in /usr/lib64/libpthread-2.32.so)
> ==2715==by 0xDFCEA92: clone (in /usr/lib64/libc-2.32.so)
> ==2715== mutex 0xe907d10 was first observed at:
> ==2715==at 0x4840F55: pthread_mutex_lock_intercept
> (drd_pthread_intercepts.c:890)
> ==2715==by 0x4840F55: pthread_mutex_lock (drd_pthread_intercepts.c:903)
> ==2715==by 0x5058502: __gthread_mutex_lock (gthr-default.h:749)
> ==2715==by 0x5058502: lock (std_mutex.h:100)
> ==2715==by 0x5058502: lock (unique_lock.h:138)
> ==2715==by 0x5058502: unique_lock (unique_lock.h:68)
> ==2715==by 0x5058502:
> WaitFor::WaitForValueEqualTo::
> > (Predicate.h:123)
> ==2715==by 0x5058502: WaitForValueEqualTo (Predicate.h:157)
> ==2715==by 0x5058502: WaitForEventReceived (Event.h:114)
> ==2715==by 0x5058502:
> lldb_private::Process::ControlPrivateStateThread(unsigned int)
> (Process.cpp:3698)
> ==2715==by 0x505BC61:
> lldb_private::Process::StartPrivateStateThread(bool) (Process.cpp:3647)
> ==2715==by 0x5065B96:
> lldb_private::Process::Attach(lldb_private::ProcessAttachInfo&)
> (Process.cpp:2961)
> ==2715==by 0x544DBB8:
> PlatformPOSIX::Attach(lldb_private::ProcessAttachInfo&,
> lldb_private::Debugger&, lldb_private::Target*, lldb_private::Status&)
> (PlatformPOSIX.cpp:401)
> ==2715==by 0x509F531:
> lldb_private::Target::Attach(lldb_private::ProcessAttachInfo&,
> lldb_private::Stream*) (Target.cpp:3008)
> ==2715==by 0x54C3F17:
> CommandObjectProcessAttach::DoExecute(lldb_private::Args&,
> lldb_private::CommandReturnObject&) (CommandObjectProcess.cpp:386)
> ==2715==by 0x4FC0ACD: lldb_private::CommandObjectParsed::Execute(char
> const*, lldb_private::CommandReturnObject&) (CommandObject.cpp:993)
> ==2715==by 0x4FBCBD7:
> lldb_private::CommandInterpreter::HandleCommand(char const*,
> lldb_private::LazyBool, lldb_private::CommandReturnObject&,
> lldb_private::ExecutionContext*, bool, bool) (CommandInterpreter.cpp:1803)
> ==2715==by 0x4FBDB96:
> lldb_private::CommandInterpreter::IOHandlerInputComplete(lldb_private::IOHandler&,
> std::__cxx11::basic_string,
> std::allocator >&) (CommandInterpreter.cpp:2838)
> ==2715==by 0x4EF21C0: lldb_private::IOHandlerEditline::Run()
> (IOHandler.cpp:579)
> ==2715==by 0x4ED02B0: lldb_private::Debugger::RunIOHandlers()
> (Debugger.cpp:861)
>
> Hopefully this is an issue with valgrind and not lldb. But still curious
> whether someone else can reproduce something similar.
>
> Dmitry
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
Re: [lldb-dev] Odd output issue with lldb -s
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 you need help. In the python you might be able to do something a bit smarter than trying to subtract 24 from the PC. This if very error prone because opcodes for x86 vary in size and this value might be in the middle of an opcode. It might be better to get the function for the current PC and get its instructions in python: >>> pc = frame.GetPCAddress() >>> print(pc) a.out`main + 36 [inlined] squares(int, int) at main.cpp:17 a.out`main + 36 at main.cpp:17 >>> function = pc.GetFunction() >>> if not function.IsValid(): ... function = pc.GetSymbol() ... >>> print(function) SBFunction: id = 0x7fff0122, name = main, type = main Now "function" is either a lldb.SBFunction or lldb.SBSymbol. Both types have a "GetInstructions(...)" method which can be used to grab a lldb.SBInstructionList for all instructions in that function or symbol: >>> instructions = function.GetInstructions(target) >>> for instruction in instructions: ... print(instruction) ... a.out[0x10f10]: pushq %rbp a.out[0x10f11]: movq %rsp, %rbp a.out[0x10f14]: subq $0x30, %rsp a.out[0x10f18]: movl $0x0, -0x1c(%rbp) a.out[0x10f1f]: movl %edi, -0x20(%rbp) a.out[0x10f22]: movq %rsi, -0x28(%rbp) a.out[0x10f26]: movl $0xa, -0xc(%rbp) a.out[0x10f2d]: movl $0x14, -0x10(%rbp) a.out[0x10f34]: movl -0xc(%rbp), %eax a.out[0x10f37]: movl %eax, -0x8(%rbp) a.out[0x10f3a]: movl -0x8(%rbp), %eax a.out[0x10f3d]: imull -0x8(%rbp), %eax a.out[0x10f41]: movl %eax, -0x14(%rbp) a.out[0x10f44]: movl -0x10(%rbp), %eax a.out[0x10f47]: movl %eax, -0x4(%rbp) a.out[0x10f4a]: movl -0x4(%rbp), %eax a.out[0x10f4d]: imull -0x4(%rbp), %eax a.out[0x10f51]: movl %eax, -0x18(%rbp) a.out[0x10f54]: movl -0x18(%rbp), %eax a.out[0x10f57]: addl -0x14(%rbp), %eax a.out[0x10f5a]: movl %eax, -0x14(%rbp) a.out[0x10f5d]: movl -0x14(%rbp), %eax a.out[0x10f60]: movl %eax, -0x2c(%rbp) a.out[0x10f63]: movl -0x2c(%rbp), %esi a.out[0x10f66]: leaq 0x35(%rip), %rdi a.out[0x10f6d]: movb $0x0, %al a.out[0x10f6f]: callq 0x10f82 a.out[0x10f74]: xorl %ecx, %ecx a.out[0x10f76]: movl %eax, -0x30(%rbp) a.out[0x10f79]: movl %ecx, %eax a.out[0x10f7b]: addq $0x30, %rsp a.out[0x10f7f]: popq %rbp a.out[0x10f80]: retq Each "instruction" is a "lldb.SBInstruction" that has a "GetAddress()" method which returns the lldb.SBAddress for that instruction. You can compare that to the PC value: >>> for instruction in instructions: ... if instruction.GetAddress() == pc: ... print(instruction) ... a.out[0x10f34]: movl -0xc(%rbp), %eax So you can use this to find the index of the instruction that the PC is at within "instructions": >>> for (i, instruction) in enumerate(instructions): ... if instruction.GetAddress() == pc: ... print(instruction) ... break ... a.out[0x10f34]: movl -0xc(%rbp), %eax >>> print(i) 8 Now you can backup as many instructions as you want and not fear that you will end up in the middle of an x86 instruction. Greg > On Sep 24, 2020, at 10:30 AM, Ted Woodward via lldb-dev > wrote: > > 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 with top-of-tree on Ubuntu 16: > > bin/lldb /bin/ls -o "process launch -s" -s dis.lldb > (lldb) target create "/bin/ls" > Current executable set to '/bin/ls' (x86_64). > (lldb) process launch -s > Process 32258 launched: '/bin/ls' (x86_64) > (lldb) command source -s 0 'dis.lldb' > Executing commands in '/local/mnt/ted/tip/full/dis.lldb'. > (lldb) thread select 1 > (lldb) disassemble --start-address $pc-24 --end-address $pc+24 > * thread #1, name = 'ls', stop reason = signal SIGSTOP > frame #0: 0x77dd7c30 ld-2.23.so`_start > ld-2.23.so`_start: > -> 0x77dd7c30 <+0>: movq %rsp, %rdi > 0x77dd7c33 <+3>: callq 0x77dd89b0; _dl_start at > rtld.c:353 > > ld-2.23.so`_dl_start_user: > 0x77dd7c38 <+0>: movq %rax, %r12 > 0x77dd7c3b <+3>: movl 0x225037(%rip), %eax ; _dl_skip_args > ld-2.23.so`oom: > 0x77dd7c18 <+13>: xorl %eax, %eax > 0x77dd7c1a <+15>: callq 0x77de88f0; _dl_dprintf at > dl-misc.c:275 > 0x77dd7c1f <+20>: movl $0x7f, %edi > 0x77dd7c24 <+25>: callq 0x77df24f0; __GI__exit at > _exit.c:27 > 0x77dd7c29:
Re: [lldb-dev] [llvm-dev] Optimised-code debugging experience Round Table
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 time, I’m concerned about a risk to making the topic so broad that > we don’t have time to get through all the things people want to get > through. I’m thinking there’s a different way to slice the topics, > hopefully without much overlap, but that will allow a bit more focus. No > doubt a lot of the same people would be interested in multiple slices, but > by limiting the scope of each conversation I’m hoping we’ll get more > accomplished. I daresay a lot of people interested in debug-info quality > in general might totally tune out a DWARF-nerd discussion 😊 > > The slicing could be something like this: > > > >1. Getting LLVM to do a better job of tracking info internally, so >what gets emitted in the end is more representative of the original >program. This should improve the debugging experience by letting the >debugger do a better job of mapping the executing program to the original >source, because the data it works with is more accurate/complete. > 1. This is basically about IR/Metadata handling and representation, > although it might leak into things like the “is_stmt” flag, and doing > better with “prologue_end,” which are currently handled by AsmPrinter. > 2. Better handling of induction variables, entry-values, variables > with multiple locations, etc. >2. Changes to optimization passes/pipelines and codegen, to avoid >borking the source-location and value/variable tracking; again this should >improve the debugging experience by letting the debugger do a better job of >mapping the executing program back to the original source, because that >mapping is simpler. > 1. This is basically about IR/MIR transforms, and is where an Og/O1 > kind of topic would fit. > 2. Also things like extended lifetimes, limiting code > motion/duplication, etc. >3. Changing the DWARF spec itself to improve the completeness and >efficiency of the information it contains. This should improve the >debugging experience by making the DWARF itself a richer information >source, to the extent that it can describe more of what happened to the >original program; also hopefully any efficiency improvements will allow the >debugger to be more responsive. > 1. This is obviously about DWARF itself, although to some extent > how we go about generating it. > 2. Take better advantage of ranges and the .debug_addr table. > dblaikie and clayborg have put up ideas about this. > 3. Figure out a way to allow tracking multiple source locations for > an individual instruction. Right now we mostly give up and set > locations > to line-0 when this happens. > 4. Understand the competing needs of profiling and debugging > consumers, and see what might be doable there. (Although this might be > tough enough to be its own topic.) >4. Debug-info testing/validation. How do we decide what is >“correct”? > 1. What are the tools we have, what are they good/bad at, what’s > missing? > > > > I hear that round-tables can be proposed for either ~half hour or ~full > hour, so with more focused topics we might rather have shorter sessions? > > > > Thanks, > > --paulr > > > > *From:* llvm-dev *On Behalf Of *Eric > Christopher via llvm-dev > *Sent:* Tuesday, September 22, 2020 2:42 PM > *To:* Cazalet-Hyams, Orlando ; LLDB Dev < > lldb-dev@lists.llvm.org> > *Cc:* llvm-...@lists.llvm.org > *Subject:* Re: [llvm-dev] Optimised-code debugging experience Round Table > > > > +LLDB Dev > > > > I'll sign up. :) > > > > My particular interests are: > > > > - Og (and O1 as Og) > > - Correctness testing tools > > > > Past that the rest of your list seems quite specific, but the overall > "line tables" and "variable locations" are important. > > > > Relatedly we have a number of DWARF committee members in llvm and another > possible discussion area could be: "what extensions do debug info consumers > think should happen to make dwarf a better input into debugging". > > > > Thanks. > > > > -eric > > > > > > On Tue, Sep 22, 2020 at 8:43 AM Cazalet-Hyams, Orlando via llvm-dev < > llvm-...@lists.llvm.org> wrote: > > Hi all, > > > > I haven't seen a proposal for an optimised-code debugging experience Round > Table yet so here goes! > > Please let me know if you are interested by emailing me at: > > > > orlando.hy...@sony.com > > > > Below is a non-exhaustive list of possible topics. Feel free to include > any preferences and > > suggestions in your response. > > > > a. Line tables: > > 1. Can we fix is_stmt? > > 2. Is prologue_end reliable? > > 3. General stepping beha
