Re: Moving Linux-specific stuff out of i386-tdep.c

[Stan Shebs <shebs at apple dot com>]

Mark Kettenis wrote:
> 
> Hi,
> 
> Over time quite a lot of Linux-dependent stuff has been added to
> i386-tdep.c, and I think it's time to move that into its own file.

Bear in mind that it should be possible to build a foo-x-linux
cross debugger, if for no other reason than to bootstrap new
systems.  *-nat.c files are by definition native-only, and won't
get linked into a cross debugger.

I generally like to look at foo-tdep.c as a quasi-library of
knowledge about foo.  It makes it easier to share code that
is the same or nearly the same for different OSes running on
the architecture.

> But before I do that I'd like to get some clarification on some
> issue's.
> 
> 1. Do we still care about the filename limits of older System V
>    systems?  i386-linux-nat.c is longer than 14 characters which is a
>    no-no according to the GNU conding standards.

Well, the systems in question are quite old, we've had long filenames
in GDB sources for quite a while, and only the DJGPP folks have
whined about it. :-)  Personally, I think we should try to stay
within the 14-char limit, because a) everything gets unwieldy when
people start trying to put the documentation into the filenames
like i386-linux-nat-for-red-hat-6.1-beta2-except-in-nepal.c
and b) because doschk is a handy way to check on all the filename
issues at once.

If somebody has an actual System V machine that chokes when
handed a tar file with long filenames, now would be a good time
to speak up...

> 2. Should I postpone creating the new -tdep.c file until after the
>    release or not.  Andrew has been telling us to avoid gratuitous
>    changes to make it easier to apply outstanding patches.  But on the
>    other hand, after 5.0 is released, I hope to see a lot new patches
>    generated against 5.0.  So creating the new file before 5.0 would
>    make applying those new patches a lot easier.

If the Linux patch backlog were to be emptied out, you wouldn't have
this problem. :-)  But seriously, if you change it now, before all
submitted patches have been dealt with, then it would only be fair
for you to adapt those patches yourself.  So it seems more like a
question of whether you want to do more work now vs later.

Stan