Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Mark Kettenis <kettenis@wins.uva.nl>
To: hjl@lucon.org
Cc: kingdon@redhat.com, gdb-patches@sourceware.cygnus.com
Subject: Re: Make threads architecture-independent on Linux
Date: Wed, 10 Nov 1999 13:38:00 -0000	[thread overview]
Message-ID: <199911102138.WAA00378@delius.kettenis.local> (raw)
In-Reply-To: <19991108233623.805581B493@ocean.lucon.org>

   Date: Mon, 8 Nov 1999 15:36:23 -0800 (PST)
   From: hjl@lucon.org (H.J. Lu)

   > 
   > Following up on last week's discussion (that is,
   > http://sourceware.cygnus.com/ml/gdb-patches/1999-q4/msg00123.html and
   > related email), here is a patch to enable linux threads in general
   > rather than just on x86.  I've tested it on x86 but it should work on
   > all of them (famous last words :-)).
   > 
   > 1999-11-08  Jim Kingdon  < http://developer.redhat.com/ >
   > 
   > 	Enable threads for all linux architectures:
   > 	* config/nm-linux.h: New file.
   > 	* config/{alpha,i386,m68k,sparc}/nm-linux.h: Use it.
   > 

   I will advise against it. You can take a look at gdb 4.17.0.14 to
   see how it is handled there. I will make a patch for gdb 4.18
   when the backlog improves.

What exactly is withholding you from submitting small patches to bits
unrelated to the FPU support?  And even then, the only piece missing
for proper Linux FPU support is the "info float" command which is not
essential and will be present real soon now.  There are also some
remaining issues with long double support that have to be resolved and
the idea is to get rid if the ad-hoc implementation that the Linux
port uses now.  I would advise strongly against touching the long
double support since almost anything you'll do will most likely be
changed anyway.  But I cannot see why this small "backlog" is keeping
you from submitting patches.

Somehow I'm suspecting that you want to submit a huge patch that
touches several unrelated issues without a lot of explanation why
those changes are necessary.  I think that that would be a terribly
bad thing to do, and I would strngly advise the GDB maintainers not to
accept such a large patch.

If JK's patch really isn't the right way to add thread-support for
all Linux architectures, please tell us why!  Otherwise I think the
patch should be applied.

Mark
From shebs@cygnus.com Wed Nov 10 13:41:00 1999
From: Stan Shebs <shebs@cygnus.com>
To: guo@cup.hp.com
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: (patch) hpjyg02: fix gdb.base/commands.exp
Date: Wed, 10 Nov 1999 13:41:00 -0000
Message-id: <199911102141.NAA28196@andros.cygnus.com>
References: <Pine.LNX.4.10.9910281741360.28476-100000@hpcll168.cup.hp.com>
X-SW-Source: 1999-q4/msg00221.html
Content-length: 310

   Date: Thu, 28 Oct 1999 17:44:32 -0700 (PDT)
   From: Jimmy Guo <guo@cup.hp.com>

   We need a $gdb_prompt $ anchor for 'continue with watch' test in
   gdb.base/commands.exp, or the anchor could be picked up by the next
   expect ...

Thanks, I've just installed this patch in the repository.

								Stan
From eliz@gnu.org Wed Nov 10 14:37:00 1999
From: Eli Zaretskii <eliz@gnu.org>
To: jimb@cygnus.com, dj@delorie.com
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: i386: Are we settled?
Date: Wed, 10 Nov 1999 14:37:00 -0000
Message-id: <199911102234.RAA01359@mescaline.gnu.org>
References: <199911090018.TAA12933@zwingli.cygnus.com>
X-SW-Source: 1999-q4/msg00222.html
Content-length: 10052

These are the patches for go32-specific config files following the new
tm-i386.h.

--- gdb/config/i386/tm-go32.h~1	Wed Jul  7 20:13:00 1999
+++ gdb/config/i386/tm-go32.h	Wed Nov 10 18:08:46 1999
@@ -18,108 +18,10 @@
    Foundation, Inc., 59 Temple Place - Suite 330,
    Boston, MA 02111-1307, USA.  */
 
-#include "i386/tm-i386v.h"
+#undef HAVE_SSE_REGS	/* FIXME! go32-nat.c needs to support XMMi registers */
+#define HAVE_I387_REGS
 
-/* Number of machine registers. */
-
-#undef NUM_FREGS
-#define NUM_FREGS 15
-#undef NUM_REGS
-#define NUM_REGS (16+NUM_FREGS)
-
-/* Initializer for an array of names of registers.  There should be
-   NUM_REGS strings in this initializer.  */
-
-/* The order of the first 8 registers must match the compiler's
-   numbering scheme (which is the same as the 386 scheme).  */
-
-#undef REGISTER_NAMES
-#define REGISTER_NAMES { "eax",  "ecx",   "edx",  "ebx",  \
-			 "esp",  "ebp",   "esi",  "edi",  \
-			 "eip",  "eflags","cs",   "ss",   \
-			 "ds",   "es",    "fs",   "gs",   \
-			 "st0",  "st1",   "st2",  "st3",  \
-                         "st4",  "st5",   "st6",  "st7",  \
-			 "fctrl","fstat", "ftag", "fcs",  \
-			 "fopsel","fip",  "fopoff" }
-
-#undef FP_REGNUM
-#define FP_REGNUM  5		/* (ebp) Contains addr of stack frame */
-#undef  SP_REGNUM
-#define SP_REGNUM  4		/* (usp) Contains address of top of stack */
-#undef  PS_REGNUM
-#define PS_REGNUM  9		/* (ps)  Contains processor status */
-#undef  PC_REGNUM
-#define PC_REGNUM  8		/* (eip) Contains program counter */
-#undef  FP0_REGNUM
-#define FP0_REGNUM 16		/* Floating point register 0 */
-#undef  FPC_REGNUM
-#define FPC_REGNUM 24		/* 80387 control register */
-#undef  FPCWD_REGNUM
-#define FPCWD_REGNUM FPC_REGNUM
-#undef  FPSWD_REGNUM
-#define FPSWD_REGNUM 25		/* 80387 status register */
-#undef  FPTWD_REGNUM
-#define FPTWD_REGNUM 26		/* 80387 tag register */
-#undef  FPIPO_REGNUM
-#define FPIPO_REGNUM 29		/* 80387 instruction pointer offset reg */
-#undef  FPIPS_REGNUM
-#define FPIPS_REGNUM 27		/* 80387 instruction pointer selector reg */
-#undef  FPOOS_REGNUM
-#define FPOOS_REGNUM 30		/* 80387 operand pointer offset reg */
-#undef  FPOPS_REGNUM
-#define FPOPS_REGNUM 28		/* 80387 operand pointer selector reg */
-
-/* Total amount of space needed to store our copies of the machine's
-   register state, the array `registers'.  */
-
-#undef REGISTER_BYTES
-#define REGISTER_BYTES (10*4 + 6*2 + 8*10 + 5*2 + 2*4)
-
-/* Index within `registers' of the first byte of the space for
-   register N.  */
-
-#undef REGISTER_BYTE
-#define REGBYTE_0  0
-#define REGBYTE_10 (REGBYTE_0+10*4)
-#define REGBYTE_16 (REGBYTE_10+6*2)
-#define REGBYTE_24 (REGBYTE_16+8*10)
-#define REGBYTE_29 (REGBYTE_24+5*2)
-#define REGISTER_BYTE(N) (((N) < 10) ? (N) * 4 : \
-                          (N) < 16 ? REGBYTE_10 +((N) - 10) * 2 : \
-                          (N) < 24 ? REGBYTE_16 +((N) - 16) * 10 : \
-                          (N) < 29 ? REGBYTE_24 +((N) - 24) * 2 : \
-                          REGBYTE_29 + ((N) - 29) * 4)
-
-/* Number of bytes of storage in the actual machine representation
-   for register N.  */
-
-#undef REGISTER_RAW_SIZE
-#define REGISTER_RAW_SIZE(N) ((N) < 10 ? 4 : (N) < 16 ? 2 : (N) < 24 ? 10 : \
-                              (N) < 29 ? 2 : 4)
-
-/* Number of bytes of storage in the program's representation
-   for register N. */
-
-#undef REGISTER_VIRTUAL_SIZE
-#define REGISTER_VIRTUAL_SIZE(N) REGISTER_RAW_SIZE(N)
-
-/* Largest value REGISTER_RAW_SIZE can have.  */
-
-#undef MAX_REGISTER_RAW_SIZE
-#define MAX_REGISTER_RAW_SIZE 10
-
-/* Largest value REGISTER_VIRTUAL_SIZE can have.  */
-
-#undef MAX_REGISTER_VIRTUAL_SIZE
-#define MAX_REGISTER_VIRTUAL_SIZE 10
-
-/* Nonzero if register N requires conversion
-   from raw format to virtual format.  */
-
-#undef REGISTER_CONVERTIBLE
-#define REGISTER_CONVERTIBLE(N) ((N) < FP0_REGNUM ? 0 :\
-                                 (N) < FPC_REGNUM ? 1 : 0)
+#include "i386/tm-i386.h"
 
 /* The host and target are i386 machines and the compiler supports
    long doubles. Long doubles on the host therefore have the same
@@ -142,70 +44,34 @@
 
 extern int i387_hex_long_double_input (char *p, long double *putithere);
 
+#ifdef LD_I387	/* otherwise, definitions from tm-i386.h are good enough */
+
 #undef REGISTER_CONVERT_TO_VIRTUAL
-#ifdef LD_I387
-#define REGISTER_CONVERT_TO_VIRTUAL(REGNUM,TYPE,FROM,TO) \
-{ \
-  if (TYPE == REGISTER_VIRTUAL_TYPE (REGNUM)) \
-    { \
-      memcpy (TO, FROM, TYPE_LENGTH (TYPE)); \
-    } \
-  else \
-    { \
-      long double val = *((long double *)FROM); \
-      store_floating ((TO), TYPE_LENGTH (TYPE), val); \
-    } \
+#define REGISTER_CONVERT_TO_VIRTUAL(REGNUM,TYPE,FROM,TO)	\
+{								\
+  long double val = *((long double *)(FROM));			\
+  store_floating ((TO), TYPE_LENGTH (TYPE), val);		\
 }
-#else
-/* Convert data from raw format for register REGNUM in buffer FROM to
-   virtual format with type TYPE in buffer TO.  */
-#define REGISTER_CONVERT_TO_VIRTUAL(REGNUM,TYPE,FROM,TO) \
-{ \
-  double val; \
-  i387_to_double ((FROM), (char *)&val); \
-  store_floating ((TO), TYPE_LENGTH (TYPE), val); \
-}
-#endif
-
-extern void i387_to_double PARAMS ((char *, char *));
 
 #undef REGISTER_CONVERT_TO_RAW
-#ifdef LD_I387
-#define REGISTER_CONVERT_TO_RAW(TYPE,REGNUM,FROM,TO) \
-{ \
-  if (TYPE == REGISTER_VIRTUAL_TYPE (REGNUM)) \
-    { \
-      memcpy (TO, FROM, TYPE_LENGTH (TYPE)); \
-    } \
-  else \
-    { \
-      long double val = extract_floating ((FROM), TYPE_LENGTH (TYPE)); \
-      *((long double *)TO) = val; \
-    } \
-}
-#else
-#define REGISTER_CONVERT_TO_RAW(TYPE,REGNUM,FROM,TO) \
-{ \
-  double val = extract_floating ((FROM), TYPE_LENGTH (TYPE)); \
-  double_to_i387((char *)&val, (TO)); \
+#define REGISTER_CONVERT_TO_RAW(TYPE,REGNUM,FROM,TO)			\
+{									\
+  long double val = extract_floating ((FROM), TYPE_LENGTH (TYPE));	\
+  *((long double *)(TO)) = val;						\
 }
-#endif
 
-extern void double_to_i387 PARAMS ((char *, char *));
+/* Return the GDB type object for the "standard" data type of data in 
+   register N.  Perhaps si and di should go here, but potentially they
+   could be used for things other than address.  */
+
+#define REGISTER_VIRTUAL_TYPE(N)				\
+  (((N) == PC_REGNUM || (N) == FP_REGNUM || (N) == SP_REGNUM)	\
+   ? lookup_pointer_type (builtin_type_void)			\
+   : IS_FP_REGNUM(N) ? builtin_type_long_double 		\
+   : IS_SSE_REGNUM(N) ? builtin_type_v4sf			\
+   : builtin_type_int)
 
-/* Return the GDB type object for the "standard" data type of data in
-   register N.  */
-
-#undef REGISTER_VIRTUAL_TYPE
-#ifdef LD_I387
-#define REGISTER_VIRTUAL_TYPE(N) \
-  ((N < FP0_REGNUM) ? builtin_type_int : \
-   (N < FPC_REGNUM) ? builtin_type_long_double : builtin_type_int)
-#else
-#define REGISTER_VIRTUAL_TYPE(N) \
-  ((N < FP0_REGNUM) ? builtin_type_int : \
-   (N < FPC_REGNUM) ? builtin_type_double : builtin_type_int)
-#endif
+#endif /* LD_I387 */
 
 #undef TARGET_LONG_DOUBLE_BIT
 #define TARGET_LONG_DOUBLE_BIT 96
--- gdb/config/i386/xm-go32.h~1	Mon Apr 26 18:26:22 1999
+++ gdb/config/i386/xm-go32.h	Wed Aug 18 08:30:52 1999
@@ -25,7 +25,7 @@
 
 #define SLASH_P(X) ((X)=='\\' || (X) == '/')
 
-#define ROOTED_P(X) ((SLASH_P((X)[0]))|| ((X)[1] ==':'))
+#define ROOTED_P(X) ((SLASH_P((X)[0])) || ((X)[0] && (X)[1] ==':'))
 
 #define SLASH_CHAR '/'
 #define SLASH_STRING "/"
--- gdb/config/i386/nm-go32.h~1	Sun Aug  8 12:41:38 1999
+++ gdb/config/i386/nm-go32.h	Sat Aug 14 14:59:08 1999
@@ -24,8 +23,31 @@
 
 #define TARGET_HAS_HARDWARE_WATCHPOINTS
 
+/* Returns the number of hardware watchpoints of type TYPE that we can
+   set.  Value is positive if we can set CNT watchpoints, zero if
+   setting watchpoints of type TYPE is not supported, and negative if
+   CNT is more than the maximum number of watchpoints of type TYPE
+   that we can support.  TYPE is one of bp_hardware_watchpoint,
+   bp_read_watchpoint, bp_write_watchpoint, or bp_hardware_breakpoint.
+   CNT is the number of such watchpoints used so far (including this
+   one).  OTHERTYPE is non-zero if other types of watchpoints are
+   currently enabled.
+
+   We always return 1 here because we don't have enough information
+   about possible overlap of addresses that they want to watch.  As
+   an extreme example, consider the case where all the watchpoints
+   watch the same address and the same region length: then we can
+   handle a virtually unlimited number of watchpoints, due to debug
+   register sharing implemented via reference counts in go32-nat.c.  */
+
 #define TARGET_CAN_USE_HARDWARE_WATCHPOINT(type, cnt, ot) 1
 
+/* Returns non-zero if we can use hardware watchpoints to watch a region
+   whose address is ADDR and whose length is LEN.  */
+
+#define TARGET_REGION_OK_FOR_HW_WATCHPOINT(addr,len) \
+	go32_region_ok_for_watchpoint(addr,len)
+
 /* After a watchpoint trap, the PC points to the instruction after the
    one that caused the trap.  Therefore we don't need to step over it.
    But we do need to reset the status register to avoid another trap.  */
@@ -33,19 +55,22 @@
 #define HAVE_CONTINUABLE_WATCHPOINT
 
 #define STOPPED_BY_WATCHPOINT(W)  \
-  go32_stopped_by_watchpoint (inferior_pid)
+  go32_stopped_by_watchpoint (inferior_pid, 0)
+
+#define target_stopped_data_address() \
+  go32_stopped_by_watchpoint (inferior_pid, 1)
 
 /* Use these macros for watchpoint insertion/removal.  */
 
 #define target_insert_watchpoint(addr, len, type)  \
-  go32_insert_watchpoint (inferior_pid, addr, len, 2)
+  go32_insert_watchpoint (inferior_pid, addr, len, type)
 
 #define target_remove_watchpoint(addr, len, type)  \
-  go32_remove_watchpoint (inferior_pid, addr, len)
+  go32_remove_watchpoint (inferior_pid, addr, len, type)
 
 #define target_insert_hw_breakpoint(addr, shadow)  \
   go32_insert_hw_breakpoint(addr, shadow)
-
+  
 #define target_remove_hw_breakpoint(addr, shadow)  \
   go32_remove_hw_breakpoint(addr, shadow)
 
@@ -55,3 +80,4 @@
 #define FLOAT_INFO { i386_go32_float_info (); }
 
 extern void i386_go32_float_info (void);
+
From eliz@gnu.org Wed Nov 10 14:50:00 1999
From: Eli Zaretskii <eliz@gnu.org>
To: ezannoni@cygnus.com, dj@delorie.com
Cc: muller@cerbere.u-strasbg.fr, shebs@cygnus.com, gdb-patches@sourceware.cygnus.com
Subject: Re: go32-nat.c compilation problem
Date: Wed, 10 Nov 1999 14:50:00 -0000
Message-id: <199911102250.RAA01938@mescaline.gnu.org>
References: <199911081709.SAA23904@cerbere.u-strasbg.fr> <14375.536.118347.328812@kwikemart.cygnus.com> <199911081742.MAA20623@mescaline.gnu.org> <14375.5038.377535.816858@kwikemart.cygnus.com>
X-SW-Source: 1999-q4/msg00223.html
Content-length: 2683

> Fatal() was deleted, and then changes to go32-nat.c were made that
> reintroduced calls to fatal(). I believe the changes were part of a patch
> you submitted, *before* the function fatal was replaced by internal_error().

Here are the diffs for go32-nat.c that should fix this.

1999-11-10  Eli Zaretskii  <eliz@is.elta.co.il>

	* go32-nat.c (go32_fetch_registers, store_register)
	(go32_create_inferior, init_go32_ops): Replace fatal with
	internal_error.
	(sig_map): Map exception 7 to TARGET_SIGNAL_EMT.


--- gdb/go32-nat.c~1	Wed Oct 13 13:39:00 1999
+++ gdb/go32-nat.c	Wed Nov 10 16:49:06 1999
@@ -345,7 +345,7 @@ sig_map[] =
     4, TARGET_SIGNAL_FPE,
     5, TARGET_SIGNAL_SEGV,
     6, TARGET_SIGNAL_ILL,
-    7, TARGET_SIGNAL_FPE,
+    7, TARGET_SIGNAL_EMT,	/* no-coprocessor exception */
     8, TARGET_SIGNAL_SEGV,
     9, TARGET_SIGNAL_SEGV,
     10, TARGET_SIGNAL_BUS,
@@ -570,7 +570,8 @@ go32_fetch_registers (int regno)
 	supply_register (regno,
 			 (char *) &npx + regno_mapping[regno].tss_ofs);
       else
-	fatal ("Invalid register no. %d in go32_fetch_register.", regno);
+	internal_error ("Invalid register no. %d in go32_fetch_register.",
+			regno);
     }
 }
 
@@ -587,7 +588,7 @@ store_register (int regno)
   else if (regno < 31)
     rp = (char *) &npx + regno_mapping[regno].tss_ofs;
   else
-    fatal ("Invalid register no. %d in store_register.", regno);
+    internal_error ("Invalid register no. %d in store_register.", regno);
   memcpy (rp, v, regno_mapping[regno].size);
 }
 
@@ -680,7 +681,7 @@ go32_create_inferior (char *exec_file, c
   resume_is_step = 0;
   /* Init command line storage.  */
   if (redir_debug_init (&child_cmd) == -1)
-    fatal ("Cannot allocate redirection storage: not enough memory.\n");
+    internal_error ("Cannot allocate redirection storage: not enough memory.\n");
 
   /* Parse the command line and create redirections.  */
   if (strpbrk (args, "<>"))
@@ -1311,7 +1312,7 @@ init_go32_ops (void)
 
   /* Initialize child's command line storage.  */
   if (redir_debug_init (&child_cmd) == -1)
-    fatal ("Cannot allocate redirection storage: not enough memory.\n");
+    internal_error ("Cannot allocate redirection storage: not enough memory.\n");
 }
 
 void
--- gdb/utils.c~1	Wed Nov 10 12:58:14 1999
+++ gdb/utils.c	Wed Nov 10 16:51:24 1999
@@ -787,7 +787,7 @@ notice_quit ()
     immediate_quit = 1;
 }
 
-#else /* !defined(__GO32__) && !defined(_MSC_VER) */
+#else /* !defined(_MSC_VER) */
 
 void
 notice_quit ()
@@ -795,7 +795,7 @@ notice_quit ()
   /* Done by signals */
 }
 
-#endif /* !defined(__GO32__) && !defined(_MSC_VER) */
+#endif /* !defined(_MSC_VER) */
 
 /* Control C comes here */
 void
From kingdon@redhat.com Wed Nov 10 15:31:00 1999
From: Jim Kingdon <kingdon@redhat.com>
To: hjl@lucon.org
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: Make threads architecture-independent on Linux
Date: Wed, 10 Nov 1999 15:31:00 -0000
Message-id: <199911102331.SAA08531@devserv.devel.redhat.com>
References: <19991108233623.805581B493@ocean.lucon.org>
X-SW-Source: 1999-q4/msg00224.html
Content-length: 865

> I will advise against it. You can take a look at gdb 4.17.0.14 to
> see how it is handled there.

Uh, OK, I've just looked at it.  The bits to make threads
arch-independent look pretty similar to my patch to me.

Perhaps you (or someone) could offer a more specific critique?
Failing more specifics, I'd advocate checking my patch in.  That's
http://sourceware.cygnus.com/ml/gdb-patches/1999-q4/msg00207.html
for those who might have lost track.

> I will make a patch for gdb 4.18 when the backlog improves.

I don't think that waiting for future patches is a good plan.  This
isn't just directed at you, HJ, it applies equally to all the Cygnus
threads changes which are in progress and/or planned.  Especially
since just about everything being discussed (backlog, floating point,
libthread_db analogue, &c) is orthogonal to making the config
arch-independent.
From hjl@lucon.org Wed Nov 10 15:49:00 1999
From: hjl@lucon.org (H.J. Lu)
To: kingdon@redhat.com (Jim Kingdon)
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: Make threads architecture-independent on Linux
Date: Wed, 10 Nov 1999 15:49:00 -0000
Message-id: <19991110234852.420C61B493@ocean.lucon.org>
References: <199911102331.SAA08531@devserv.devel.redhat.com>
X-SW-Source: 1999-q4/msg00225.html
Content-length: 2412

> 
> > I will advise against it. You can take a look at gdb 4.17.0.14 to
> > see how it is handled there.
> 
> Uh, OK, I've just looked at it.  The bits to make threads
> arch-independent look pretty similar to my patch to me.

But you don't have config/tm-linux.h.

> 
> Perhaps you (or someone) could offer a more specific critique?

You should have config/tm-linux.h enclosed here and modify all the
Linux tm files to include it. Otherwise, linuxthreads won't work
right if REALTIME_HI and REALTIME_LO are not correct.

> Failing more specifics, I'd advocate checking my patch in.  That's
> http://sourceware.cygnus.com/ml/gdb-patches/1999-q4/msg00207.html
> for those who might have lost track.
> 
> > I will make a patch for gdb 4.18 when the backlog improves.
> 
> I don't think that waiting for future patches is a good plan.  This
> isn't just directed at you, HJ, it applies equally to all the Cygnus
> threads changes which are in progress and/or planned.  Especially
> since just about everything being discussed (backlog, floating point,
> libthread_db analogue, &c) is orthogonal to making the config
> arch-independent.
> 

My gdb tree is a mess. I don't have the time to clean it up. I don't
want to spend time on it before gdb in CVS is in reasonable shape.



-- 
H.J. Lu (hjl@gnu.org)
--
/* Macro definitions for Linux targets.
   Copyright 1999 Free Software Foundation, Inc.

This file is part of GDB.

This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.

This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
GNU General Public License for more details.

You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.  */

/* Some versions of Linux have real-time signal support in the C library, and
   some don't.  We have to include this file to find out.  */
#include <signal.h>

#ifdef __SIGRTMIN
#define REALTIME_LO __SIGRTMIN
#define REALTIME_HI (__SIGRTMAX + 1)
#else
#define REALTIME_LO 32
#define REALTIME_HI 64
#endif


       reply	other threads:[~1999-11-10 13:38 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <19991108233623.805581B493@ocean.lucon.org>
1999-11-10 13:38 ` Mark Kettenis [this message]
     [not found] <19991110234852.420C61B493@ocean.lucon.org>
1999-11-12 10:58 ` Jim Kingdon
1999-11-19 13:35   ` Jim Blandy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=199911102138.WAA00378@delius.kettenis.local \
    --to=kettenis@wins.uva.nl \
    --cc=gdb-patches@sourceware.cygnus.com \
    --cc=hjl@lucon.org \
    --cc=kingdon@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox