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: Pedro Alves <palves at redhat dot com>
- To: Paul_Koning at Dell dot com, gbenson at redhat dot com
- Cc: sandra at codesourcery dot com, gdb at sourceware dot org
- Date: Fri, 24 Jul 2015 17:05:59 +0100
- 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>
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=/".
Thanks,
Pedro Alves