Re: ignoring unknown signals

Re: ignoring unknown signals

[Grant Edwards]

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?

> 1. Wait for 4.19.
> 2. Get the current one from CVS.
> 3. Try gdb 4.17.0.14 for Linux.

-- 
Grant Edwards
grante@visi.com

Re: ignoring unknown signals

[H.J. Lu]

> 
> 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 <scottb@netwinder.org>
To: GDB Mailing List <gdb@sourceware.cygnus.com>
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 <ac131313@cygnus.com>
To: GDB Discussion <gdb@sourceware.cygnus.com>
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 <ac131313@cygnus.com>
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 <jimb@cygnus.com>
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: <npeme7k5a6.fsf@zwingli.cygnus.com>
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 <shebs@cygnus.com>
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 <ac131313@cygnus.com>
   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