From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jim Kingdon To: Mark Mitchell Cc: gdb@sourceware.cygnus.com Subject: Re: Regressions problem (200 failures) Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: References: <20000301123337B.mitchell@codesourcery.com> X-SW-Source: 2000-q1/msg00486.html > I think GCC shouldn't put out any line notes for the prologue in the > first place. That's what's causing the problem, indirectly. Does GDB > require a line note in the prologue, or can we wait until the first > bit of real code? GDB expects the first line number to be for the real code (unless something has changed, or I'm remembering it wrong or something - I didn't actually play around with the test cases). >From aj@suse.de Sat Apr 01 00:00:00 2000 From: Andreas Jaeger To: shebs@shebs.cnchost.com Cc: gdb@sourceware.cygnus.com, linux390@de.ibm.com Subject: Re: GDB for S390 Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: References: <389CB0ED.755AD37C@shebs.cnchost.com> X-SW-Source: 2000-q1/msg00114.html Content-length: 769 >>>>> Stan Shebs writes: > Noticed this while surfing in strange corners of the web: > http://www.software.ibm.com/developerworks/opensource/linux390/download_src.html > Not only is there a port of Linux to IBM's 390 mainframes, > but the GCC and GDB patches are available! GDB patches > are against 4.18 and at first glance seem reasonable; we > should contact those guys and get them to donate... There're also glibc and binutils patches ;-). I hope that these will soon be integrated (so far the patches have only be added to the Linux 2.2 kernel) I'm CC'ing the linux390 developers - perhaps one of them can clarify the situation? Or just donate the port;-). Andreas -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.rhein-neckar.de >From kevinb@cygnus.com Sat Apr 01 00:00:00 2000 From: Kevin Buettner To: gdb@sourceware.cygnus.com Cc: Eric Bachalo , Franz Sirl , khendricks@admin.ivey.uwo.ca Subject: Linux/PPC support (was Re: Preparing for the GDB 5.0 ... release) Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <1000209051829.ZM2093@ocotillo.lan> References: <00020900262503.05214@enzo.bigblue.local> X-SW-Source: 2000-q1/msg00185.html Content-length: 1659 I am at least partially to blame for nothing happening with regard to getting the linux/ppc patches merged and committed to cvs. My excuse is that I've been assigned some challenging work that has sucked up all of my work time as well as much of my personal time. Earlier today, I spoke to my manager about this situation and I've gotten his agreement (I think) to spend a week getting linux/ppc support merged and committed. :-) Better still, the week in question is next week (2/14 thru 2/18, plus whatever I put in on the weekends). The reason for doing it next week as opposed to some other random week is that I'm in the midst of a two week stint of AIX work and it's better for me to do it now when I'm focused on the PPC and related architectures and have current (working) build trees for AIX. Plus, once committed, it'll give those of you who use linux/ppc on a daily basis a chance to put it through its paces before the next gdb release. When I did the gdb port for linux/ppc, I made a copy of rs6000-tdep.c and converted it to use the SysV ABI (along with some other linux specific details). At the time, this was the right decision since I didn't have access to an AIX machine to build and test on. Had I attempted to work directly in rs6000-tdep.c, I would almost certainly have broken the AIX port. But now the situation is a bit different and I think the right thing to do (maintenance-wise) is to merge linux/ppc support into rs6000-tdep.c and (partially/minimally) multi-arch the thing in the process. There will still be a separate ppclinux-nat.c file though. Okay? Kevin -- Kevin Buettner kev@primenet.com, kevinb@redhat.com >From kettenis@wins.uva.nl Sat Apr 01 00:00:00 2000 From: Mark Kettenis To: ac131313@cygnus.com Cc: aj@suse.de, gdb@sourceware.cygnus.com Subject: Re: core dump from GNU/Linux ; Was: Build failure on Linux/i686 Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <200002110736.e1B7afa00398@delius.kettenis.local> References: <200002101919.UAA23595@landau.wins.uva.nl> <38A353C3.DDD9A240@cygnus.com> X-SW-Source: 2000-q1/msg00219.html Content-length: 1144 Date: Fri, 11 Feb 2000 11:11:47 +1100 From: Andrew Cagney Mark Kettenis wrote: > This is the solution I proposed: > > http://sourceware.cygnus.com/ml/gdb-patches/2000-q1/msg00103.html > > Note that you'll need to patch too, otherwise GDB will > segfault when you try to debug a multithreaded app! Um, can you expand on this a little? (You may have already). The first version of glibc that includes the threads debugging library (libthread.so) will be 2.1.3, which has not been officially released yet. Since both Andreas and I are glibc developers we were among the first to test a GDB that makes use of that functionality apart from the people who actually implemented it. It looks as if Ulrich Drepper (the glibc maintainer) and Michael have let things go slighty out of sync. So without patches to both GDB and the glibc prereleases it won't work. If there is a header file found in a standard GNU/Linux distribution that can cause GDB to dump core we're going to need some sort of evasive action. Sigh. That's what I'm trying to prevent :-) Mark >From ac131313@cygnus.com Sat Apr 01 00:00:00 2000 From: Andrew Cagney To: GDB Discussion Cc: GDB Patches Subject: New file gdb/CONTRIBUTE guidelins for the contributor Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38A3780F.2FE7A510@cygnus.com> X-SW-Source: 2000-q1/msg00209.html Content-length: 4972 Hello, I'd like to put the attatched file forward as an addition to the other readme files in the GDB directory. Originally I was going to include this in the MAINTAINERS file but decided that a separate file was probably of more benefit and more likely to be noticed. In terms of content, this really is a direct lift of GCC's how-to-contribute page. The one problem I can see at present is that the notes don't clearly differentiate between GDB (src/gdb) and BINUTILS (src/bfd, src/include). Andrew Contributing to GDB [much of this is lifted from the GCC page] We strongly encourage contributions of code, bugfixes, new optimizations, new features, documentation updates, tests, web page improvements, etc. for GDB. There are certain legal requirements and style issues which all contributions must meet. o Coding Standards All contributions must conform to the GNU Coding Standard. http://www.gnu.ai.mit.edu/prep/standards_toc.html Submissions which do not conform to the standards will be returned with a request to reformat the changes. For GDB, that standard is more tightly defined. GDB's coding standard is determined by the output of gnu-indent. This situation came about because, by the start of '99, GDB's coding style was so bad an inconsistent that it was decided to restart things from scratch. o Copyright Assignment There are certain legal requirements Before we can accept code contributions from you, we need a copyright assignment form filled out. If you've developed some addition or patch to GDB that you would like to contribute, you should fill out a copyright assignment form and send it in to the FSF. We are unable to use code from you until this is on-file at the FSF, so get that paperwork in! This form covers one batch of changes. Ref: http://gcc.gnu.org/fsf-forms/assignment-instructions.html If you think you're going to be doing continuing work on GDB, it would be easier to use a different form, which arranges to assign the copyright for all your future changes to GDB. It is called assign.future. Please note that if you switch employers, the new employer will need to fill out the disclaim.future form; there is no need to fill out the assign.future form again. Ref: http://gcc.gnu.org/fsf-forms/assign.future Ref: http://gcc.gnu.org/fsf-forms/disclaim.future There are several other forms you can fill out for different circumstances (e.g. to contribute an entirely new program, to contribute significant changes to a manual, etc.) Ref: http://gcc.gnu.org/fsf-forms/copyrights.html Small changes can be accepted without a copyright assignment form on file. This is pretty confusing! If you are unsure of what is necessary, just ask the GCC mailing list and we'll figure out what is best for you. Note: Many of these forms have a place for "name of program". Insert the name of one program in that place -- in this case, "GDB". o Submitting Patches Every patch must have several pieces of information before we can properly evaluate it. A description of the bug and how your patch fixes this bug. A reference to a testsuite failure is very helpful. For new features a description of the feature and your implementation. A ChangeLog entry as plaintext (separate from the patch); see the various ChangeLog files for format and content. Note that, unlike some other projects, we do require ChangeLogs also for documentation (i.e., .texi files). The patch itself. If you are accessing the CVS repository at: Cygnus, use "cvs update; cvs diff -c3p"; else, use "diff -c3p OLD NEW" or "diff -up OLD NEW". If your version of diff does not support these options, then get the latest version of GNU diff. We accept patches as plain text (preferred for the compilers themselves), MIME attachments (preferred for the web pages), or as uuencoded gzipped text. When you have all these pieces, bundle them up in a mail message and send it to gdb-patches@sourceware.cygnus.com. All patches and related discussion should be sent to the gcc-patches mailinglist. For further information on the GDB CVS repository, see the Anonymous read-only CVS access and Read-write CVS access page. -- Supplemental information for GDB: o Please try to run the relevant testsuite before and after committing a patch If the contributor doesn't do it then the maintainer will. A contributor might include before/after test results in their contribution. o For bug fixes, please try to include a way of demonstrating that the patch actually fixes something. The best way of doing this is to ensure that the testsuite contains one or more test cases that fail without the fix but pass with the fix. People are encouraged to submit patches that extend the testsuite. o Please read your patch before submitting it. A patch containing several unrelated changes or arbitrary reformats will be returned with a request to re-formatting / split it.