Re: [lldb-dev] [RFC] Improving protocol-level compatibility between LLDB and GDB

> On Apr 27, 2021, at 4:56 AM, Pavel Labath wrote: > > I think that's fine, though possible changing the servers to just ignore the > length fields, like you did above, might be even better, as then they will > work fine regardless of which client they are talking to. They still should >

Re: [lldb-dev] [RFC] Improving protocol-level compatibility between LLDB and GDB

I was looking at lldb-platform and I noticed I implemented the A packet in it, and I was worried I might have the same radix error as lldb in there, but this code I wrote made me laugh: const char *p = pkt.c_str() + 1; // skip the 'A' std::vector packet_contents =

Re: [lldb-dev] [RFC] Improving protocol-level compatibility between LLDB and GDB

> On Apr 20, 2021, at 11:39 PM, Pavel Labath via lldb-dev > wrote: > > I am very happy to see this effort and I fully encourage it. Completely agree. Thanks for Cc:'ing me Pavel, I hadn't seen Michał's thread. > > On 20/04/2021 09:13, Michał Górny via lldb-dev wrote: >> On Mon,

Re: [lldb-dev] RFC: packet to identify a standalone aka firmware binary UUID / location

> On Mar 23, 2021, at 1:36 PM, Greg Clayton wrote: > > > >> On Mar 22, 2021, at 11:01 PM, Jason Molenda wrote: >> >> Hi, I'm working with an Apple team that has a gdb RSP server for JTAG >> debugging, and we're working to add the ability for it to tell lldb about >> the UUID and possibly

Re: [lldb-dev] RFC: packet to identify a standalone aka firmware binary UUID / location

a bit more generic and releasing it open source for use with OpenOCD? > They've got a stub for gdb, but it needs some work to behave better with lldb. > > Ted > >> -Original Message----- >> From: lldb-dev On Behalf Of Jason >> Molenda via lldb-dev >> Sent: Tuesd

[lldb-dev] RFC: packet to identify a standalone aka firmware binary UUID / location

Hi, I'm working with an Apple team that has a gdb RSP server for JTAG debugging, and we're working to add the ability for it to tell lldb about the UUID and possibly address of a no-dynamic-linker standalone binary, or firmware binary. Discovery of these today is ad-hoc and each different

Re: [lldb-dev] [RFC] Segmented Address Space Support in LLDB

Hi Greg, Pavel. I think it's worth saying that this is very early in this project. We know we're going to need the ability to track segments on addresses, but honestly a lot of the finer details aren't clear yet. It's such a fundamental change that we wanted to start a discussion, even

Re: [lldb-dev] LLDB might not be handling DW_CFA_restore or DW_CFA_restore_extended correctly in all cases

> On Oct 8, 2020, at 10:37 PM, Greg Clayton wrote: > > > >> On Oct 8, 2020, at 10:29 PM, Jason Molenda wrote: >> >> >> >>> On Oct 8, 2020, at 10:06 PM, Jason Molenda wrote: >>> >>> >>> On Oct 8, 2020, at 9:17 PM, Greg Clayton wrote: > On Oct 8, 2020, at

Re: [lldb-dev] LLDB might not be handling DW_CFA_restore or DW_CFA_restore_extended correctly in all cases

> On Oct 8, 2020, at 10:06 PM, Jason Molenda wrote: > > > >> On Oct 8, 2020, at 9:17 PM, Greg Clayton wrote: >> >> >> >>> On Oct 8, 2020, at 8:55 PM, Jason Molenda wrote: >>> >>> Good bug find! >>> >>> It seems to me that DWARFCallFrameInfo should push the initial CIE register >>>

Re: [lldb-dev] LLDB might not be handling DW_CFA_restore or DW_CFA_restore_extended correctly in all cases

> On Oct 8, 2020, at 9:17 PM, Greg Clayton wrote: > > > >> On Oct 8, 2020, at 8:55 PM, Jason Molenda wrote: >> >> Good bug find! >> >> It seems to me that DWARFCallFrameInfo should push the initial CIE register >> setup instructions as being the state at offset 0 in the function (in fact

Re: [lldb-dev] LLDB might not be handling DW_CFA_restore or DW_CFA_restore_extended correctly in all cases

> On Oct 8, 2020, at 9:17 PM, Greg Clayton wrote: > > > >> On Oct 8, 2020, at 8:55 PM, Jason Molenda wrote: >> >> Good bug find! >> >> It seems to me that DWARFCallFrameInfo should push the initial CIE register >> setup instructions as being the state at offset 0 in the function (in fact

Re: [lldb-dev] LLDB might not be handling DW_CFA_restore or DW_CFA_restore_extended correctly in all cases

Good bug find! It seems to me that DWARFCallFrameInfo should push the initial CIE register setup instructions as being the state at offset 0 in the function (in fact I'd say it's a bug if it's not). If that were done, then getting RowAtIndex(0) should be synonymous with

Re: [lldb-dev] RFC: AArch64 Linux Memory Tagging Support for LLDB

implementation from my side will be >> an overlap with what you guys have done already. There can also be design >> conflicts and I would really appreciate it if we can come on some common >> ground regarding upstreaming of Apple's downstream pointer authentication >> patche

Re: [lldb-dev] RFC: AArch64 Linux Memory Tagging Support for LLDB

nwinder support. > > Thanks! > > On Tue, 11 Aug 2020 at 04:13, Jason Molenda via lldb-dev > wrote: > Hi David, thanks for the great writeup. I hadn't been following the gdb MTE > support. > > This all looks reasonable to me. A few quick thoughts -- > > T

Re: [lldb-dev] RFC: AArch64 Linux Memory Tagging Support for LLDB

Hi David, thanks for the great writeup. I hadn't been following the gdb MTE support. This all looks reasonable to me. A few quick thoughts -- The initial idea of commands like "memory showptrtag", "memory showtag", "memory checktag" - it might be better to put all of these under "memory tag

Re: [lldb-dev] LLDB C++ API causes SIGSEGV

Hi Rui, you need to call SBDebugger::Terminate() before your program exits. On 03/08/20 01:54 PM, Rui Liu via lldb-dev wrote: > > > Hi LLDB devs, > > I'm trying to build a debugger integration that uses LLDB C++ API. Due to > lack of documentation, I'm basically using the examples in the

Re: [lldb-dev] gdb-remote protocol questions

Hi Alexander, sorry for the delay in replying. The attached unwind log shows that lldb is using the architectural default unwind plan for this target. You can see where this unwind plan in constructed at ABISysV_mips::CreateDefaultUnwindPlan it says to find the caller's pc value at *($r29),

Re: [lldb-dev] gdb-remote protocol questions

I suspect your problem may be related to lldb not knowing how to walk the stack on this target. Is mips-unknown-linux-gnu correct? What do you see if you turn on unwind logging, 'log enable lldb unwind'. You can also have lldb show you the unwind rules at the current pc value with 'image

Re: [lldb-dev] does vFile:Open actually work?

Yeah, this is a bug in lldb's implementation of vFile:open. lldb talks to lldb-server (in platform mode) so it will work with itself, but it will not interoperate with any other implementations. That's the down side to having the client and server literally built from the same sources. :)

Re: [lldb-dev] [RFC] Fast Conditional Breakpoints (FCB)

> On Aug 22, 2019, at 3:58 PM, Ismail Bennani via lldb-dev > wrote: > > Hi Greg, > > Thanks for your suggestion! > >> On Aug 22, 2019, at 3:35 PM, Greg Clayton wrote: >> >> Another possibility is to have the IDE insert NOP opcodes for you when you >> write a breakpoint with a condition

Re: [lldb-dev] Signal stack unwinding and __kernel_rt_sigreturn

> On Jul 12, 2019, at 2:04 PM, Greg Clayton wrote: > > > >> On Jun 21, 2019, at 1:24 PM, Joseph Tremoulet via lldb-dev >> wrote: >> > >> 2 - When the user handler is invoked, its return address is set to the very >> first byte of __kernel_rt_sigreturn, which throws off unwinding because

Re: [lldb-dev] Evaluating the same expression at the same breakpoint gets slower after a certain number of steps

Hm, that's interesting. I tried running a debug lldb on /bin/ls. then I attached from another lldb. I put a breakpoint on CommandObjectTargetModulesLookup::DoExecute and resumed execution. In the debuggee lldb, I did tar mod loo -a 0 and auto-repeated return so the same command would be

Re: [lldb-dev] Unwinding call frames with separated data and return address stacks

Yeah, if you don't need to find a way to express this in DWARF, then adding a type to RestoreType would be very simple. lldb maps all the different unwind sources (debug_frame, eh_frame, arm index, compact unwind, assembly instruction scanning) into its internal intermediate representation

Re: [lldb-dev] Unwinding call frames with separated data and return address stacks

Hi Tom, interesting problem you're working on there. I'm not sure any of the DWARF expression operators would work here. You want to have an expression that works for a given frame, saying "to find the caller's pc value, look at the saved-pc stack, third entry from the bottom of that stack."

Re: [lldb-dev] RFC: Unwinding + Symbol Files: How To?

Hi Pavel, I'm open to this. I don't think there was any specific reason why UnwindTable is in the ObjectFile over the Module - it was very likely not an intentional choice when I put it there. To recap, each "binary" in the system has an UnwindTable. The UnwindTable has a list of functions it

Re: [lldb-dev] When should ArchSpecs match?

here some reason we can’t define vendors, environments, arches, and > > oses for all supported use cases? That way “there is no os” would not ever > > be a thing. > > On Thu, Dec 6, 2018 at 3:37 PM Jason Molenda via lldb-dev > > wrote: > > I think the confusi

Re: [lldb-dev] When should ArchSpecs match?

ote: > > Is there some reason we can’t define vendors, environments, arches, and oses > for all supported use cases? That way “there is no os” would not ever be a > thing. > On Thu, Dec 6, 2018 at 3:37 PM Jason Molenda via lldb-dev > wrote: > I think the confusing thing is

Re: [lldb-dev] When should ArchSpecs match?

I think the confusing thing is when "unspecified" means "there is no OS" or "there is no vendor" versus "vendor/OS is unspecified". Imagine debugging a firmware environment where we have a cpu arch, and we may have a vendor, but we specifically do not have an OS. Say armv7-apple-none (I make

Re: [lldb-dev] Using FileCheck in lldb inline tests

> On Aug 15, 2018, at 11:34 AM, Vedant Kumar wrote: > > > >> On Aug 14, 2018, at 6:19 PM, Jason Molenda wrote: >> >> It's more verbose, and it does mean test writers need to learn the public >> API, but it's also much more stable and debuggable in the future. > > I'm not sure about this.

Re: [lldb-dev] Using FileCheck in lldb inline tests

ever > have to worry about it changing. > > That said, I think history has shown that limiting ourselves to sb api tests, > despite all the theoretical benefits, leads to insufficient test coverage. So > while it has benefits, it also has problems for which we need a better > solu

Re: [lldb-dev] Using FileCheck in lldb inline tests

It's more verbose, and it does mean test writers need to learn the public API, but it's also much more stable and debuggable in the future. It's a higher up front cost but we're paid back in being able to develop lldb more quickly in the future, where our published API behaviors are being

Re: [lldb-dev] Using FileCheck in lldb inline tests

I'd argue against this approach because it's exactly why the lit tests don't run against the lldb driver -- they're hardcoding the output of the lldb driver command into the testsuite and these will eventually make it much more difficult to change and improve the driver as we've accumulated

Re: [lldb-dev] Xcode project creates too many diffs if I just add or remove a file...

Yeah, I wrote the script to accept stdin or a filename argument, and print its results. I'll fix it to hardcode looking for lldb.xcodeproj/project.pbxproj or project.pbxproj in cwd and update it in place. > On Jul 23, 2018, at 3:37 PM, Raphael “Teemperor” Isemann > wrote: > > That’s just

Re: [lldb-dev] [llvm-dev] RFC: libtrace

> On Jun 26, 2018, at 2:00 PM, Jim Ingham via lldb-dev > wrote: > > >> * unwinding and backtrace generation > > Jason says this will be somewhat tricky to pull out of lldb. OTOH much of > the complexity of unwind is reconstructing all the non-volatile registers, > and if you don't care

Re: [lldb-dev] Do we have any infrastructure for creating mini dump files from a loaded process or from a core file?

fwiw I had to prototype a new LC_NOTE load command a year ago in Mach-O core files, to specify where the kernel binary was located. I wrote a utility to add the data to an existing corefile - both load command and payload - and it was only about five hundred lines of C++. I didn't link

Re: [lldb-dev] Dlopen extremely slow while LLDB is attached

Was liblldb.so build with debug information? You're probably looking at lldb scanning the DWARF to make up its symbol table. That would be re-used on subsequent reruns so you're only seeing the cost that first time through. gdb may be using the standard dwarf accelerator tables, or it may be

Re: [lldb-dev] gdb-remote incompatibility with gdbserver?

lldb doesn't know what register set exists - if you do 'register read' you'll see that there are no registers. Maybe gdbserver doesn't implement the target.xml request (it's their packet definition! c'mon!) Download the x86_64 target def file from

Re: [lldb-dev] LLDB performance drop from 3.9 to 4.0

I don't know exactly when the 3.9 / 4.0 branches were cut, and what was done between those two points, but in general we don't expect/want to see performance regressions like that. I'm more familiar with the perf characteristics on macos, Linux is different in some important regards, so I can

Re: [lldb-dev] Is anything using the REPL?

I don't follow REPL issues very closely but I think some people may have hopes of doing a repl in a language other than swift in the future which is why it was upstreamed to llvm. J > On Mar 21, 2017, at 6:34 PM, Zachary Turner wrote: > > Thanks, I had a suspicion it

Re: [lldb-dev] Is anything using the REPL?

It's used in the swift lldb, https://github.com/apple/swift-lldb The idea is to have any non-swift specific code in llvm.org; the github repository for swift specific additions. > On Mar 21, 2017, at 6:19 PM, Zachary Turner via lldb-dev > wrote: > > AFAICT this is

Re: [lldb-dev] Bug in StackFrame::UpdateCurrentFrameFromPreviousFrame

For reference, the original code that Greg wrote in r112301 was +if (!m_disassembly.GetString().empty()) +m_disassembly.GetString().swap (m_disassembly.GetString()); > On Nov 14, 2016, at 1:44 PM, Zachary Turner wrote: > > If the swap is correct, then

Re: [lldb-dev] A problem with the arm64 unwind plans I'm looking at

I like that idea. A bunch of other work just landed on my desk so it might be a bit before I do it, but I'll see how that patch looks. > On Nov 9, 2016, at 3:54 AM, Tamas Berghammer wrote: > > Based on your comments I have one more idea for a good heuristic. What if we

[lldb-dev] A problem with the arm64 unwind plans I'm looking at

Hi Tamas & Pavel, I thought you might have some ideas so I wanted to show a problem I'm looking at right now. The arm64 instruction unwinder forwards the unwind state based on branch instructions within the function. So if one block of code ends in an epilogue, the next instruction (which is

Re: [lldb-dev] Remote Kernel Debugging using LLDB

Ah, I don't know how to do kernel debugging with macOS running under a VM. I think this sounds more like a question for the apple devforums, I think it's more of a "how do I do kext debugging with a VM", not so much an lldb question. > On Jul 28, 2016, at 7:38 PM, hrishikesh chaudhari

Re: [lldb-dev] Remote Kernel Debugging using LLDB

Is your kext loaded in lldb when you're connected to the kernel? If you do 'image list' do you see your kext there? Does it show the dSYM, which has all of the debug information, also loaded for your kext? If your kext with its dSYM is on the local filesystem, you can add a line to your

Re: [lldb-dev] Remote Kernel Debugging using LLDB

Hi, the KDK from Apple includes a README file (.txt or .html, I forget) which describes how to set up kernel debugging. I'd start by looking at those notes. There have also been WWDC sessions that talk about kernel debugging, e.g. https://developer.apple.com/videos/play/wwdc2013/707/ (there

Re: [lldb-dev] Inquiry regarding AddOneMoreFrame function in UnWindLLDB

> On May 31, 2016, at 11:31 AM, jing...@apple.com wrote: > > >> On May 31, 2016, at 12:52 AM, Ravitheja Addepally via lldb-dev >> wrote: >> >> Hello, >> I posted this query a while ago, i still have no answers, I am >> currently working on Bug 27687

Re: [lldb-dev] No breakpoints after update

If you can pause the remote process while debugging, I would start by seeing if lldb knows about any images being loaded: (lldb) image list I'd also try 'target list', 'platform status', and maybe 'log enable lldb dyld' from the start. If lldb can't figure out where the binaries are loaded in

Re: [lldb-dev] lldb 340.4.119 unable to attach (El Capitan)

> On Jan 5, 2016, at 10:17 AM, Greg Clayton via lldb-dev > wrote: > > >> So how about: >> >> (lldb) run >> error: developer mode not enabled > > We should be able to do this. The main issue is detecting that the user is in > a remote scenario where they don't have

Re: [lldb-dev] Benchmark tests

FWIW, nope, I've never messed with the benchmark tests. > On Dec 9, 2015, at 1:22 PM, Todd Fiala wrote: > > Hey Jason, > > Are you the benchmark user? > > -Todd > > On Wed, Dec 9, 2015 at 12:32 PM, Zachary Turner via lldb-dev > wrote: > Is

Re: [lldb-dev] Two CLs requiring changes to the Xcode project

Ah, my bad. It's the lldb-gtest target. > On Nov 12, 2015, at 5:49 PM, Zachary Turner wrote: > > Hmm, can you ask Todd about it? He said he added one, but I'm not sure how > it works. > > On Thu, Nov 12, 2015 at 5:46 PM Jason Molenda wrote: > Done

Re: [lldb-dev] LLDB: Unwinding based on Assembly Instruction Profiling

Hi Abhishek, > On Oct 30, 2015, at 6:56 AM, Abhishek Aggarwal wrote: > > When eh_frame has epilogue description as well, the Assembly profiler > doesn't need to augment it. In this case, is eh_frame augmented unwind > plan used as Non Call Site Unwind Plan or Assembly

Re: [lldb-dev] Using DYLD_LIBRARY_PATH and lldb

If it's on Mac OS X 10.11, I saw this the other day. e.g. sh-3.2$ cat a.c #include #include int main() { printf("%s\n", getenv("DYLD_LIBRARY_PATH")); } sh-3.2$ clang a.c sh-3.2$ lldb -x a.out (lldb) target create "a.out" Current executable set to 'a.out' (x86_64). (lldb) pro lau -v

Re: [lldb-dev] LLDB: Unwinding based on Assembly Instruction Profiling

Hi all, sorry I missed this discussion last week, I was a little busy. Greg's original statement isn't correct -- about a year ago Tong Shen changed lldb to using eh_frame for the currently-executing frame. While it is true that eh_frame is not guaranteed to describe the prologue/epilogue, in

Re: [lldb-dev] LLDB: Unwinding based on Assembly Instruction Profiling

> On Oct 19, 2015, at 2:54 PM, Jason Molenda via lldb-dev > <lldb-dev@lists.llvm.org> wrote: > Greg's original statement isn't correct -- about a year ago Tong Shen changed > lldb to using eh_frame for the currently-executing frame. While it is true > that eh_fr

Re: [lldb-dev] Can't debug with a -g compiled binary as a non-root user on OS X 10.11 El Capitan

(resending my reply with a Cc to lldb-dev - System Integrity Protection in Mac OS X 10.11 El Capitan has impact on lldb in several important ways, I think others will be interested.) Yes, System Integrity Protection in El Capitan includes the restriction that nothing can be modified in