[Lldb-commits] [PATCH] D62931: [lldb-server] Add setting to force 'g' packet use

[Jason Molenda via lldb-commits]

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 <jmolenda at 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 <jmolenda at 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 <reviews at 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
>>> 
>>> 
>>> 
>> 
>