[RFC] TARGET_OBJECT_WCOOKIE

[RFC] TARGET_OBJECT_WCOOKIE

[Mark Kettenis]

Actually the purpose of this RFC is twofold.

First, I'd like to add a TARGET_OBJECT_WCOOKIE method to support the
StackGhost cookie on OpenBSD/sparc.  This really is something
target-related rather than OS/ABI related.  GDB will have to deal with
StackGhost when running non-OpenBSD binaries on an OpenBSD kernel.
Moreover, older OpenBSD kernels might not have StackGhost.  Anyway,
are there objections to adding something like the attached patch?

The second issue I'd like your opinion on is related to the patch.  I
followed the example set by TARGET_OBJECT_UNWIND_TABLE in having a
macro (NATIVE_XFER_WCOOKIE) to invoke the native-specific function
that fetches the cookie.  This macro would be defined in the nm.h
file, but wasn't it our goal to get rid of the nm.h file sooner rather
than later?  Shouldn't we add another method for these kinds of hooks?
The obvious alternatives are:

a) Use a public function pointer, which is initialized to some
   do-nothing-and-return-minus-one function by default.  This function
   pointer would be overridden by some code in the appropraite *-nat.c
   files.

b) Use a private function pointer, and provide a function to set that
   pointer, along the lines of inftarg_set_find_memory_regions().

Opinions?

Mark


Index: inftarg.c
===================================================================
RCS file: /cvs/src/src/gdb/inftarg.c,v
retrieving revision 1.21
diff -u -p -r1.21 inftarg.c
--- inftarg.c 14 Nov 2003 20:49:23 -0000 1.21
+++ inftarg.c 1 Feb 2004 15:55:47 -0000
@@ -1,7 +1,7 @@
 /* Target-vector operations for controlling Unix child processes, for GDB.
 
    Copyright 1990, 1991, 1992, 1993, 1994, 1995, 1996, 1998, 1999,
-   2000, 2002, 2003 Free Software Foundation, Inc.
+   2000, 2002, 2003, 2004 Free Software Foundation, Inc.
 
    Contributed by Cygnus Support.
 
@@ -577,6 +577,12 @@ child_xfer_partial (struct target_ops *o
 #endif
       return NATIVE_XFER_UNWIND_TABLE (ops, object, annex, readbuf, writebuf,
 				       offset, len);
+
+#ifdef NATIVE_XFER_WCOOKIE
+    case TARGET_OBJECT_WCOOKIE:
+      return NATIVE_XFER_WCOOKIE (ops, object, annex, readbuf, writebuf,
+				  offset, len);
+#endif
 
 #if 0
     case TARGET_OBJECT_AUXV:
Index: target.h
===================================================================
RCS file: /cvs/src/src/gdb/target.h,v
retrieving revision 1.55
diff -u -p -r1.55 target.h
--- target.h 17 Jan 2004 21:56:12 -0000 1.55
+++ target.h 1 Feb 2004 15:55:47 -0000
@@ -226,6 +226,8 @@ enum target_object
   TARGET_OBJECT_MEMORY,
   /* Kernel Unwind Table.  See "ia64-tdep.c".  */
   TARGET_OBJECT_UNWIND_TABLE,
+  /* StackGhost cookie.  See "sparc-tdep.c".  */
+  TARGET_OBJECT_WCOOKIE,
   /* Possible future objects: TARGET_OBJECT_FILE, TARGET_OBJECT_PROC,
      TARGET_OBJECT_AUXV, ...  */
 };

Re: [RFC] TARGET_OBJECT_WCOOKIE

[Daniel Jacobowitz]

On Sun, Feb 01, 2004 at 06:02:17PM +0100, Mark Kettenis wrote:
> Actually the purpose of this RFC is twofold.
> 
> First, I'd like to add a TARGET_OBJECT_WCOOKIE method to support the
> StackGhost cookie on OpenBSD/sparc.  This really is something
> target-related rather than OS/ABI related.  GDB will have to deal with
> StackGhost when running non-OpenBSD binaries on an OpenBSD kernel.
> Moreover, older OpenBSD kernels might not have StackGhost.  Anyway,
> are there objections to adding something like the attached patch?

Not from me.

> The second issue I'd like your opinion on is related to the patch.  I
> followed the example set by TARGET_OBJECT_UNWIND_TABLE in having a
> macro (NATIVE_XFER_WCOOKIE) to invoke the native-specific function
> that fetches the cookie.  This macro would be defined in the nm.h
> file, but wasn't it our goal to get rid of the nm.h file sooner rather
> than later?  Shouldn't we add another method for these kinds of hooks?
> The obvious alternatives are:
> 
> a) Use a public function pointer, which is initialized to some
>    do-nothing-and-return-minus-one function by default.  This function
>    pointer would be overridden by some code in the appropraite *-nat.c
>    files.
> 
> b) Use a private function pointer, and provide a function to set that
>    pointer, along the lines of inftarg_set_find_memory_regions().
> 
> Opinions?

Personally, I think the -nat files should have a chance to edit
child_ops, or provide their own version of child_ops.  This would
eliminate 90% of the gunk in nm* files which is checked in the various
inf* files implementing child_ops.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [RFC] TARGET_OBJECT_WCOOKIE

[Andrew Cagney]

>>The second issue I'd like your opinion on is related to the patch.  I
>> followed the example set by TARGET_OBJECT_UNWIND_TABLE in having a
>> macro (NATIVE_XFER_WCOOKIE) to invoke the native-specific function
>> that fetches the cookie.  This macro would be defined in the nm.h
>> file, but wasn't it our goal to get rid of the nm.h file sooner rather
>> than later?  Shouldn't we add another method for these kinds of hooks?
>> The obvious alternatives are:
>> 
>> a) Use a public function pointer, which is initialized to some
>>    do-nothing-and-return-minus-one function by default.  This function
>>    pointer would be overridden by some code in the appropraite *-nat.c
>>    files.
>> b) Use a private function pointer, and provide a function to set that
>>    pointer, along the lines of inftarg_set_find_memory_regions().
>> Opinions?

It sux less than some of the other existing alternatives - in particular 
the way certain /proc or ptrace specific functions just happen to be 
linked in.  Makes a real mess of the idea of having both /proc and 
ptrace support in a single executable.

> Personally, I think the -nat files should have a chance to edit
> child_ops, or provide their own version of child_ops.  This would
> eliminate 90% of the gunk in nm* files which is checked in the various
> inf* files implementing child_ops.

Have "proc" and "ptrace" export functions for creating fairly generic 
target ops and then have *-nat "inherit" from it (or push on-top of it)?

Andrew

Re: [RFC] TARGET_OBJECT_WCOOKIE

[Daniel Jacobowitz]

On Mon, Feb 02, 2004 at 02:01:48PM -0500, Andrew Cagney wrote:
> 
> >>The second issue I'd like your opinion on is related to the patch.  I
> >>followed the example set by TARGET_OBJECT_UNWIND_TABLE in having a
> >>macro (NATIVE_XFER_WCOOKIE) to invoke the native-specific function
> >>that fetches the cookie.  This macro would be defined in the nm.h
> >>file, but wasn't it our goal to get rid of the nm.h file sooner rather
> >>than later?  Shouldn't we add another method for these kinds of hooks?
> >>The obvious alternatives are:
> >>
> >>a) Use a public function pointer, which is initialized to some
> >>   do-nothing-and-return-minus-one function by default.  This function
> >>   pointer would be overridden by some code in the appropraite *-nat.c
> >>   files.
> >>b) Use a private function pointer, and provide a function to set that
> >>   pointer, along the lines of inftarg_set_find_memory_regions().
> >>Opinions?
> 
> It sux less than some of the other existing alternatives - in particular 
> the way certain /proc or ptrace specific functions just happen to be 
> linked in.  Makes a real mess of the idea of having both /proc and 
> ptrace support in a single executable.
> 
> >Personally, I think the -nat files should have a chance to edit
> >child_ops, or provide their own version of child_ops.  This would
> >eliminate 90% of the gunk in nm* files which is checked in the various
> >inf* files implementing child_ops.
> 
> Have "proc" and "ptrace" export functions for creating fairly generic 
> target ops and then have *-nat "inherit" from it (or push on-top of it)?

Yeah, something like that.

At the very least, we could reduce the existing mess of macros to one. 
After child_ops is initialized, call a native macro which can override
elements of it.

Then, later on, we can remove explicit references to child_ops (they're
scattered all over GDB last time I checked) and make the native targets
fill in their own ops.

Sound good?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer