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] gdb-remote incompatibility with gdbserver?
On 6 December 2017 at 12:40, Pedro Alves via lldb-dev wrote: > 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? > I think that could be (a part of) the problem. lldb-server always adjusts the PC (see NativeProcessLinux::FixupBreakpointPCsAsNeeded). I am unsure whether there is any additional fixup logic in the client. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] [6.0.0 Release] Scheduling the release
Hello everyone, It's time to start making plans for the 6.0.0 release. Following our regular schedule, the branch would occur about two weeks into January, on Wednesday 17 January 2018, with the goal of shipping early March. This is the schedule I would propose. However, one large consumer of the branch has asked if we could start earlier this time, branching on 3 January instead (not moving the ship date), to get a longer period for stabilization that syncs with their internal process. While I'm hesitant to change the schedule because I think it's important that it's predictable, there is a benefit of having large users "in sync" with the upstream release branch, as that means more people testing the same code. I will be out of the office the first weeks of January (and I'm guessing other members of the community might be too), so while I could get the branch started on the 3rd, it would be a kind of "slow-start" of the process, but still allow those who want to start testing and nominating merges to do so. Ultimately, it comes down to what the community prefers. Should we stick to the regular schedule, or should we do the "slow-start" two weeks early this time? Let me know what you think, especially those of you involved in the release testing. Cheers, Hans ___ 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?
Does ds2 have the same behavior? Took a glance and didn't see it. On Dec 6, 2017 7:47 AM, "Pavel Labath" wrote: > On 6 December 2017 at 12:40, Pedro Alves via lldb-dev > wrote: > > 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? > > > > I think that could be (a part of) the problem. lldb-server always > adjusts the PC (see NativeProcessLinux::FixupBreakpointPCsAsNeeded). I > am unsure whether there is any additional fixup logic in the client. > ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [6.0.0 Release] Scheduling the release
> -Original Message- > From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Hans > Wennborg via lldb-dev > Sent: Wednesday, December 06, 2017 9:29 AM > To: Release-testers; llvm-dev; cfe-dev; LLDB Dev; openmp-dev (openmp- > d...@lists.llvm.org) > Subject: [lldb-dev] [6.0.0 Release] Scheduling the release > > Hello everyone, > > It's time to start making plans for the 6.0.0 release. > > Following our regular schedule, the branch would occur about two weeks > into January, on Wednesday 17 January 2018, with the goal of shipping > early March. This is the schedule I would propose. > > However, one large consumer of the branch has asked if we could start > earlier this time, branching on 3 January instead (not moving the ship > date), to get a longer period for stabilization that syncs with their > internal process. I'm very sympathetic to syncing upstream stabilization with internal processes; that said, branching so soon after New Year's Day (which I'd guess is celebrated essentially everywhere) seems like not such a great idea. This is not a strong objection, more of an observation. Can I make a counter-offer of Monday, 8 January? If that's a real problem, then we can live with 3 January. --paulr > > While I'm hesitant to change the schedule because I think it's > important that it's predictable, there is a benefit of having large > users "in sync" with the upstream release branch, as that means more > people testing the same code. > > I will be out of the office the first weeks of January (and I'm > guessing other members of the community might be too), so while I > could get the branch started on the 3rd, it would be a kind of > "slow-start" of the process, but still allow those who want to start > testing and nominating merges to do so. > > Ultimately, it comes down to what the community prefers. Should we > stick to the regular schedule, or should we do the "slow-start" two > weeks early this time? > > Let me know what you think, especially those of you involved in the > release testing. > > Cheers, > Hans > ___ > lldb-dev mailing list > lldb-dev@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
