From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eli Zaretskii To: jimb@zwingli.cygnus.com Cc: kevinb@cygnus.com, gdb-patches@sourceware.cygnus.com Subject: Re: Linux sigtramp detection code moved to its proper place Date: Sat, 18 Mar 2000 14:27:00 -0000 Message-id: <200003182227.RAA07058@indy.delorie.com> References: <200003162241.RAA19616@zwingli.cygnus.com> <1000316225504.ZM3009@ocotillo.lan> X-SW-Source: 2000-03/msg00334.html > *** gdb/Makefile.in 2000/03/16 10:23:38 1.13 > --- gdb/Makefile.in 2000/03/17 19:59:40 > *************** > *** 1063,1068 **** > --- 1063,1069 ---- > i386-tdep.c i386b-nat.c i386mach-nat.c i386v-nat.c i386-linux-nat.c \ > i386aix-nat.c i386m3-nat.c i386v4-nat.c i386ly-tdep.c \ > i387-tdep.c \ > + i386-linux-tdep.c \ > i960-tdep.c \ > infptrace.c inftarg.c irix4-nat.c irix5-nat.c isi-xdep.c \ > lynx-nat.c m3-nat.c \ I see you already added the new file. Sigh... Is it possible to find a different name for it, one which won't clash with i386-linux-nat.c? How about i386linux-tdep.c, for example? >From eliz@delorie.com Sat Mar 18 14:27:00 2000 From: Eli Zaretskii To: cgf@cygnus.com Cc: kettenis@wins.uva.nl, kevinb@cygnus.com, jimb@cygnus.com, gdb-patches@sourceware.cygnus.com Subject: Re: Linux sigtramp detection code moved to its proper place Date: Sat, 18 Mar 2000 14:27:00 -0000 Message-id: <200003182227.RAA07055@indy.delorie.com> References: <200003162241.RAA19616@zwingli.cygnus.com> <1000316225504.ZM3009@ocotillo.lan> <20000316180048.A30640@cygnus.com> <200003162311.e2GNBUH00362@delius.kettenis.local> <20000316193609.D30640@cygnus.com> X-SW-Source: 2000-03/msg00333.html Content-length: 1122 > I would be in favor of just creating an i386-linux-tdep.c and working > out the 8.3 issues later. Since there are already 8.3 issues in > the gdb source directory, adding one more is not going to aggravate > the problem unduly. I beg to disagree ;-). Let me explain why. What I intend to do to resolve the problem of file names clashing in the 8+3 namespace is to use the feature of DJTAR, an untar utility which comes with DJGPP, to rename files on the fly. To this end, I created a name-mapping file which specifies what files to rename and how; this file needs to be submitted to DJTAR when unpacking the distribution. I will make the file itself part of the distribution (so DJGPP users will need to unpack that special file first, and then the rest). I already spent a frustrating evening creating this name-mapping file; adding any new files that clash with existing files would require me to reproduce that file, possibly affecting other files as well. I respect the decision not to change any names before GDB 5.0 is released, but in the meantime could we please not add any new files whose names clash? >From kevinb@cygnus.com Sat Mar 18 14:30:00 2000 From: Kevin Buettner To: gdb-patches@sourceware.cygnus.com Subject: [PATCH RFA] symfile.c bounds check Date: Sat, 18 Mar 2000 14:30:00 -0000 Message-id: <1000318223035.ZM11861@ocotillo.lan> X-SW-Source: 2000-03/msg00335.html Content-length: 1202 I was seeing rather severe problems (gdb coredumps; test suite wouldn't run at all) on linux/ppc after my recent solib.c changes. The following patch fixes these problems. (Also, since this is happening, MAX_SECTIONS needs to be even bigger. We probably just ought to redesign struct section_addr_info so that it can be dynamically sized.) May I check this in? * symfile.c (syms_from_objfile): Added bounds check prior to accessing ``other'' array in a section_addr_info struct. Index: symfile.c =================================================================== RCS file: /cvs/src/src/gdb/symfile.c,v retrieving revision 1.2 diff -u -p -r1.2 symfile.c --- symfile.c 2000/03/15 19:43:57 1.2 +++ symfile.c 2000/03/18 22:18:53 @@ -738,7 +790,9 @@ syms_from_objfile (objfile, addrs, mainl else if (strcmp (s->the_bfd_section->name, ".bss") == 0) s_addr = addrs->bss_addr; else - for (i = 0; !s_addr && addrs->other[i].name; i++) + for (i = 0; + !s_addr && i < MAX_SECTIONS && addrs->other[i].name; + i++) if (strcmp (s->the_bfd_section->name, addrs->other[i].name) == 0) s_addr = addrs->other[i].addr; /* end added for gdb/13815 */