This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: GDB now takes 4 minutes to start up with remote gdbserver target
- From: <Paul_Koning at Dell dot com>
- To: <palves at redhat dot com>
- Cc: <gbenson at redhat dot com>, <sandra at codesourcery dot com>, <gdb at sourceware dot org>
- Date: Fri, 24 Jul 2015 16:58:38 +0000
- Subject: Re: GDB now takes 4 minutes to start up with remote gdbserver target
- Authentication-results: sourceware.org; auth=none
- References: <55B1768E dot 9090309 at codesourcery dot com> <55B1A4FC dot 9010403 at codesourcery dot com> <20150724085244 dot GB22673 at blade dot nx> <55B2444C dot 106 at codesourcery dot com> <2906903F-7478-4B9D-8A9A-A6256F8076EF at dell dot com> <20150724151148 dot GA18553 at blade dot nx> <FC7D3C21-A8E8-4316-8125-E9FCE152F5D0 at dell dot com> <55B26267 dot 4060905 at redhat dot 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