From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cagney To: Jim Blandy Cc: gdb@sourceware.cygnus.com Subject: Re: Try out the patch database Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38BCCE9E.206DE44@cygnus.com> References: <200002292134.QAA10095@zwingli.cygnus.com> X-SW-Source: 2000-q1/msg00465.html 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 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: 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 To: Eli Zaretskii Cc: gdb@sourceware.cygnus.com, DJ Delorie , Andrew Cagney Subject: Re: 000217: status of DJGPP support Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: 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? >