[PATCH 00/10] Improve GDB/gdbserver experience when using a local gdbserver

[Andrew Burgess]

Mark Wielaard <mark@klomp.org> writes:

> Hi Andrew,
>
> On Wed, 2023-08-16 at 16:54 +0100, Andrew Burgess wrote:
>> The goal of this series is to improve the user experience when using a
>> local (running on the same machine as GDB) gdbserver.
>> 
>> Outside of testing, there are still plenty of occasions when a user
>> can end up running gdbserver on the same machine as GDB, tools like
>> valgrind communicate via the remote protocol, as do many simulators
>> (other than those built into GDB).
>> 
>> This series includes the following improvements:
>> 
>>   1. Better handling of gdbserver's default executable and arguments.
>>   This applies to remote gdbservers and local gdbservers,
>> 
>>   2. Allow sysroot 'target:' prefix to be ignored when gdbserver is
>>   running locally to GDB, and
>> 
>>   3. Allow the user to skip setting 'remote exec-file' if gdbserver is
>>   running locally to GDB.
>
> I read through most of this patch series and created a trivial
> qDefaultExecAndArgs for vgdb that just returns 'U' and it seems to work
> just fine, no more setting of remote exec-file needed \o/
> https://bugs.kde.org/show_bug.cgi?id=473687

Excellent.

> I have to think a bit more about qMachineId.
> There were also some opinions expressed in this bug:
> https://sourceware.org/bugzilla/show_bug.cgi?id=30541

Thanks for the link.  I'd not read that.  I think the only thing I took
from that was that the boot-id that I'm currently using likely isn't
going to work w.r.t. containers -- but Thiago Jung Bauermann already
pointed that out.

We already have some container detection support (at least, I believe
that's what it's doing) in linux_nat_target::filesystem_is_local (), so
I'm hoping I can use something based off that to extend what I currently
have.

It's just testing it that's going to slow me down, but I hope to take
another pass at it soon.

Thanks,
Andrew