* Re: [PATCH] Fix for target.c:do_target_signal_to_host()
[not found] ` <38A90F10.E61AF586@cygnus.com>
@ 2000-04-01 0:00 ` Mark Kettenis
0 siblings, 0 replies; only message in thread
From: Mark Kettenis @ 2000-04-01 0:00 UTC (permalink / raw)
To: ac131313; +Cc: gdb-patches
Date: Tue, 15 Feb 2000 19:32:16 +1100
From: Andrew Cagney <ac131313@cygnus.com>
If you add a comment noting that:
o TARGET_SIGNAL_REALTIME_32 isn't
contigious with TARGET_SIGNAL_REALTIME_32
o TARGET_SIGNAL_REALTIME_33 is 33 by defintion.
then it can go straight in.
While adding the comments I noticed that the function will return 32
for TARGET_SIGNAL_REALTIME_32 even if it doesn't exist, and that (with
my patch) for the other RT signals the upper bound was checked, but
not the lower bound. Not likely to be very problematic, but this is
not right according to the comment at the top of the function.
I also moved the TARGET_SIGNAL_REALTIME_32 case within the
default: where the other RT signals are handled. I think this
makes it easier to understand the code.
OK to check this in?
Mark
2000-02-16 Mark Kettenis <kettenis@gnu.org>
* target.c (do_target_signal_to_host): Do not use REALTIME_LO in
the conversion of the signal number. TARGET_SIGNAL_REALTIME_33 is
33 by definition, whereas REALTIME_LO might be 32 on systems that
have SIG32 such as Linux. Make sure that the signal number
returned is within the range specified by REALTIME_LO and
REALTIME_HI.
Index: gdb/target.c
===================================================================
RCS file: /cvs/src/src/gdb/target.c,v
retrieving revision 1.2
diff -u -r1.2 target.c
--- gdb/target.c 2000/02/09 08:52:47 1.2
+++ gdb/target.c 2000/02/16 15:12:31
@@ -2022,8 +2022,6 @@
return SIGPRIO;
#endif
- case TARGET_SIGNAL_REALTIME_32: return 32; /* by definition */
-
/* Mach exceptions. Assumes that the values for EXC_ are positive! */
#if defined (EXC_BAD_ACCESS) && defined (_NSIG)
case TARGET_EXC_BAD_ACCESS:
@@ -2060,11 +2058,21 @@
if (oursig >= TARGET_SIGNAL_REALTIME_33
&& oursig <= TARGET_SIGNAL_REALTIME_63)
{
+ /* This block of signals is continuous, and
+ TARGET_SIGNAL_REALTIME_33 is 33 by definition. */
int retsig =
- (int) oursig - (int) TARGET_SIGNAL_REALTIME_33 + REALTIME_LO;
- if (retsig < REALTIME_HI)
+ (int) oursig - (int) TARGET_SIGNAL_REALTIME_33 + 33;
+ if (retsig >= REALTIME_LO && retsig < REALTIME_HI)
return retsig;
}
+#if (REALTIME_LO < 33)
+ else if (oursig == TARGET_SIGNAL_REALTIME_32)
+ {
+ /* TARGET_SIGNAL_REALTIME_32 isn't contiguous with
+ TARGET_SIGNAL_REALTIME_33. It is 32 by definition. */
+ return 32;
+ }
+#endif
#endif
*oursig_ok = 0;
return 0;
From kingdon@redhat.com Sat Apr 01 00:00:00 2000
From: Jim Kingdon <kingdon@redhat.com>
To: gdb-patches@sourceware.cygnus.com
Subject: Re: GDB-5 2000-03-03
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <bu2imls7e.fsf@rtl.cygnus.com>
References: <38BFBD74.79263683@cygnus.com> <200003031714.e23HEC900400@delius.kettenis.local> <b66v3g6zb.fsf@rtl.cygnus.com> <38C07857.36B3FB41@cygnus.com>
X-SW-Source: 2000-q1/msg00507.html
Content-length: 593
> Jim, in this case (where a patch is submitted before someone becomes
> maintainer) some general confusion is allowed. If I was in Mark's boots
> I wouldn't be sure what the state of many patches (especially the non
> Linux specific ones) were in.
Oh, in the case of new maintainers I expect general confusion in
general (which is more than general confusion in the case of
previously submitted patches ;-)).
I was hoping I could help resolve some of the confusion (and I appear
to have have been wrong :-)).
Hack away folks, and I'll try to not to be too much in the way....
From msnyder@cygnus.com Sat Apr 01 00:00:00 2000
From: Michael Snyder <msnyder@cygnus.com>
To: Eli Zaretskii <eliz@is.elta.co.il>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: gdb.texinfo broken?
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38D7C977.FA3@cygnus.com>
References: <38D6CF69.6844@cygnus.com> <200003211819.NAA12435@indy.delorie.com>
X-SW-Source: 2000-q1/msg00864.html
Content-length: 3784
Eli Zaretskii wrote:
>
> > Following the recent spate of patches to gdb.texinfo,
> > I find that I cannot build gdb.info; it's been a long
> > time since I tried, so I do not know exactly when or
> > with what patch it broke.
>
> Can you post the error mesage(s) you get from "make info"? perhaps
> they are descriptive enough to identify the offending line(s).
Sure.
%] msnyder<2>% make gdb.info
makeinfo -I
/cleaver/blade/msnyder/sourceware/src/gdb/doc/../../readline/doc -I
/cleaver/blade/msnyder/sourceware/src/gdb/doc -o ./gdb.info gdb.texinfo
Making info file `./gdb.info' from `gdb.texinfo'.
gdb.texinfo:113: No matching `@end ifnottex'.
gdb.texinfo:156: Unmatched `@end'.
/cleaver/blade/msnyder/sourceware/src/gdb/doc/annotate.texi:52: Node
`Top' multiply defined (line 114 is first definition at).
/cleaver/blade/msnyder/sourceware/src/gdb/doc/annotate.texi:53: Node
with @top as a section already exists.
/cleaver/blade/msnyder/sourceware/src/gdb/doc/gdb.texinfo:114: Here is
the @top node.
/cleaver/blade/msnyder/sourceware/src/gdb/doc/annotate.texi:121: Node
`Server' multiply defined (line 9531 is first definition at).
/cleaver/blade/msnyder/sourceware/src/gdb/doc/annotate.texi:260: Node
`Frames' multiply defined (line 3554 is first definition at).
/cleaver/blade/msnyder/sourceware/src/gdb/doc/annotate.texi:604: Node
`Running' multiply defined (line 1417 is first definition at).
/cleaver/blade/msnyder/sourceware/src/gdb/doc/annotate.texi:673: Node
`Source' multiply defined (line 3845 is first definition at).
gdb.texinfo:12673: Node `Index' multiply defined (line 712 is first
definition at).
/cleaver/blade/msnyder/sourceware/src/gdb/doc/gdb.texinfo:11874: Next
reference to nonexistent node `Annotations'.
/cleaver/blade/msnyder/sourceware/src/gdb/doc/annotate.texi:79: Node
`General''s Next field not pointed back to.
/cleaver/blade/msnyder/sourceware/src/gdb/doc/gdb.texinfo:9531: This
node (`Server') is the one with the bad `Prev'.
/cleaver/blade/msnyder/sourceware/src/gdb/doc/annotate.texi:134: Node
`Values''s Next field not pointed back to.
/cleaver/blade/msnyder/sourceware/src/gdb/doc/gdb.texinfo:3554: This
node (`Frames') is the one with the bad `Prev'.
/cleaver/blade/msnyder/sourceware/src/gdb/doc/annotate.texi:134: Node
`Values's Prev field not pointed back to.
/cleaver/blade/msnyder/sourceware/src/gdb/doc/gdb.texinfo:9531: This
node (`Server') has the bad Next.
/cleaver/blade/msnyder/sourceware/src/gdb/doc/annotate.texi:393: Node
`Displays's Prev field not pointed back to.
/cleaver/blade/msnyder/sourceware/src/gdb/doc/gdb.texinfo:3554: This
node (`Frames') has the bad Next.
/cleaver/blade/msnyder/sourceware/src/gdb/doc/annotate.texi:584: Node
`Invalidation''s Next field not pointed back to.
/cleaver/blade/msnyder/sourceware/src/gdb/doc/gdb.texinfo:1417: This
node (`Running') is the one with the bad `Prev'.
/cleaver/blade/msnyder/sourceware/src/gdb/doc/annotate.texi:695: Node
`TODO's Prev field not pointed back to.
/cleaver/blade/msnyder/sourceware/src/gdb/doc/gdb.texinfo:3845: This
node (`Source') has the bad Next.
/cleaver/blade/msnyder/sourceware/src/gdb/doc/gdb.texinfo:12050: Prev
reference to nonexistent node `Annotations'.
/cleaver/blade/msnyder/sourceware/src/gdb/doc/gdb.texinfo:12381: Node
`Installing GDB''s Next field not pointed back to.
/cleaver/blade/msnyder/sourceware/src/gdb/doc/annotate.texi:712: This
node (`Index') is the one with the bad `Prev'.
/cleaver/blade/msnyder/sourceware/src/gdb/doc/gdb.texinfo:928: Cross
reference to nonexistent node `Annotations'.
/cleaver/blade/msnyder/sourceware/src/gdb/doc/gdb.texinfo:145: Menu
reference to nonexistent node `Annotations'.
makeinfo: Removing output file `./gdb.info' due to errors; use --force
to preserve.
make: *** [gdb.info] Error 2
%] msnyder<3>%
From rearnsha@arm.com Sat Apr 01 00:00:00 2000
From: Richard Earnshaw <rearnsha@arm.com>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: rearnsha@arm.com
Subject: Re: Recommend directory update
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200002231134.LAA00557@cam-mail2.cambridge.arm.com>
References: <38B3C390.214B8988@cygnus.com>
X-SW-Source: 2000-q1/msg00333.html
Content-length: 962
> > Any chance that we can crib the contrib structure from gcc and have
> > contrib/update_{gdb,binutils,...}? This would then ensure that configure
> > files didn't get mangled either.
>
> Um, I'm not sure what you mean.
>
> Andrew
Sorry, structure was probably a misleading word to use. contrib is a
directory in the top-level of the source tree. It contains (amongst other
things) a script called gcc_update. This script will update a local copy
of your cvs repository by doing a suitable sequence of "cvs update"
commands. The final part of the script will then touch certain
autogenerated files such as gcc/configure to make sure that it is more
recent than gcc/configure.in -- this avoids the need to continuously track
tools such as autoconf to ensure that your copy is in sync with the copy
used in the repository.
In summary, it's a shell script that does the right things to update the
source for the tool you have checked out.
R.
^ permalink raw reply [flat|nested] only message in thread