Re: [lldb-dev] gdb-remote incompatibility with gdbserver?
On 12/05/2017 09:50 PM, Greg Clayton via lldb-dev wrote: > >> On Dec 5, 2017, at 12:45 PM, Pedro Alves wrote: >> >> On 12/05/2017 06:49 PM, Greg Clayton via lldb-dev wrote: >> >>> Though it does seem to be a bug that the "gdbserver" you were using doesn't >>> support the Target XML packets that the GDB remote protocol defines? Is >>> this some old version of GDB remote from many many years ago? Seems any >>> recent gdbserver should have this feature? >> >> The x86 port of gdbserver won't send back a XML target description >> unless the client includes "xmlRegisters=i386" in the initial >> qSupported negotiation. (This was done at the same time support >> for x86 XML descriptions was added in order to keep new-gdbserver >> working against old-gdb, because the XML register layout doesn't match >> the no-XML layout.) > > Interesting! So would we add xmlRegisters=i386 to qSupported for i386 and > xmlRegisters=x86_64 for x86_64? We should have LLDB send this down to the > server then and everything would just work? It's "xmlRegisters=i386" for both 32-bit/64-bit. I don't know whether that's all you're missing. I should qualify "doesn't send back" better. To be more accurate, without "xmlRegisters=i386" gdbserver still reports back a XML description in response to "qXfer:features:read:target.xml". But, that description matches the register file/layout that predated x86 XML target descriptions. GDB still connects and debugs fine in that case (just tried it on x86_64), but the problem will be that that description (and the resulting g/G packet layout) doesn't include all the new registers that have been added over the years (SSE, etc.). So sounds like there may be more to it. Pedro Alves ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] gdb-remote incompatibility with gdbserver?
On 12/05/2017 11:17 PM, David Manouchehri wrote: > Is there a user accessible setting to force on XML target descriptions > in new-gdbsever? In gdbserver? Nope. There's a setting in GDB to force it to not fetch descriptions, which I found out today didn't actually work. Fixed now in master [1]. GDB works fine against gdbserver with XML force-disabled, so I suspect something else is going on. Maybe a disagreement about who adjusts the PC after a breakpoint trap between lldb and gdbserver? (given the spurious SIGTRAPs and SIGSEGVs) gdb and gdbserver negotiate that via qSupported. If both agree on the "swbreak+" feature, then gdbserver handles it (and reports a "T05 swbreak" for int3 traps). Otherwise gdbserver assumes that the client (gdb/lldb) will, so doesn't do it itself. I did a quick grep on a lldb checkout I had around here and didn't find any "swbreak" hit, but maybe lldb assumes the server does it? Really just guessing though. [1] https://sourceware.org/ml/gdb-patches/2017-12/msg00121.html Thanks, Pedro Alves ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] How to handle "O XX..." reply packets from gdb servers like openocd
On 01/03/2018 07:11 PM, Greg Clayton via lldb-dev wrote: > >> On Jan 1, 2018, at 6:30 PM, Owen Shaw via lldb-dev >> wrote: >> >> I dug into this a bit more, and these output reply packets seem to be >> handled already, but only if the program is running. > >> Since the relevant openocd commands are often issued when the program >> paused, the reply packets aren't processed as expected. >> >> The spec does say that reply packets can happen "any time while the >> program is running", so perhaps openocd is abusing the protocol, but >> gdb handles the packets just fine when stopped. > > Yes, LLDB is assuming that an "O" packet will only come during a continue > command. "O" is for stdout output and it seems the rCmd assuming it will > work. Why not just send back the text in response to the rCmd? Is some common > code path being hit where it might send this text while running and also in > response to the rCmd? I am confused by "O" packets are needed in response to > the rCmd. qRcmd was invented well before my time, but qRcmd provides support for running random interpreter commands on the server, with the resulting output being potentially long, unbounded. Thus sending the text back in response to qRcmd would require an unbounded packet buffer and would potentially hit the max packet size. So you'd need some way to send partial output in chunks. Which ends up being exactly what you get by reusing "O". > If the rCmd can't be fixed to just return the text without using "O" packets, The documentation of the qRcmd packet explicitly specifies that output should be sent via "O" packets: https://sourceware.org/gdb/onlinedocs/gdb/General-Query-Packets.html#index-qRcmd-packet Sounds like OpenOCD is working as intended. Pedro Alves ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [RFC] Fast Conditional Breakpoints (FCB)
Hi, Very interesting. One comment below, about something that jumped at me when I skimmed the proposal. On 8/14/19 9:52 PM, Ismail Bennani via lldb-dev wrote: > > Since the x86_64 ISA has variable instruction size, LLDB moves enough > instructions in the trampoline to be able to overwrite them with a jump to the > trampoline. If I understood you correctly, you meant to say that LLDB moves enough instructions _at the breakpoint address_ to be able to overwrite them with a jump to the trampoline? It's the plural (instructionS) that jumped at me. If so, how do you plan to handle the case of some thread currently executing one of the instructions that you're overwriting? Say, you're using a 5 bytes jmp instruction to jump to the trampoline, so you need to replace 5 bytes at the breakpoint address. But the instruction at the breakpoint address is shorter than 5 bytes. Like: ADDR | BEFORE | AFTER --- | INSN1 (1 byte) | JMP (5 bytes) 0001 | INSN2 (2 bytes) | <<< thread T's PC points here 0002 | | 0003 | INSN3 (2 bytes) | Now once you resume execution, thread T is going to execute a bogus instruction at ADDR 0001. GDB does something similar to this for fast tracepoints (replaces the tracepointed instruction with a jump to a trampoline area that does the tracepoint collection, all without traps), and because of the above, GDB currently keeps it simple and only allows setting fast tracepoints at addresses with instructions longer than the jump-to-trampoline jump instruction used. Thanks, Pedro Alves ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [RFC] Fast Conditional Breakpoints (FCB)
On 8/22/19 12:36 AM, Ismail Bennani via lldb-dev wrote: >> On Aug 21, 2019, at 3:48 PM, Pedro Alves wrote: >> Say, you're using a 5 bytes jmp instruction to jump to the >> trampoline, so you need to replace 5 bytes at the breakpoint address. >> But the instruction at the breakpoint address is shorter than >> 5 bytes. Like: >> >> ADDR | BEFORE | AFTER >> --- >> | INSN1 (1 byte) | JMP (5 bytes) >> 0001 | INSN2 (2 bytes) | <<< thread T's PC points here >> 0002 | | >> 0003 | INSN3 (2 bytes) | >> >> Now once you resume execution, thread T is going to execute a bogus >> instruction at ADDR 0001. > > That’s a relevant point. > > I haven’t thought of it, but I think this can be mitigated by checking at > the time of replacing the instructions if any thread is within the copied > instructions bounds. > > If so, I’ll change all the threads' pcs that are in the critical region to > point to new copied instruction location (inside the trampoline). > > This way, it won’t change the execution flow of the program. Yes, I think that would work, assuming that you can stop all threads, or all threads are already stopped, which I believe is true with LLDB currently. If any thread is running (like in gdb's non-stop mode) then you can't do that, of course. > > Thanks for pointing out this issue, I’ll make sure to add a fix to my > implementation. > > If you have any other suggestion on how to tackle this problem, I’d like > really to know about it :). Not off hand. I think I'd take a look at Dyninst, see if they have some sophisticated way to handle this scenario. Thanks, Pedro Alves ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [RFC] Fast Conditional Breakpoints (FCB)
If you can rely on the IDE & compile&debug, you might as well made the IDE&compiler bake in the breakpoint condition and trompoline into the code without having to have the debugger build the trampoline afterwards. Thanks, Pedro Alves On 8/22/19 11: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 and compile NOPs into your program. > > So the flow is: > - set a breakpoint in IDE > - modify breakpoint to add a condition > - compile and debug, the IDE inserts NOP instructions at the right places > - now when you debug you have a NOP you can use and not have to worry about > moving instructions > > >> On Aug 22, 2019, at 5:29 AM, Pedro Alves via lldb-dev >> wrote: >> >> On 8/22/19 12:36 AM, Ismail Bennani via lldb-dev wrote: >>>> On Aug 21, 2019, at 3:48 PM, Pedro Alves wrote: >> >>>> Say, you're using a 5 bytes jmp instruction to jump to the >>>> trampoline, so you need to replace 5 bytes at the breakpoint address. >>>> But the instruction at the breakpoint address is shorter than >>>> 5 bytes. Like: >>>> >>>> ADDR | BEFORE | AFTER >>>> --- >>>> | INSN1 (1 byte) | JMP (5 bytes) >>>> 0001 | INSN2 (2 bytes) | <<< thread T's PC points here >>>> 0002 | | >>>> 0003 | INSN3 (2 bytes) | >>>> >>>> Now once you resume execution, thread T is going to execute a bogus >>>> instruction at ADDR 0001. >>> >>> That’s a relevant point. >>> >>> I haven’t thought of it, but I think this can be mitigated by checking at >>> the time of replacing the instructions if any thread is within the copied >>> instructions bounds. >>> >>> If so, I’ll change all the threads' pcs that are in the critical region to >>> point to new copied instruction location (inside the trampoline). >>> >>> This way, it won’t change the execution flow of the program. >> >> Yes, I think that would work, assuming that you can stop all threads, >> or all threads are already stopped, which I believe is true with >> LLDB currently. If any thread is running (like in gdb's non-stop mode) >> then you can't do that, of course. >> >>> >>> Thanks for pointing out this issue, I’ll make sure to add a fix to my >>> implementation. >>> >>> If you have any other suggestion on how to tackle this problem, I’d like >>> really to know about it :). >> >> Not off hand. I think I'd take a look at Dyninst, see if they have >> some sophisticated way to handle this scenario. >> >> Thanks, >> Pedro Alves >> ___ >> lldb-dev mailing list >> lldb-dev@lists.llvm.org >> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
