Re: attach u/i oddity

[Doug Evans <dje@google.com>]

On Tue, Oct 11, 2011 at 11:56 AM, Pedro Alves <pedro@codesourcery.com> wrote:
> On Tuesday 11 October 2011 19:11:21, Doug Evans wrote:
>> On Tue, Oct 11, 2011 at 10:20 AM, Pedro Alves <pedro@codesourcery.com> wrote:
>> >> We don't need to make this case simple though.
>> >> I'd be surprised if it was the more frequent case (or even close).
>> >
>> > Err.  It's close.  The "different executable" is usually the one
>> > with debug info, while the one deployed in the target/system is the
>> > one without debug info.
>> >
>> >> Even if that case required several commands, as long as it was
>> >> robustly scriptable that would be fine.
>> >
>> > I don't take it so lightly.  This is quite old behavior.  We
>> > should not break things unless there's very good reason.
>>
>> No disagreement here.
>> I'm curious what motivated inferring I was taking it lightly.
>
> Well, all the extra talk about deprecating and deleting commands.

One should be free to talk about such things without having the
listener insert things between the lines.
It's a BIG step to go from simply talking about deprecating and
deleting commands (*1) to taking them lightly.

(*1): I actually said "ultimately deleting broken command behaviour",
and by that I meant no longer supporting whatever it is that was
deprecated.

>> >> > 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.
>> >
>> > What I don't like about that, is that is adds state, that is likely
>> > to confuse users one way or another anyway.
>>
>> Yep.
>> OTOH, I claim the current behaviour is already confusing. :-)
>>
>> > Sometimes we can't
>> > avoid it, but stateless things are easier to grok.
>>
>> Yadayada ...?  1/2 :-)
>
> ;-)
>
>> >> 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).
>> >
>> > It's a bit unrelated, wouldn't you say?
>>
>> Eh?  I don't understand.
>
> I don't understand what is "this" in "make this completely work"
> was then.

"this" can be ambiguous. :-)

> I don't understand what file not having an effect on
> reloading of thread_db has to do with the case we're discussing.

I was pointing out that file;attach is not (currently) equivalent to
attach;file.
i.e. it's not enough to do attach,detach,attach, find out that the
second attach didn't work as expected, and then try to fix things up
by then doing "file".  If "file" is a legit thing to do after an
attach, then ISTM we've still got work to do.

E.g., ref: http://sourceware.org/ml/gdb-patches/2011-10/msg00182.html

(gdb) file wrong_executable
(gdb) attach PID or core-file core.1234
whooops!
(gdb) file right_executable

>> >> We could add an option to attach (attach -f PID, or whatever) that
>> >> explicitly set the file, overriding what's currently in effect.
>> >
>> > That would work for me.  But then again, if you know to do this,
>> > you can also do "file; attach" (or define myattach...).
>> >
>> >> > ( 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. :-)
>> >
>> > I can't imagine _not_ wanting it to be clever when I don't
>> > have a file loaded yet.
>>
>> I can't imagine not wanting the simple case of attach,detach,attach to
>> Just Work.
>
> Your definition of "Just Work" conflicts with other use cases where
> it Just Works...  We need to compromise while avoiding breaking
> things.  "attach -f" (or whatever the spelling) was one way.  A bit
> more verbosity was another.  Enhancing the documentation is yet another.
> And none of these is mutually exclusive.
>
>> "But seriously ..."
>> There was some cleverness that was wanted, was "tricky to get right
>> right for remote targets. Also not all targets can fetch the running
>> executable on attach", and yet was added anyway.  Awesome.
>
> In addition to the misunderstanding I pointed out in the other email,

Like I said, "this" can be ambiguous ...

> there's tons of things that some targets can't do, yet that shouldn't
> block implementing the features in targets that can.

Yep.

> It would also be
> reasonable to print something like "warning: no exec loaded, and can't
> infer exec from target" for targets where we can't get it from the
> target.

"works for me"