Re: Try out the patch database

[Andrew Cagney <ac131313@cygnus.com>]

Jim Blandy wrote:
> 
> Take a look at http://sourceware.cygnus.com/gdb/contribute.html , and
> let me know what you think.

Jim,

the file that ultimatly needs to have this information is
gdb/CONTRIBUTE.  That is what gets shipped.

> I'd like to incorporate the text of that page itself into the main GDB
> page, http://sourceware.cygnus.com/gdb/ .
> 
> contribute.html refers to three new pages:
> 
> - patch-db.html, which is supposed to be everything a new contributor
>   needs to know to add a patch to the patch database.
> 
> - patch-checklist.html, a checklist for submitting patches via
>   E-mail.  Originally, I was going to do a template, but it seems like
>   GNATS will do everything that's important automatically, so I don't
>   think a template offers much benefit over simple instructions.
> 
> - assigning.html, a page explaining the copyright situation, and
>   directing people to talk to me.  Eventually, of course, we'll want a
>   role mail address for this, but I want to get things going quickly.

Perhaphs, renaming ``Development'' to ``Contributing'' would be
sufficient.

	Andrew
From toddpw@windriver.com Sat Apr 01 00:00:00 2000
From: Todd Whitesel <toddpw@windriver.com>
To: kingdon@redhat.com (Jim Kingdon)
Cc: gdb@sourceware.cygnus.com (GDB Developers)
Subject: Re: A patch for ia32 hardware watchpoint.
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200003090344.TAA25378@alabama.wrs.com>
References: <bsny1fths.fsf@rtl.cygnus.com>
X-SW-Source: 2000-q1/msg00632.html
Content-length: 1348

> The two approaches aren't mutually exclusive, actually, we probably
> want both a canonicalized status and a way to get more specific
> information in a free-form way.

The numbering scheme I prefer has multiple layers. For each event type
that GDB handles in a generic way, there is a value of TARGET_WAITKIND_*
that is always preferred. For miscellaneous events that GDB doesn't know
how to handle specifically, you have TARGET_WAITKIND_SIGNALLED or
TARGET_WAITKIND_CPU_EXCEPTION, both of which activate a target-defined
auxiliary field that carries the signal/exception type. When this happens:

For unixy targets, you get TARGET_WAITKIND_SIGNALLED and a signal number.
For raw targets, you get TARGET_WAITKIND_CPU_EXCEPTION and a vector number
(or something like it -- on many RISC chips this is not a simple integer).

The reactionary position is:

It is not the job of the generic inferior event stuff to disambiguate
unixy signals like SIGTRAP. That is what unix tdep files are for.

The more reasonable position is:

As early as possible, I want a SIGTRAP to become a TARGET_WAITKIND_BREAKPOINT
so that above some layer I never have to think about SIGTRAP on any target,
except in the case of a spurious SIGTRAP that matches no breakpoint, which
should be treated like any other uncaught signal.

-- 
Todd Whitesel
toddpw @ windriver.com
From dan@cgsoftware.com Sat Apr 01 00:00:00 2000
From: Daniel Berlin <dan@cgsoftware.com>
To: Eli Zaretskii <eliz@delorie.com>
Cc: gdb@sourceware.cygnus.com, DJ Delorie <dj@delorie.com>, Andrew Cagney <ac131313@cygnus.com>
Subject: Re: 000217: status of DJGPP support
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <Pine.LNX.4.10.10002201158010.1564-100000@propylaea.anduin.com>
References: <200002201017.FAA12081@indy.delorie.com>
X-SW-Source: 2000-q1/msg00353.html
Content-length: 1849

> 
>   - Does any other configuration use `select' rather than `poll'?  It
>     seems to me that the branch with `select' is broken; for starters,
>     fd_mask is not defined anywhere (GCC bails out with parse error
>     while compiling event-loop.c).  Does the distribution assume that
>     fd_mask is defined on some system header?  If so, I think it
>     should test for it, because I don't think it is a standard
>     definition.
> 

I have this problem on BeOS.
I can give you an fd_mask that will work.
Unfortunately, i had to disable the event loop based interface because
our select isn't good enough yet.

We don't have poll, neither.

> Alternatively, I could supply a
definition on xm-go32.h, for >     example.
> 
>     Btw, why doesn't the `select' branch use the standard fd_set type
>     and the FD_* macros instead of memset and memcpy?  Use of fd_set
>     and FD_* would remove the need in all that juggling with
>     bits-per-byte, MASK_SIZE, etc.  Is there any reason not to use
>     those?
> 
>   - The configure scripts cannot be run without some tricks, like
>     setting a few variables in the environment.  So I'm thinking about
>     adding a gdb/djgpp subdirectory with a special script that DJGPP
>     users will need to run (and which in turn will run the top-level
>     configure), and maybe a few small Sed scripts to fix file-name
>     related problems on 8+3 filesystems.  Is this acceptable?
> 
>   - What is the policy for fixing problems in the directories taken
>     from Binutils?  I'd imagine you want me to send patches to
>     Binutils maintainers, but with the next Binutils release nowhere
>     in sight, and some of my patches to Binutils in the queue since
>     August, is this really practical?  How can I make sure these
>     problems are fixed in GDB before GDB 5.0 is released?
>