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

Paul_Koning
2015-07-24T16:58:44Z

> 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