Re: GDB now takes 4 minutes to start up with remote gdbserver target

[Pedro Alves <palves@redhat.com>]

On 07/24/2015 05:58 PM, Paul_Koning@Dell.com wrote:
> 
>> On Jul 24, 2015, at 12:05 PM, Pedro Alves <palves@redhat.com> wrote:
>>
>> On 07/24/2015 04:27 PM, Paul_Koning@Dell.com wrote:
>>
>>> But having sysroot default to target is also a bad idea for lots of other people.  Consider embedded systems: you presumably have stripped images there, but unstripped ones on your build host.
>>
>> But in that scenario, with the old default sysroot, how was gdb finding
>> the binaries on the build host?  The binaries on the equilalent locations
>> on the host's root will certainly not match the embedded/target system's.
>> In that scenario, you must have been pointing the "set sysroot" somewhere
>> local?  And if you do that, nothing changes in 7.10, gdb will still access
>> the files on the local filesystem.
>>
>> From the discussion so far, it seems that the only case that ends up
>> regressing is the case where the host and target share both the
>> filesystem, and the host/target paths match.  I don't know off hand how to
>> make gdb aware of that automatically.
>>
>> That seems like enough of a special case that could well be handled
>> by an explicit "set sysroot /" in e.g., the toolchain's system-gdbinit, or
>> by building gdb with "--with-sysroot=/“.
> 
> If you’re doing cross-builds, then yes, you’d have a non-default sysroot.  But if the host and target are the same OS, but the target has a small local file system with stripped images on it, then the default sysroot was valid in the past, but the new default is not.

And in case the host and target are the same OS, but the binaries are
of different versions (which happens frequently, machines
don't usually update their packages at exactly the same time), then
the default is almost right, but then the user gets misleading backtraces.

It seems to me like if you take the trouble to build such a setup
as you suggest, putting a "set sysroot /" somewhere is just another
small setup step.

The idea of the new default was both what's more convenient in the wider
set of use cases and also picking correctness over efficiency, while still
letting the user point at local copies of files (or set sysroot /dev/null
to point nowhere, for e.g.) to get efficiency back, when possible.

The discoverability of the need to do the latter I believe should be
treated as a separate matter, which seems could be resolved with a warning
around "warning: fetching files from the target.  Use "set sysroot" to
point at local copies for faster access." or some such, as has already
been suggested elsewhere.  IOW, if we had that already, how bad would it
really be if target: remains the default?

Thanks,
Pedro Alves