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

[Pedro Alves <palves at redhat dot com>]

On 07/24/2015 06:18 PM, Sandra Loosemore wrote:
> On 07/24/2015 10:05 AM, Pedro Alves 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.
> 
> 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.  

Doesn't care, until she wants to backtrace across code in the shared
library, e.g., across qsort, or until she starts wondering what are
all those ???'s in the backtrace.

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

I fully agree that those should be fixed.  If GDB had warned giving a
"set sysroot" suggestion, and the slow retrieval was cancelable, would we
be discussing the new default?

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

Over the years we kept hearing the same in the other direction -- 'why
do we have to point at copies of local files, or explicitly
do "set sysroot remote:"?  Why isn't "remote:" the default sysroot?
Why doesn't GDB "just work" by default?'

The definition of "just work" here depends on perspective.  We're
just looking at this from different angles.

Thanks,
Pedro Alves