Re: [RFC] Don't create inferior in tfile target.

[Pedro Alves <palves@redhat.com>]

On 05/04/2013 02:31 AM, Yao Qi wrote:
> In ctf target, we don't create inferior when open ctf trace file,
> however we do it in tfile target.  After read the code for a while, I
> don't see any reason that we need an inferior here.  The code was
> added along with the tfile support patch, and was modified once by
> patch [1]
> 
> I checked out the code on the revision before patch [1] was applied
> bd196e7a61b03f2ea7e5dcb0aecbd49d239d6390 and I am able to reproduce
> the same internal error, However, I am wondering why do we need
> inferior in tfile target.  I removed the code to create inferior in
> tfile_open and remove inferior in tfile_close.  The internal error can
> be fixed also.  I also checked that 'info threads' and 'info
> inferiors' works properly.
> 
> I talked with Stan (he wrote tfile supported code) on this, but we were
> unable to recall the reason in details on creating inferior.  I post
> this patch to remove the code to create inferior in tfile target.
> Comments are welcome.

I have a very vague recollection that it was I who suggested this
in internal reviews at the time, but GDB was a bit different then,
and I don't recall exactly why.  It's possible you might find that
in CS's archives.

The whole tfile/tracepoints model is weird, in that it's hacked
on, and bypasses the whole target stack model.  You get
things like, while inspecting a traceframe (on targets where
threads are a kernel entity), "info threads" lists you the threads
the live target happens to have at the moment.  Same with shared
libraries, etc.  This could/should probably be revisited once
gdb learns about being connected to multiple targets simultaneously.

I was going to say this would break "detach" with tfile
(detach_command checks for null_ptid).  Except "detach" with tfile
doesn't work already -- with target core,
"detach" unloads the core, and I assumed tfile behaved the same.
I think it'd be reasonable if it did.

You didn't mention it explicitly, so I'll ask.
There are probably more commands that treat null_ptid magically.
Could you audit kill, detach, continue, step, etc.
to see if they'll do something reasonable?  Or rather,
could you audit/grep the tree for null_ptid uses?  E.g.,
I see that dcache.c uses null_ptid as magic number, but
probably that doesn't matter for tfile.  There don't seem
to be that many checks for null_ptid, and many are in run
control code, which obviously doesn't apply, so an audit
seems doable.

Thanks,
-- 
Pedro Alves