Re: [PATCH] Make only user-specified executable filenames sticky

[Pedro Alves <palves@redhat.com>]

On 05/13/2015 08:54 AM, Gary Benson wrote:

> I asked already, but nobody answered, so...

I did reply :-)  Here:

 https://sourceware.org/ml/gdb-patches/2015-05/msg00273.html

> 
> If you say "attach PID", and GDB can see that PID's executable is
> /foo/bar, and the current exec-file is not /foo/bar/, under what
> circumstances should GDB *not* automatically reload the new exec-
> file?  

For the symbol-file part, it's clear: we need the debug info
that might well be missing on the running copy of the binary
(I know that's not what you're asking).

When the running image does not have all the info we need out
of the executable (in which case you'll have passed a non-stripped
binary to gdb).  I pointed out section info, as that's what I thought
of off hand.  There may be other bits needed.  Grepping around for
exec_bfd may find more.  Of course, determining whether the
file has the necessary bits requires downloading/opening
the file, which is something the user may want to avoid.

> i.e. why could this "attach -f" behavior not be the default?

If we come up with means to force usage of the current
exec, maybe.  Though maybe we're trying to make gdb
too smart, as in, some obscure cases things may go wrong,
depending on program/binary and target you connect to,
which is confusing.  The "user-specified==sticky" idea seems
simpler to explain to users to me.  If GDB warned on exec-file vs
running image mismatch, I think the default would matter less.

Thanks,
Pedro Alves