From mboxrd@z Thu Jan 1 00:00:00 1970 From: hjl@lucon.org (H.J. Lu) To: grante@visi.com (Grant Edwards) Cc: 666@grafzahl.de, gdb@sourceware.cygnus.com (GDB) Subject: Re: ignoring unknown signals Date: Tue, 02 Nov 1999 11:44:00 -0000 Message-id: <19991102194418.203091B493@ocean.lucon.org> References: <19991102132742.A19465@visi.com> X-SW-Source: 1999-q4/msg00207.html > > On Tue, Nov 02, 1999 at 11:24:32AM -0800, H.J. Lu wrote: > > > gdb 4.18 is broken on Linux. You can do > > What does "on Linux" mean? > > Linux as the host, Linux as the target? > As the target. It doesn't work as good as gdb 4.17.0.14 in many aspects. -- H.J. Lu (hjl@gnu.org) >From scottb@netwinder.org Tue Nov 02 14:00:00 1999 From: Scott Bambrough To: GDB Mailing List Subject: Recent changes to rdi-share... Date: Tue, 02 Nov 1999 14:00:00 -0000 Message-id: <381F5DF0.304D187C@netwinder.org> X-SW-Source: 1999-q4/msg00208.html Content-length: 1900 I just did a clean checkout, and build of the arm-coff, arm-elf targets and they fail in rdi-share. Is something missing from the patch? Perhaps in Makefile, Makefile.in? I thought bytesex.* was removed. make[2]: Entering directory `/home/scottb/cvstree/gdb-arm-coff/gdb/rdi-share' gcc -DPACKAGE=\"rdi-share\" -DVERSION=\"1.0\" -DSTDC_HEADERS=1 -DHAVE_FCNTL_H=1 -DHAVE_SYS_IOCTL_H=1 -DHAVE_SYS_TIME_H=1 -DHAVE_UNISTD_H=1 -DTIME_WITH_SYS_TIME=1 -DRETSIGTYPE=void -DHAVE_VPRINTF=1 -DHAVE_GETTIMEOFDAY=1 -DHAVE_SELECT=1 -DHAVE_SOCKET=1 -DHAVE_STRTOD=1 -DHAVE_STRTOUL=1 -DHAVE_MEMCPY=1 -DHAVE_MEMMOVE=1 -I. -I../../../gdb/gdb/rdi-share -DRETRANS -DARM_RELEASE='"Berkeley Licence for Cygnus"' -g -O2 -W -Wall -c ../../../gdb/gdb/rdi-share/ardi.c ../../../gdb/gdb/rdi-share/ardi.c: In function `wait_for_debug_message': ../../../gdb/gdb/rdi-share/ardi.c:157: warning: suggest parentheses around comparison in operand of & ../../../gdb/gdb/rdi-share/ardi.c: In function `angel_RDI_info': ../../../gdb/gdb/rdi-share/ardi.c:1824: warning: suggest parentheses around comparison in operand of & ../../../gdb/gdb/rdi-share/ardi.c: At top level: ../../../gdb/gdb/rdi-share/ardi.c:2647: warning: missing initializer ../../../gdb/gdb/rdi-share/ardi.c:2647: warning: (near initialization for `angel_rdi.targetisdead') ../../../gdb/gdb/rdi-share/ardi.c:2661: warning: missing initializer ../../../gdb/gdb/rdi-share/ardi.c:2661: warning: (near initialization for `hostappl_CmdTable[0].syntax') make[2]: *** No rule to make target `bytesex.o', needed by `libangsd.a'. Stop. make[2]: Leaving directory `/home/scottb/cvstree/gdb-arm-coff/gdb/rdi-share' make[1]: *** [rdi-share/libangsd.a] Error 2 make[1]: Leaving directory `/home/scottb/cvstree/gdb-arm-coff/gdb' make: *** [all-gdb] Error 2 Scott -- Scott Bambrough - Software Engineer REBEL.COM http://www.rebel.com NetWinder http://www.netwinder.org >From ac131313@cygnus.com Tue Nov 02 18:19:00 1999 From: Andrew Cagney To: GDB Discussion Subject: Re: Dejagnu as part of repository? Date: Tue, 02 Nov 1999 18:19:00 -0000 Message-id: <381F9BA6.FD120AC4@cygnus.com> References: <381824BF.BCE63370@cygnus.com> X-SW-Source: 1999-q4/msg00209.html Content-length: 543 Andrew Cagney wrote: > > Hello, > > Should the GDB repository contain dejagnu? > > A user wanting to run GDB tests could then just check out ``gdb > dejagnu'' and build instantly and run the tests. I figure that while > dejagnu is a separate product the way GDB uses it is very like READLINE > in that it is imported and then locked in. > > Thoughts? Clearly there is the need to ensure that it is kept in sync > with GCC. > > Andrew FYI, I've seen zero objections to this proposal. I'll start following it through. Andrew >From ac131313@cygnus.com Wed Nov 03 01:15:00 1999 From: Andrew Cagney To: gdb@sourceware.cygnus.com Subject: #define XMALLOC(TYPE) (TYPE*) xmalloc (sizeof (TYPE)) Date: Wed, 03 Nov 1999 01:15:00 -0000 Message-id: <381FFC42.4EC314D8@cygnus.com> X-SW-Source: 1999-q4/msg00210.html Content-length: 570 Hello, Here is a style question. A convention I adopted when developing psim (gdb/sim/ppc) was to use the macro: #define XMALLOC(TYPE) (TYPE*) xmalloc (sizeof (TYPE)) vis: struct xyz *x = XMALLOC (struct xyz); rather than the more common: struct xyz *x = (struct xyz *) xmalloc (sizeof (struct syz)); /*[sic]*/ It's a poor persons ``new()''. Would people react violently if this definition was pushed into defs.h where it could be used more widely? This is very different to making it a requirement of any coding standard. enjoy, Andrew >From jimb@cygnus.com Wed Nov 03 06:40:00 1999 From: Jim Blandy To: Daniel Vogel <666@grafzahl.de> Cc: gdb@sourceware.cygnus.com Subject: Re: handling of unknown signals Date: Wed, 03 Nov 1999 06:40:00 -0000 Message-id: References: <381D94AD.B37EC167@grafzahl.de> X-SW-Source: 1999-q4/msg00211.html Content-length: 435 > when trying to debug a program that uses threads gbd (4.18) stops with: > > Program received signal ?, Unknown signal. GDB 4.18 doesn't include LinuxThreads support, so the signals the threads use to communicate with each other confuse GDB. Because GDB doesn't know what the signal is, you can't really tell it to pass it through. Try a GDB snapshot from http://sourceware.cygnus.com/gdb . The LinuxThreads support is in there. >From shebs@cygnus.com Wed Nov 03 19:20:00 1999 From: Stan Shebs To: cagney@cygnus.com Cc: gdb@sourceware.cygnus.com Subject: Re: #define XMALLOC(TYPE) (TYPE*) xmalloc (sizeof (TYPE)) Date: Wed, 03 Nov 1999 19:20:00 -0000 Message-id: <199911040320.TAA09824@andros.cygnus.com> References: <381FFC42.4EC314D8@cygnus.com> X-SW-Source: 1999-q4/msg00212.html Content-length: 1296 From: Andrew Cagney Date: Wed, 03 Nov 1999 20:11:30 +1100 Here is a style question. A convention I adopted when developing psim (gdb/sim/ppc) was to use the macro: #define XMALLOC(TYPE) (TYPE*) xmalloc (sizeof (TYPE)) I have mixed feelings about this. The simplification is attractive, but I'm cringing at the idea of introducing still more macros into the sources (although I notice that you introduced it into several files already...). Also, this version only simplifies the singleton allocations, though admittedly those seem to account for about 2/3 of the xmalloc calls. If everybody else likes this, I'll go along. It's a poor persons ``new()''. Would people react violently if this definition was pushed into defs.h where it could be used more widely? This is very different to making it a requirement of any coding standard. If we *do* use this, I would rather encourage its use, add a multiplying version (call it XMALLOC_N or some such), deprecate bare calls to xmalloc, and - ideally - change all the existing calls. It's much more important to me to be consistent throughout the code. Otherwise future GDB hackers will scratch their heads and wonder whether they're supposed to be using xmalloc or XMALLOC. Stan