From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark Kettenis To: ac131313@cygnus.com Cc: gdb-patches@sourceware.cygnus.com Subject: Re: [PATCH] Fix for target.c:do_target_signal_to_host() Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <200002161532.e1GFWaf03903@delius.kettenis.local> References: <200002142116.e1ELGrL06391@delius.kettenis.local> <38A90F10.E61AF586@cygnus.com> X-SW-Source: 2000-q1/msg00180.html Date: Tue, 15 Feb 2000 19:32:16 +1100 From: Andrew Cagney 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 * 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 To: gdb-patches@sourceware.cygnus.com Subject: Re: GDB-5 2000-03-03 Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: References: <38BFBD74.79263683@cygnus.com> <200003031714.e23HEC900400@delius.kettenis.local> <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 To: Eli Zaretskii 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 To: Andrew Cagney 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.