This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [rfa/threads] Eliminate lin-lwp.c
On Thu, Sep 16, 2004 at 05:11:27PM -0400, Andrew Cagney wrote:
> >I do not think that leaving these functions where they are will
> >complicate the process of cleaning them up. Could you explain
> >why you see this as a problem?
>
> As with inf-child and inf-ptrace, an important objective here is to get
> all the inf-linux methods local to a file so that we can ensure that all
> accesses are strictly via the target vector. Leaving them where they
> are defeats this, a little.
So the reason you want them all in one file is so that you can make
them all static, and ensure they aren't accessed "on the side". Is
that right? That's a good technical reason for this patch, one which I
didn't think of and you didn't explain. I'm just trying to get you to
share your wisdom with all us other maintainers.
With that explanation presented, I have no objection. Let's make sure
Michael agrees.
> >>linux-inf.c? inf-linux.c is equally (if not more) consistent with the
> >>>new inf-ptrace.c and inf-child.c.
> >
> >
> >inf-* are currently more or less target agnostic; just "unixy".
>
> inf-child, the current root object is very un "unixy".
Hmm, that's because it doesn't do anything. I hadn't looked
since you created the new inf-* files (the confusion with inf*, ugh!).
> > GDB
> >convention says that native support for Linux - that's what this is -
> >belongs in linux-nat.c. If some of it is left in lin-lwp.c for
> >historical reasons, that's a separate issue.
>
> Here we're going to end up with:
>
> inf-i386-linux is-a inf-linux (is-a inf-ptrace?) is-a inf-child
>
> Lets not be shy with the code base. inf-linux.c, containing the
> inf-linux class, is going to be far more consistent in the long term.
> (the only alt I see is a name reversal of linux-inf, child-inf,
> ptrace-inf, ...).
I'm saying that don't see the point of this renaming. Having the
native support for GNU/Linux, whatever it inherits from, continue to
live in linux-nat.c is more natural to me.
> What about I fix up i386 and then come back for the others?
I don't understand what you mean.
--
Daniel Jacobowitz