Re: attach u/i oddity

[Pedro Alves <pedro at codesourcery dot com>]

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.

> >> > 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.  I don't understand what file not having an effect on 
reloading of thread_db has to do with the case we're discussing.

> >> 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,
there's tons of things that some targets can't do, yet that shouldn't
block implementing the features in targets that can.  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.

-- 
Pedro Alves