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

[Stan Shebs <stanshebs@earthlink.net>]

On 5/15/13 8:33 AM, Pedro Alves wrote:
> 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.

We've poked around those, haven't found anything specific.  At the time
we were also working on multi-process support and other ideas, it might
simply be that it seemed like it was going to be required in the near
future. (Wouldn't be the first time that Stan added gratuitous
future-anticipating code, ahem.)

> 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.

Heh, yeah, we've certainly discussed that ourselves, and I remember
multiple discussions with Andrew, Michael, etc on the subject as well.

I take the view that the target stack is a flawed concept, in that it
makes sense for the simple exec/process/core trio, and breaks down for
just about every other situation.  It has needed hacks and workarounds
ever since it was introduced ("strata", etc).  It probably wouldn't even
be that hard to replace with a functional model where you pass an
inheritance chain to a manipulating function and get back a new chain
that may be arbitrarily different ("push" and "pop" being two common
cases); the amount of code involved is less than has been changed in
other recent restructuring projects.

Stan
stan@codesourcery.com