I'm switching the default for at least the weekend via 60ab30ebce833c87bd4776f67cd9a82fe162ef9c / https://reviews.llvm.org/rG60ab30ebce83 so the bots aren't failing because of this, we can all look into this next week. I think the best solution is to get lldb to fall back to p/P if g/G are not supported (which we need to talk to some targets), and disable debugserver's g/G packet support until I can debug where the bug is over there.
I'm still concerned about some of the macos CI bots which use the installed debugservers, which will continue to have this g/G bug for a while, we'll figure all that out next week. > On Nov 8, 2019, at 5:41 PM, Jason Molenda <jmole...@apple.com> wrote: > > Hm, a follow-on problem is that there's some bug between debugserver and lldb > with the g/G packets which is causing bot failures on macos systems. lldb has > never used g/G before (if p/P was available) because debugserver seeds all of > the GPR values with the stop packet (? aka Tnn) or with the jThreadsInfo > packet when we have a public stop and want the GPRs for all the threads, so > there was no driving perf need. > > g/G would be a perf benefit if you were fetching the floating point registers > on every step, which could definitely happen in an IDE, but it's not common, > so we stuck with the simpler p/P. > > Given that TestRegisters.py and some filecheck tests are failing on macos the > bots, I think it might be best to change the default value for > plugin.process.gdb-remote.use-g-packet-for-reading to false until next week > when we can get to the bottom of the debugserver g/G issue. > > I'm not sure of the configuration of the bots; I think some of them use the > installed debugserver binaries (which are code signed by apple etc) instead > of the just-built one. I'm not sure how we'll structure TestRegisters.py and > the filecheck tests to handle the difference correctly. We can figure that > out next week. > > > J > >> On Nov 8, 2019, at 4:15 PM, Jason Molenda <jmole...@apple.com> wrote: >> >> A heads-up - lldb is failing to detect the case where the remote gdb RSP >> stub does not support the 'g' packet. I found this while doing some bare >> board debugging; g fails and doesn't fall back to fetching register values >> individually. >> >> I wrote a test TestNoGPacketSupported.py to show this behavior - it's >> currently marked as @expectedFailureAll. If I add the >> plugin.process.gdb-remote.use-g-packet-for-reading = false setting, the test >> case passes, but of course we can't require people to use that. lldb has to >> be adaptive to the packets that the remote stub supports. >> >> >> I'll try to look at the updating the changes to work correctly in this >> environment, but I wanted to raise the issue more widely in case anyone has >> a chance before me. >> >> >> J >> >> >>> On Oct 30, 2019, at 9:30 AM, Guilherme Andrade via Phabricator >>> <revi...@reviews.llvm.org> wrote: >>> >>> guiandrade added a comment. >>> >>> In D62931#1726865 <https://reviews.llvm.org/D62931#1726865>, @labath wrote: >>> >>>> This looks fine to me. Thanks for your patience. Do you still need someone >>>> to commit this for you? >>> >>> >>> Np. Yes, I do. Could you please do it for me? >>> >>> Thanks! >>> >>> >>> Repository: >>> rG LLVM Github Monorepo >>> >>> CHANGES SINCE LAST ACTION >>> https://reviews.llvm.org/D62931/new/ >>> >>> https://reviews.llvm.org/D62931 >>> >>> >>> >> > _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
