This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFC] Don't create inferior in tfile target.
- From: Pedro Alves <palves at redhat dot com>
- To: Yao Qi <yao at codesourcery dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Wed, 15 May 2013 16:33:36 +0100
- Subject: Re: [RFC] Don't create inferior in tfile target.
- References: <1367631071-20079-1-git-send-email-yao at codesourcery dot 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