Re: Linux sigtramp detection code moved to its proper place

[Eli Zaretskii <eliz@delorie.com>]

> *** 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 <eliz@delorie.com>
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> <jimb@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 <kevinb@cygnus.com>
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 */