Re: GDB now takes 4 minutes to start up with remote gdbserver target
Gary Benson <[email protected]>
| Newsgroups | gmane.comp.gdb.devel |
|---|---|
| Message-ID | <[email protected]> |
Sandra Loosemore wrote: > On 07/24/2015 10:05 AM, Pedro Alves wrote: > > On 07/24/2015 04:27 PM, [email protected] 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. > > There's also the case where the host and target sysroot locations do > not match at all. As I said, this used to work reasonably well for > application debugging, where the user isn't interested in debugging > shared libraries and doesn't care if the shared library symbol > information isn't available to GDB. It used to print a helpful > message suggesting using "set sysroot" if the user wants the shared > library information, instead of hanging on startup with no > indication of what the trouble is or how to fix it. I can't see the > new default behavior as an improvement over the old. > > > 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=/". > > There are a bunch of possible workarounds for this, but why can't we > make GDB "just work" by default, as it used to, instead of requiring > users to build GDB differently or install a workaround or issue > extra commands manually that they didn't used to need at all? I have an idea for a solution to this. I should know in a few hours if it can work. Tomorrow morning at the very latest. Thanks, Gary -- http://gbenson.net/