Hi,

This is another cleanup/commonalization patch that serves as a base for 
the future remote fork/exec support.

Both GDB and gdbserver check for ptrace options in similar ways, but 
each code does its own thing.

The patch moves the ptrace option checks from 
linux-nat.*/gdbserver/linux-low.c to common/linux-ptrace.c. The code is 
a little entangled with the native linux stuff too, so some code gets 
moved to common/linux-nat-common.* instead.

The variable that stores all the supported ptrace options is kept in 
common/linux-ptrace.c now, and GDB/gdbserver can query features 
(tracesysgood, tracevfork etc) via helper functions. It seems a bit 
cleaner this way.

With this change GDB and gdbserver share almost the same code for those 
checks, leading to less duplication.

Up for discussion are a few things though:

1 - There is a bit of gdbserver-specific code that disallows 
PTRACE_O_TRACEFORK and friends so gdbserver keeps the same behavior even 
though those options are available for Linux. This is temporary so we 
don't break gdbserver while remote fork is being developed. You can see 
this block in linux_enable_event_reporting.

There is also a gdbserver-specific block for gdbserver debugging 
messages. Maybe we can get rid of those and come up with something 
common between GDB and gdbserver as well.

2 - I had to come up with a little bit of magic to merge the 
gdbserver-specific code to fork childs and grandchilds 
(fork/clone-handling) with GDB's. gdbserver supports MMU-less targets 
and we have a few defines there to either use fork or clone based on 
that condition. ia64 also has its own little thing going on, so that is 
honored as well for both GDB and gdbserver. This can be seen in 
linux_fork_to_function.

3 - gdbserver explicitly casts the arguments for a ptrace call to cope 
with odd architectures that require such a cast to be able to pass 
parameters correctly. I'm not too sure what to do about this one. We can 
either have more #ifdef blocks (in a way, defeating the purpose of 
having common code) or just unconditionally use a #define for a cast and 
create such a #define at build-time (either GDB or gdbserver) with the 
correct casting type or no casting at all.

4 - Is linux-nat-common.* an acceptable naming pattern? It seems to me 
that in the future we will eventually have lots of these, one for each 
architecture as we share more and more backend code.

Testing-wise, everything is still the same for x86-84, no regressions 
found for both GDB and gdbserver.

Thoughts?