x86-64-tdep.h cleanup

x86-64-tdep.h cleanup

[Michal Ludvig]

[-- Attachment #1: Type: text/plain, Size: 3238 bytes --]

As it was recommended by lots of people here I moved <sys/reg.h> along 
with regmap from x86-64-tdep.h to x86-64-linux-nat.c.
Also to let x86-64-tdep.h contain only #defines, I moved declarations of 
x86_64_linux_frame_saved_pc and x86_64_linux_saved_pc_after_call to 
x86-64-tdep.c. Are these changes OK to commit?

Michal Ludvig

Index: ChangeLog
from Michal Ludvig  <mludvig@suse.cz>

* x86-64-tdep.h (sys/reg.h, x86_64_regmap): Moved to x86-64-linux-nat.c
(x86_64_linux_frame_saved_pc,
x86_64_linux_saved_pc_after_call): Moved to x86-64-tdep.c
* x86-64-linux-nat.c (sys/reg.h, x86_64_regmap): Moved here
from x86-64-tdep.h
* x86-64-tdep.c (x86_64_linux_frame_saved_pc,
x86_64_linux_saved_pc_after_call): Moved here from x86-64-tdep.h

Index: x86-64-tdep.h
===================================================================
RCS file: /cvs/src/src/gdb/x86-64-tdep.h,v
retrieving revision 1.1
diff -c -3 -p -r1.1 x86-64-tdep.h
*** x86-64-tdep.h	2001/09/21 12:19:15	1.1
--- x86-64-tdep.h	2002/03/05 15:03:37
***************
*** 24,49 ****
   #define X86_64_TDEP_H

   #include "i386-tdep.h"
- #include <sys/reg.h>
- /* Mapping between the general-purpose registers in `struct user'
-    format and GDB's register array layout.  */
-
- static int x86_64_regmap[] = {
-   RAX, RDX, RCX, RBX,
-   RSI, RDI, RBP, RSP,
-   R8, R9, R10, R11,
-   R12, R13, R14, R15,
-   RIP, EFLAGS
- };
-
   /* Number of all registers */
   #define X86_64_NUM_REGS (51)

   /* Number of general registers.  */
   #define X86_64_NUM_GREGS (18)
-
- gdbarch_frame_saved_pc_ftype x86_64_linux_frame_saved_pc;
- gdbarch_saved_pc_after_call_ftype x86_64_linux_saved_pc_after_call;

   #endif
--- 24,34 ----
Index: x86-64-linux-nat.c
===================================================================
RCS file: /cvs/src/src/gdb/x86-64-linux-nat.c,v
retrieving revision 1.5
diff -c -3 -p -r1.5 x86-64-linux-nat.c
*** x86-64-linux-nat.c	2002/02/24 22:14:33	1.5
--- x86-64-linux-nat.c	2002/03/05 15:03:37
***************
*** 33,39 ****
--- 33,51 ----
   #include <sys/debugreg.h>
#include <sys/syscall.h>
#include <sys/procfs.h>
+ #include <sys/reg.h>
+ /* Mapping between the general-purpose registers in `struct user'
+    format and GDB's register array layout.  */
+
+ static int x86_64_regmap[] = {
+   RAX, RDX, RCX, RBX,
+   RSI, RDI, RBP, RSP,
+   R8, R9, R10, R11,
+   R12, R13, R14, R15,
+   RIP, EFLAGS
+ };
+ 	
   static unsigned long
   x86_64_linux_dr_get (int regnum)
   {
Index: x86-64-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/x86-64-tdep.c,v
retrieving revision 1.10
diff -c -3 -p -r1.10 x86-64-tdep.c
*** x86-64-tdep.c	2002/03/04 11:08:28	1.10
--- x86-64-tdep.c	2002/03/05 15:03:37
*************** int x86_64_register_raw_size_table[X86_6
*** 59,64 ****
--- 59,69 ----
     4
   };

+ /* Prototypes of some functions from x86-64-linux-tdep.c  */
+
+ gdbarch_frame_saved_pc_ftype x86_64_linux_frame_saved_pc;
+ gdbarch_saved_pc_after_call_ftype x86_64_linux_saved_pc_after_call;
+
   /* Number of bytes of storage in the actual machine representation for
      register REGNO.  */
   int



Michal Ludvig
-- 
* SuSE CR, s.r.o     * mludvig@suse.cz
* +420 2 9654 5373   * http://www.suse.cz

[-- Attachment #2: x8664-01.diff --]
[-- Type: text/plain, Size: 2405 bytes --]

Index: x86-64-tdep.h
===================================================================
RCS file: /cvs/src/src/gdb/x86-64-tdep.h,v
retrieving revision 1.1
diff -c -3 -p -r1.1 x86-64-tdep.h
*** x86-64-tdep.h	2001/09/21 12:19:15	1.1
--- x86-64-tdep.h	2002/03/05 15:03:37
***************
*** 24,49 ****
  #define X86_64_TDEP_H
  
  #include "i386-tdep.h"
- #include <sys/reg.h>
  
- /* Mapping between the general-purpose registers in `struct user'
-    format and GDB's register array layout.  */
- 
- static int x86_64_regmap[] = {
-   RAX, RDX, RCX, RBX,
-   RSI, RDI, RBP, RSP,
-   R8, R9, R10, R11,
-   R12, R13, R14, R15,
-   RIP, EFLAGS
- };
- 
  /* Number of all registers */
  #define X86_64_NUM_REGS (51)
  
  /* Number of general registers.  */
  #define X86_64_NUM_GREGS (18)
- 
- gdbarch_frame_saved_pc_ftype x86_64_linux_frame_saved_pc;
- gdbarch_saved_pc_after_call_ftype x86_64_linux_saved_pc_after_call;
  
  #endif
--- 24,34 ----
Index: x86-64-linux-nat.c
===================================================================
RCS file: /cvs/src/src/gdb/x86-64-linux-nat.c,v
retrieving revision 1.5
diff -c -3 -p -r1.5 x86-64-linux-nat.c
*** x86-64-linux-nat.c	2002/02/24 22:14:33	1.5
--- x86-64-linux-nat.c	2002/03/05 15:03:37
***************
*** 33,39 ****
--- 33,51 ----
  #include <sys/debugreg.h>
  #include <sys/syscall.h>
  #include <sys/procfs.h>
+ #include <sys/reg.h>
  
+ /* Mapping between the general-purpose registers in `struct user'
+    format and GDB's register array layout.  */
+ 
+ static int x86_64_regmap[] = {
+   RAX, RDX, RCX, RBX,
+   RSI, RDI, RBP, RSP,
+   R8, R9, R10, R11,
+   R12, R13, R14, R15,
+   RIP, EFLAGS
+ };
+ 	
  static unsigned long
  x86_64_linux_dr_get (int regnum)
  {
Index: x86-64-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/x86-64-tdep.c,v
retrieving revision 1.10
diff -c -3 -p -r1.10 x86-64-tdep.c
*** x86-64-tdep.c	2002/03/04 11:08:28	1.10
--- x86-64-tdep.c	2002/03/05 15:03:37
*************** int x86_64_register_raw_size_table[X86_6
*** 59,64 ****
--- 59,69 ----
    4
  };
  
+ /* Prototypes of some functions from x86-64-linux-tdep.c  */
+ 
+ gdbarch_frame_saved_pc_ftype x86_64_linux_frame_saved_pc;
+ gdbarch_saved_pc_after_call_ftype x86_64_linux_saved_pc_after_call;
+ 
  /* Number of bytes of storage in the actual machine representation for
     register REGNO.  */
  int

Re: x86-64-tdep.h cleanup

[Kevin Buettner]

On Mar 5,  4:56pm, Michal Ludvig wrote:

> As it was recommended by lots of people here I moved <sys/reg.h> along 
> with regmap from x86-64-tdep.h to x86-64-linux-nat.c.
> Also to let x86-64-tdep.h contain only #defines, I moved declarations of 
> x86_64_linux_frame_saved_pc and x86_64_linux_saved_pc_after_call to 
> x86-64-tdep.c. Are these changes OK to commit?
> 
> Michal Ludvig
> 
> Index: ChangeLog
> from Michal Ludvig  <mludvig@suse.cz>
> 
> * x86-64-tdep.h (sys/reg.h, x86_64_regmap): Moved to x86-64-linux-nat.c
> (x86_64_linux_frame_saved_pc,
> x86_64_linux_saved_pc_after_call): Moved to x86-64-tdep.c
> * x86-64-linux-nat.c (sys/reg.h, x86_64_regmap): Moved here
> from x86-64-tdep.h
> * x86-64-tdep.c (x86_64_linux_frame_saved_pc,
> x86_64_linux_saved_pc_after_call): Moved here from x86-64-tdep.h


Michael,

I'm not the maintainer of the files in questions, but your changes
look okay to me.

Make sure your ChangeLog entries are indented by a tab and make sure
that you end your remarks with a period.  Also, it's been pointed out
to me in the past that an entry like this:

	* x86-64-tdep.c (x86_64_linux_frame_saved_pc,
	x86_64_linux_saved_pc_after_call): Moved here from x86-64-tdep.h.

should be written like this instead:

	* x86-64-tdep.c (x86_64_linux_frame_saved_pc)
	(x86_64_linux_saved_pc_after_call): Moved here from x86-64-tdep.h.

(I've been told that emacs is happier if ChangeLog entries are
formatted this way.)

Kevin

Re: x86-64-tdep.h cleanup

[Andreas Jaeger]

Kevin Buettner <kevinb@redhat.com> writes:

> On Mar 5,  4:56pm, Michal Ludvig wrote:
>
>> As it was recommended by lots of people here I moved <sys/reg.h> along 
>> with regmap from x86-64-tdep.h to x86-64-linux-nat.c.
>> Also to let x86-64-tdep.h contain only #defines, I moved declarations of 
>> x86_64_linux_frame_saved_pc and x86_64_linux_saved_pc_after_call to 
>> x86-64-tdep.c. Are these changes OK to commit?
>> 
>> Michal Ludvig
>> 
>> Index: ChangeLog
>> from Michal Ludvig  <mludvig@suse.cz>
>> 
>> * x86-64-tdep.h (sys/reg.h, x86_64_regmap): Moved to x86-64-linux-nat.c
>> (x86_64_linux_frame_saved_pc,
>> x86_64_linux_saved_pc_after_call): Moved to x86-64-tdep.c
>> * x86-64-linux-nat.c (sys/reg.h, x86_64_regmap): Moved here
>> from x86-64-tdep.h
>> * x86-64-tdep.c (x86_64_linux_frame_saved_pc,
>> x86_64_linux_saved_pc_after_call): Moved here from x86-64-tdep.h
>
>
> Michael,
>
> I'm not the maintainer of the files in questions, but your changes
> look okay to me.

Since x86-64 is currently not officially (according to GDB
maintainership rules) by anybody, you have the right to ok this
change.  Is this an approval?

Thanks,
Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj

Re: x86-64-tdep.h cleanup

[Michal Ludvig]

Kevin Buettner wrote:
> On Mar 5,  4:56pm, Michal Ludvig wrote:
>>* x86-64-tdep.h (sys/reg.h, x86_64_regmap): Moved to x86-64-linux-nat.c
>>(x86_64_linux_frame_saved_pc,
>>x86_64_linux_saved_pc_after_call): Moved to x86-64-tdep.c
>>* x86-64-linux-nat.c (sys/reg.h, x86_64_regmap): Moved here
>>from x86-64-tdep.h
>>* x86-64-tdep.c (x86_64_linux_frame_saved_pc,
>>x86_64_linux_saved_pc_after_call): Moved here from x86-64-tdep.h


> I'm not the maintainer of the files in questions, but your changes
> look okay to me.

There is no maintainer of this port right now. Can I understand your 
message as an approval?

> should be written like this instead:
> 
> 	* x86-64-tdep.c (x86_64_linux_frame_saved_pc)
> 	(x86_64_linux_saved_pc_after_call): Moved here from x86-64-tdep.h.
> 
> (I've been told that emacs is happier if ChangeLog entries are
> formatted this way.)

Thanks for notice, I reformatted them.
Michal Ludvig
-- 
* SuSE CR, s.r.o     * mludvig@suse.cz
* +420 2 9654 5373   * http://www.suse.cz

Re: x86-64-tdep.h cleanup

[Kevin Buettner]

On Mar 6, 11:00am, Michal Ludvig wrote:

> Kevin Buettner wrote:
> 
> > I'm not the maintainer of the files in questions, but your changes
> > look okay to me.
> 
> There is no maintainer of this port right now. Can I understand your 
> message as an approval?

Ah.  I didn't want to step on anyone's toes...

...but, since there's no maintainer, and since there haven't been any
objections to your patch, go ahead and check it in.

(Yes, approved.)

Kevin

[patch] Re: x86-64-tdep.h cleanup

[Michal Ludvig]

Kevin Buettner wrote:
> (Yes, approved.)

Thanks, for now I commited this change since noone voted against it. I 
will try to solve the other cleanup later.
Index: x86-64-tdep.h
===================================================================
RCS file: /cvs/src/src/gdb/x86-64-tdep.h,v
retrieving revision 1.1
diff -c -3 -p -r1.1 x86-64-tdep.h
*** x86-64-tdep.h       2001/09/21 12:19:15     1.1
--- x86-64-tdep.h       2002/03/07 13:26:10
***************
*** 24,41 ****
   #define X86_64_TDEP_H

   #include "i386-tdep.h"
- #include <sys/reg.h>
-
- /* Mapping between the general-purpose registers in `struct user'
-    format and GDB's register array layout.  */
-
- static int x86_64_regmap[] = {
-   RAX, RDX, RCX, RBX,
-   RSI, RDI, RBP, RSP,
-   R8, R9, R10, R11,
-   R12, R13, R14, R15,
-   RIP, EFLAGS
- };

   /* Number of all registers */
   #define X86_64_NUM_REGS (51)
--- 24,29 ----
Index: x86-64-linux-nat.c
===================================================================
RCS file: /cvs/src/src/gdb/x86-64-linux-nat.c,v
retrieving revision 1.5
diff -c -3 -p -r1.5 x86-64-linux-nat.c
*** x86-64-linux-nat.c  2002/02/24 22:14:33     1.5
--- x86-64-linux-nat.c  2002/03/07 13:26:10
***************
*** 33,39 ****
--- 33,51 ----
   #include <sys/debugreg.h>
   #include <sys/syscall.h>
   #include <sys/procfs.h>
+ #include <sys/reg.h>

+ /* Mapping between the general-purpose registers in `struct user'
+    format and GDB's register array layout.  */
+
+ static int x86_64_regmap[] = {
+   RAX, RDX, RCX, RBX,
+   RSI, RDI, RBP, RSP,
+   R8, R9, R10, R11,
+   R12, R13, R14, R15,
+   RIP, EFLAGS
+ };
+
   static unsigned long
   x86_64_linux_dr_get (int regnum)
   {



Michal Ludvig
-- 
* SuSE CR, s.r.o     * mludvig@suse.cz
* +420 2 9654 5373   * http://www.suse.cz

Re: x86-64-tdep.h cleanup

[Andreas Schwab]

Michal Ludvig <mludvig@suse.cz> writes:

|> Index: x86-64-tdep.c
|> ===================================================================
|> RCS file: /cvs/src/src/gdb/x86-64-tdep.c,v
|> retrieving revision 1.10
|> diff -c -3 -p -r1.10 x86-64-tdep.c
|> *** x86-64-tdep.c	2002/03/04 11:08:28	1.10
|> --- x86-64-tdep.c	2002/03/05 15:03:37
|> *************** int x86_64_register_raw_size_table[X86_6
|> *** 59,64 ****
|> --- 59,69 ----
|>      4
|>    };
|> 
|> + /* Prototypes of some functions from x86-64-linux-tdep.c  */
|> +
|> + gdbarch_frame_saved_pc_ftype x86_64_linux_frame_saved_pc;
|> + gdbarch_saved_pc_after_call_ftype x86_64_linux_saved_pc_after_call;
|> +
|>    /* Number of bytes of storage in the actual machine representation for
|>       register REGNO.  */
|>    int

I think the registration of the Linux specific gdbarch functions should be
moved to x86-64-linux-tdep.c.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE GmbH, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

[RFA] Re: x86-64-tdep.h cleanup

[Michal Ludvig]

[-- Attachment #1: Type: text/plain, Size: 296 bytes --]

Andreas Schwab wrote:
> I think the registration of the Linux specific gdbarch functions should be
> moved to x86-64-linux-tdep.c.

It seems reasonable. Perhaps I can do it like in the attachment?
Michal Ludvig
-- 
* SuSE CR, s.r.o     * mludvig@suse.cz
* +420 2 9654 5373   * http://www.suse.cz

[-- Attachment #2: x8664-02.diff --]
[-- Type: text/plain, Size: 2461 bytes --]

Index: x86-64-linux-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/x86-64-linux-tdep.c,v
retrieving revision 1.4
diff -c -3 -p -r1.4 x86-64-linux-tdep.c
*** x86-64-linux-tdep.c	2002/02/24 22:14:33	1.4
--- x86-64-linux-tdep.c	2002/03/06 16:34:55
*************** x86_64_linux_frame_saved_pc (struct fram
*** 134,136 ****
--- 134,144 ----
      return x86_64_linux_sigtramp_saved_pc (frame);
    return cfi_get_ra (frame);
  }
+ 
+ /* Set Linux specific functions into gdbarch vector.  */
+ void
+ linux_gdbarch_init (struct gdbarch *gdbarch)
+ {
+   set_gdbarch_saved_pc_after_call (gdbarch, x86_64_linux_saved_pc_after_call);
+   set_gdbarch_frame_saved_pc (gdbarch, x86_64_linux_frame_saved_pc);
+ }
Index: x86-64-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/x86-64-tdep.c,v
retrieving revision 1.10
diff -c -3 -p -r1.10 x86-64-tdep.c
*** x86-64-tdep.c	2002/03/04 11:08:28	1.10
--- x86-64-tdep.c	2002/03/06 16:34:55
*************** int x86_64_register_raw_size_table[X86_6
*** 59,64 ****
--- 59,67 ----
    4
  };
  
+ /* Prototype of function from x86-64-linux-tdep.c.  */
+ void linux_gdbarch_init (struct gdbarch *gdbarch);
+ 
  /* Number of bytes of storage in the actual machine representation for
     register REGNO.  */
  int
*************** i386_gdbarch_init (struct gdbarch_info i
*** 892,898 ****
  
    set_gdbarch_frameless_function_invocation (gdbarch,
  					     x86_64_frameless_function_invocation);
-   set_gdbarch_frame_saved_pc (gdbarch, x86_64_linux_frame_saved_pc);
  
    set_gdbarch_frame_args_address (gdbarch, default_frame_address);
    set_gdbarch_frame_locals_address (gdbarch, default_frame_address);
--- 895,900 ----
*************** i386_gdbarch_init (struct gdbarch_info i
*** 966,973 ****
  
    set_gdbarch_skip_prologue (gdbarch, x86_64_skip_prologue);
  
-   set_gdbarch_saved_pc_after_call (gdbarch, x86_64_linux_saved_pc_after_call);
- 
    set_gdbarch_inner_than (gdbarch, core_addr_lessthan);
  
    set_gdbarch_breakpoint_from_pc (gdbarch, x86_64_breakpoint_from_pc);
--- 968,973 ----
*************** i386_gdbarch_init (struct gdbarch_info i
*** 979,984 ****
--- 979,988 ----
  
  /* Use dwarf2 debug frame informations.  */
    set_gdbarch_dwarf2_build_frame_info (gdbarch, dwarf2_build_frame_info);
+ 
+ /* Set Linux specific functions.  */
+   linux_gdbarch_init (gdbarch);
+ 
    return gdbarch;
  }
  

Re: [RFA] Re: x86-64-tdep.h cleanup

[Andreas Schwab]

Michal Ludvig <mludvig@suse.cz> writes:

|> Andreas Schwab wrote:
|> > I think the registration of the Linux specific gdbarch functions should be
|> > moved to x86-64-linux-tdep.c.
|> 
|> It seems reasonable. Perhaps I can do it like in the attachment?

No, x86-64-tdep.c should not have _any_ reference to
x86-64-linux-tdep.c.  The former must be usable without the latter.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE GmbH, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: [RFA] Re: x86-64-tdep.h cleanup

[Kevin Buettner]

On Mar 6,  6:24pm, Andreas Schwab wrote:

> Michal Ludvig <mludvig@suse.cz> writes:
> 
> |> Andreas Schwab wrote:
> |> > I think the registration of the Linux specific gdbarch functions should be
> |> > moved to x86-64-linux-tdep.c.
> |> 
> |> It seems reasonable. Perhaps I can do it like in the attachment?
> 
> No, x86-64-tdep.c should not have _any_ reference to
> x86-64-linux-tdep.c.  The former must be usable without the latter.

How is that possible though?  I've studied this problem for other
targets and have (up to now, anyway) concluded that the main tdep.c
file is going to need to know about the (OS or ABI) variants in some
fashion.

Kevin

Re: [RFA] Re: x86-64-tdep.h cleanup

[Andrew Cagney]

> On Mar 6,  6:24pm, Andreas Schwab wrote:
> 
> 
>> Michal Ludvig <mludvig@suse.cz> writes:
>> 
>> |> Andreas Schwab wrote:
>> |> > I think the registration of the Linux specific gdbarch functions should be
>> |> > moved to x86-64-linux-tdep.c.
>> |> > |> It seems reasonable. Perhaps I can do it like in the attachment?
>> 
>> No, x86-64-tdep.c should not have _any_ reference to
>> x86-64-linux-tdep.c.  The former must be usable without the latter.
> 
> 
> How is that possible though?  I've studied this problem for other
> targets and have (up to now, anyway) concluded that the main tdep.c
> file is going to need to know about the (OS or ABI) variants in some
> fashion.

I think AndreasS is correct.  x86-64-tdep.c only contains ISA and ABI 
stuff while x86-64-linux.c contains GNU/Linux specific OS functions.

Two problems are tripping up the theory.  First is that gdbarch doesn't 
currently groak this arangement - x86-64-linux-tdep is derived (correct 
O-O word?) from x86-64-tdep.  The second problem is that gdbarch doesn't 
handle the concept of OS variants within an ISA/ABI.

Up until now people have side stepped the issue by retaining macro 
definitions in config/*/tm-linux.h.  I'm personally ok with this - it 
retains the status quo and at least manages to retain the separation.

enjoy,
Andrew

Re: [RFA] Re: x86-64-tdep.h cleanup

[Kevin Buettner]

On Mar 6,  1:26pm, Andrew Cagney wrote:

> >> Michal Ludvig <mludvig@suse.cz> writes:
> >> 
> >> |> Andreas Schwab wrote:
> >> |> > I think the registration of the Linux specific gdbarch functions should be
> >> |> > moved to x86-64-linux-tdep.c.
> >> |> > |> It seems reasonable. Perhaps I can do it like in the attachment?
> >> 
> >> No, x86-64-tdep.c should not have _any_ reference to
> >> x86-64-linux-tdep.c.  The former must be usable without the latter.
> > 
> > 
> > How is that possible though?  I've studied this problem for other
> > targets and have (up to now, anyway) concluded that the main tdep.c
> > file is going to need to know about the (OS or ABI) variants in some
> > fashion.
> 
> I think AndreasS is correct.  x86-64-tdep.c only contains ISA and ABI 
> stuff while x86-64-linux.c contains GNU/Linux specific OS functions.
> 
> Two problems are tripping up the theory.  First is that gdbarch doesn't 
> currently groak this arangement - x86-64-linux-tdep is derived (correct 
> O-O word?) from x86-64-tdep.

I'm not sure I agree with this characterization.  As I see it, the
x86-64-linux-tdep.c functions could just as easily have gone in the
main tdep.c file, but it is/was cleaner to put them in their own file.

> The second problem is that gdbarch doesn't 
> handle the concept of OS variants within an ISA/ABI.

Well, maybe not directly, but it is certainly possible use a
gdbarch_tdep struct to describe certain features of the OS in
question.  I use this sort of mechanism on IA-64 to distinguish
between AIX and Linux.  The OS-specific IA-64 tdep files deal with the
same kinds of issues that x86-64-linux-tdep.c is meant to handle.

(See the first sixty lines or so of ia64_gdbarch_init().)

> Up until now people have side stepped the issue by retaining macro 
> definitions in config/*/tm-linux.h.  I'm personally ok with this - it 
> retains the status quo and at least manages to retain the separation.

Yuck.  I don't mind the status quo for targets that haven't completely
converted over to being multiarched yet.  I don't think that we should
encourage a new target to do this though.

Kevin