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

[Paul_Koning@Dell.com]

> 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.

	paul