Re: attach u/i oddity

[Doug Evans <dje at google dot com>]

On Tue, Oct 11, 2011 at 4:17 AM, Pedro Alves <pedro@codesourcery.com> wrote:
> On Tuesday 11 October 2011 07:16:36, Joel Brobecker wrote:
>> > The user never specified forever.x32 as the program to debug, gdb was
>> > being clever. ?However, if it's going to be clever the first time,
>> > it's a bug (from the user's perspective) to not be clever the second
>> > time too (IMO).
>>
>> I agree. I was surprised by the reported behavior.
>
> I can't see how to change that while both keeping it simple, and
> avoiding breaking valid use cases. ?Users need to be able to specify a
> different executable/file than what the OS reports the process is running,

We don't need to make this case simple though.
I'd be surprised if it was the more frequent case (or even close).
Even if that case required several commands, as long as it was
robustly scriptable that would be fine.
We should be optimizing for the common case.

> and "file FOO; attach PID" is the idiom GDB uses since forever for that.

In this case the user explicitly specified the file.
One way to go (though I'm not entirely happy with it) would be to
continue to be clever as long as we didn't override what the user
explicitly specified.

> Maybe what we need a `warning' so that the surprise is gone:
>
> ?"warning: assuming process is running the loaded executable `FOO'
> ?which is different from the executable the target reports the process "
> ?is running. ?Unload it with the `file' command to make gdb find and load
> ?the target reported executable automatically."

A warning is needed, but it doesn't correct the broken default
behaviour (IMO, YMMV).
It's too bad we don't have a formal mechanism for deprecating and
ultimately deleting broken command behaviour, API elements, etc.
[I wonder how much pushback there would be to introducing one.
I don't know if I'd ultimately want to incompatibly change GDB in this
particular case, but I
do know there are changes I've wanted to make that break compatibility.]

The "file" command needs to do more to make this completely work btw.
E.g., it needs to effect a reloading of thread_db (which would fix
"gdb -c core, file foo" for the dynamic case).

We could add an option to attach (attach -f PID, or whatever) that
explicitly set the file, overriding what's currently in effect.

> ( certainly needs copy/editing :-) )
>
> Note this would be tricky to get right for remote targets. ?Also,
> not all targets can fetch the running executable on attach.

Sure, but that didn't stop making attach be clever in the first place. :-)