* Re: Linux sigtramp detection code moved to its proper place
[not found] ` <npsnxp8ix6.fsf@zwingli.cygnus.com>
@ 2000-03-18 14:27 ` Eli Zaretskii
2000-04-01 0:00 ` Mark Kettenis
0 siblings, 1 reply; 3+ messages in thread
From: Eli Zaretskii @ 2000-03-18 14:27 UTC (permalink / raw)
To: jimb; +Cc: kevinb, gdb-patches
> *** 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 */
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Linux sigtramp detection code moved to its proper place
2000-03-18 14:27 ` Linux sigtramp detection code moved to its proper place Eli Zaretskii
@ 2000-04-01 0:00 ` Mark Kettenis
0 siblings, 0 replies; 3+ messages in thread
From: Mark Kettenis @ 2000-04-01 0:00 UTC (permalink / raw)
To: eliz; +Cc: jimb, kevinb, gdb-patches
Date: Sat, 18 Mar 2000 17:27:44 -0500 (EST)
From: 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?
Yuck, that's ugly!
Is it really important that these Linux-specific files are correctly
extracted on MS-DOS? I believe your argument was about buggy tar
programs floating around, but I don't think it is too much too ask
people to fix their tar before trying to build GDB.
Mark
From fnasser@cygnus.com Sat Apr 01 00:00:00 2000
From: Fernando Nasser <fnasser@cygnus.com>
To: jtc@redback.com
Cc: GDB Patches <gdb-patches@sourceware.cygnus.com>
Subject: Re: Deprecating commands; Was: RFC: patch for ...
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38AAFCB4.EFC20163@cygnus.com>
References: <38AA23AF.34D2C08B@cygnus.com> <38AAE434.E3B21500@cygnus.com> <5memad2bsw.fsf@jtc.redbacknetworks.com>
X-SW-Source: 2000-q1/msg00200.html
Content-length: 1745
"J.T. Conklin" wrote:
>
> >>>>> "Fernando" == Fernando Nasser <fnasser@cygnus.com> writes:
> Fernando> Talking about "bad" commands, what can be worse that the
> Fernando> "set" overloading? It should only work for gdb control
> Fernando> switches. The "set var" should be name "assign". But who
> Fernando> dares to change this after 15+ years...
>
> If we were to have a different command for setting variables, I'd pick
> "write" over "assign". However I see this in much the same way as the
> BASIC "LET" keyword --- a useless bit of syntactic sugar. I'd prefer
> being able to set program variables directly:
>
> (gdb) print x
> $1 = 3
> (gdb) x = 4
>
Sure, but on the other hand not having the "set"/"let"/"assign"/"write"
or whatever keyord starts to impose restrictions on variable names. You
end up with a reserved keyword list that is the union of all languages
supported by gdb.
> but I suspect that would require a major overhaul of the command
> parser.
>
Yes, it probably would.
> Another issue is that "set" is used to assign convienence variables
> and GDB's internal variables. I see some merit in actually merging
> these so that scripts can access the values. There are some issues
> that may make it difficult to do. For example, many set commands do
> extra error checking that simply setting a convienence variable would
> not; GBD's scripting language has only a global identifier namespace;
> etc. Nevertheless, I'd love to be able to do this.
>
Good points.
--
Fernando Nasser
Red Hat - Toronto E-Mail: fnasser@cygnus.com
2323 Yonge Street, Suite #300 Tel: 416-482-2661 ext. 311
Toronto, Ontario M4P 2C9 Fax: 416-482-6299
From eliz@delorie.com Sat Apr 01 00:00:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: kettenis@wins.uva.nl
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: [PATCH]: DJGPP build and cleanup
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200002241118.GAA19392@indy.delorie.com>
References: <200002232229.RAA18809@indy.delorie.com> <200002232247.e1NMljJ28359@delius.kettenis.local>
X-SW-Source: 2000-q1/msg00357.html
Content-length: 2026
> From: Mark Kettenis <kettenis@wins.uva.nl>
>
> Date: Wed, 23 Feb 2000 17:29:16 -0500 (EST)
> From: Eli Zaretskii <eliz@delorie.com>
>
> The change to i386-tdep.c should probably be approved by someone (I
> cannot figure out from MAINTAINERS who's responsible for i386
> targets).
>
> Youd didn't include the changes to i386-tdep.c :-(.
I erroneously appended them to the other set of patches I sent
yesterday. I attach it below again.
> The point is that if you look at the GCC configuration files, you'll
> see that returning FP values in the FP registers is the default for
> most (probably all) i386 targets. So I think this should be the
> default in GDB too.
I didn't know that this was the case, but if it is so, I agree that
returning FP values in registers should be the default.
2000-02-23 Eli Zaretskii <eliz@is.elta.co.il>
* i386-tdep.c (i386_extract_return_value)
[I386_AIX_TARGET || I386_GNULINUX_TARGET]: Add I386_DJGPP_TARGET
to the list of targets which return FP values in FP registers.
--- gdb/i386-tdep.c~0 Tue Oct 19 02:46:36 1999
+++ gdb/i386-tdep.c Wed Feb 23 12:17:20 2000
@@ -702,9 +702,9 @@ i386_extract_return_value (type, regbuf,
char regbuf[REGISTER_BYTES];
char *valbuf;
{
- /* On AIX and i386 GNU/Linux, floating point values are returned in
- floating point registers. */
-#if defined(I386_AIX_TARGET) || defined(I386_GNULINUX_TARGET)
+ /* On AIX, i386 GNU/Linux and DJGPP, floating point values are
+ returned in floating point registers. */
+#if defined(I386_AIX_TARGET) || defined(I386_GNULINUX_TARGET) || defined(I386_DJGPP_TARGET)
if (TYPE_CODE_FLT == TYPE_CODE (type))
{
double d;
@@ -720,7 +720,7 @@ i386_extract_return_value (type, regbuf,
store_floating (valbuf, TYPE_LENGTH (type), d);
}
else
-#endif /* I386_AIX_TARGET || I386_GNULINUX_TARGET*/
+#endif /* I386_AIX_TARGET || I386_GNULINUX_TARGET || I386_DJGPP_TARGET */
{
#if defined(LOW_RETURN_REGNUM)
int len = TYPE_LENGTH (type);
From eliz@delorie.com Sat Apr 01 00:00:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: Peter.Schauer@regent.e-technik.tu-muenchen.de
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: RFA: breakpoint.c: Minor output fixes for hardware watchpoints
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200003091337.IAA19948@indy.delorie.com>
References: <200003072114.WAA26280@reisser.regent.e-technik.tu-muenchen.de>
X-SW-Source: 2000-q1/msg00618.html
Content-length: 884
> During implementation of hardware watchpoints on Solaris, I noticed the
> following inconsistencies in breakpoint.c output between software and
> hardware breakpoints.
Both problems confirmed on x86 using the DJGPP native version.
Actually, these two problems were on my todo list since last summer,
but since they are merely annoyances, they got pushed back ;-).
> Here is a patch for both problems:
>
> 2000-03-07 Peter Schauer <pes@regent.e-technik.tu-muenchen.de>
>
> * breakpoint.c (insert_breakpoints, do_enable_breakpoint): Reselect
> the saved frame silently after frame selection for watchpoint
> evaluation.
> (insert_breakpoints): Add missing space in `Hardware watchpoint
> deleted' message. Do not reinsert hardware watchpoint if it is
> already marked for deletion at next stop.
Both problems are gone with these patches in the DJGPP version.
Thanks!
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Fernando Nasser <fnasser@cygnus.com>
Cc: Scott Bambrough <scottb@netwinder.org>, gdb-patches@sourceware.cygnus.com, jingham@cygnus.com
Subject: Re: Patch for arm_push_arguments
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38CEDC1A.7D997EF3@cygnus.com>
References: <38CE9C8B.3EC5B7F1@netwinder.org> <38CEA1FF.CEA9553@cygnus.com>
X-SW-Source: 2000-q1/msg00699.html
Content-length: 972
Fernando Nasser wrote:
>
> Scott,
>
> I have to try it on a few targets, so I need a few days. I will try to run all the tests this week though.
>
> Thanks for doing this.
>
> Fernando
>
> Scott Bambrough wrote:
> >
> > Hi guys,
> >
> > * arm-tdep.c (arm_push_arguments): Correctly code for converting a
> > float argument from host format to a target double when preparing the
> > call frame for a function.
> >
> > This works for me. Can you try it out. If it works, let me know and I'll check
> > it in.
> >
> > Scott
> >
Scott,
To expand on what I suspect Fernando is doing, he probably has built a
``--target=arm-elf'' tool-chain (compiler, linker, debugger) and is then
testing it a dejagnu entry like:
{ "arm-*elf" } {
set target_list "arm-sim/-mlittle-endian"
}
(along with a few extra's for remote boards). This checks both big and
little endian targets without any need to own real hardware.
enjoy,
Andrew
From msnyder@cygnus.com Sat Apr 01 00:00:00 2000
From: Michael Snyder <msnyder@cygnus.com>
To: dan@cgsoftware.com
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: [RFA] Demangled minsym hash table broken
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38E2A65B.7C32@cygnus.com>
References: <pusd46y7.fsf@dan.resnet.rochester.edu>
X-SW-Source: 2000-q1/msg01116.html
Content-length: 186
Daniel Berlin wrote:
> So up until now, the demangled symbol table was never working, as i
> had suspected.
Well, that is, since the addition of the hash table
(I'm sure you meant)...
From kevinb@cygnus.com Sat Apr 01 00:00:00 2000
From: Kevin Buettner <kevinb@cygnus.com>
To: shebs@apple.com
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: [PATCH RFA] testsuite changes needed for AIX 4.3
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <1000216021706.ZM2429@ocotillo.lan>
References: <1000215230816.ZM2175@ocotillo.lan> <38A9E4F9.514007E1@apple.com> <shebs@apple.com>
X-SW-Source: 2000-q1/msg00165.html
Content-length: 1514
On Feb 15, 3:44pm, Stan Shebs wrote:
> Kevin Buettner wrote:
> >
> > I hereby reqest approval for committing the following changes:
> >
> > * gdb.base/pointers.c (usevar): New function.
> > (main): Make sure that global variables v_int_pointer2, rptr,
> > and y are all referenced someplace in the program by calling
> > usevar() on them. [Some linkers delete symbols which are
> > never referenced. The space remains, but there's no way to
> > get a (symbolic) handle on the variable from the debugger.]
> >
> > * gdb.base/scope.exp: For powerpc-*-*, xfail the same tests
> > that rs6000-*-* does.
>
> This looks reasonable to me, with the same question as Mark Kettenis
> raises: are the xfails unconditional because the tests fail whether
> xlc or gcc is used as the compiler? If they pass with xlc, then you
> need to test gcc_compiled.
Okay. As soon as I get the rest of my patches from the branch I was
working on merged in, I was going to do a build from sourceware. I'll
test with xlc then. (The machine that I had been working on didn't
have xlc on it, or if it did, I couldn't find it.)
Also, I'd appreciate it if someone could explain to me why these
xfails are necessary. (I haven't looked hard at the problem; I
just noticed that these tests were xfailed for rs6000, and I was
getting FAILs on powerpc, so it seemed reasonable to xfail them
for powerpc too.)
Kevin
--
Kevin Buettner
kev@primenet.com, kevinb@redhat.com
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Jimmy Guo <guo@cup.hp.com>
Cc: Michael Snyder <msnyder@cygnus.com>, John David Anglin <dave@hiauly1.hia.nrc.ca>, gdb-patches@sourceware.cygnus.com
Subject: Re: Initialization of hpux_threads
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38D7F9C4.ECF7E17F@cygnus.com>
References: <Pine.LNX.4.10.10003211208350.31096-100000@hpcll168.cup.hp.com>
X-SW-Source: 2000-q1/msg00879.html
Content-length: 1706
Jimmy Guo wrote:
>
> On Fri, 17 Mar 2000, Michael Snyder wrote:
>
> >John David Anglin wrote:
> >>
> >> Thu Mar 16 16:49:27 EST 2000 John David Anglin <dave@hiauly1.hia.nrc.ca>
> >>
> >> * configure.in: Don't call _initialize_hpux_thread twice.
> >> * configure: Regenerated.
> >>
> >> --- configure.in.orig Mon Mar 6 18:30:12 2000
> >> +++ configure.in Thu Mar 16 14:22:26 2000
> >> @@ -330,7 +330,6 @@
> >> AC_DEFINE(HAVE_HPUX_THREAD_SUPPORT)
> >> CONFIG_OBS="${CONFIG_OJS} hpux-thread.o"
> >> CONFIG_SRCS="${CONFIG_SRCS} hpux-thread.c"
> >> - CONFIG_INITS="${CONFIG_INITS} hpux-thread.c"
> >> else
> >> AC_MSG_RESULT(no (suppressed because you are not using GCC))
> >> fi
> >
> >If someone from HP will approve this, I will check it in...
> >
> > Michael Snyder
>
> This looks fine. Just an observation:
> CONFIG_OBS is part of DEPFILES, which is part of COMMON_OBS, which is
> part of OBS, which is part of INITFILES. It looks like all three usages
> of CONFIG_INITS in configure.in can be removed. Maybe you can just
> remove CONFIG_INITS altogether in configure.in and Makefile.in. Since
> OBS file list is already looked at by init.c rule, it really makes no
> sense to maintain a CONFIG_INITS file list.
No. CONFIG_INITS was added because things get complicated when adding
sub-directory files (eg MI) that contain _initialize_*() functions. The
mistake was to assume that it was needed in all (rather than special)
cases.
By doing this the MI avoided the need to add any nasty initialization
hooks to main() - unlike tui, MPW, and GDBTK.
Andrew
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Stan Shebs <shebs@apple.com>
Cc: Michael Snyder <msnyder@cygnus.com>, gdb-patches@sourceware.cygnus.com
Subject: Re: gdb.texinfo broken?
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38D7FDD1.D54DE1D8@cygnus.com>
References: <38D6CF69.6844@cygnus.com> <200003211819.NAA12435@indy.delorie.com> <38D7C977.FA3@cygnus.com> <5mitygglxs.fsf@jtc.redbacknetworks.com>
X-SW-Source: 2000-q1/msg00882.html
Content-length: 325
"J.T. Conklin" wrote:
> It looks like the changes to the directory entry require the latest
> makeinfo. I tried to use makeinfo from texinfo-3.2 and it failed,
> makeinfo from texinfo-4.0 works.
From memory, the possibility of requiring texinfo 4.0 as part of
building GDB 5 was considered and rejected :-(
oops,
Andrew
From scottb@netwinder.org Sat Apr 01 00:00:00 2000
From: Scott Bambrough <scottb@netwinder.org>
To: Michael Snyder <msnyder@cygnus.com>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: store_floating() and arm-tdep.c
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38C917C1.3E6E2C19@netwinder.org>
References: <1000229000345.ZM15006@ocotillo.lan> <38BCE46B.CD7889B5@cygnus.com> <1000302074643.ZM19182@ocotillo.lan> <38C7BF53.731F8CF6@redhat.com> <38C7C9A4.3566EC87@netwinder.org> <38C7F23D.61AF@cygnus.com>
X-SW-Source: 2000-q1/msg00642.html
Content-length: 1429
> Scott Bambrough wrote:
> >
> > I've been running tests on the ARM Linux target on a NetWinder regularly. The
> > results of the testsuite follow. Most of the problems are due to no
> > linuxthreads support and problems stepping in/out or backtracing in signal
> > handlers. I'll work at implementing support for these over time. I was hoping
> > to port the x86 work, but just haven't had the time.
>
Michael Snyder wrote:
>
> Hmm, the new thread_db module should be pretty
> target-independent (correct me if I'm wrong).
Ok. I attempted to put the linuxthreads support in last night. It was
relatively painless, but I have reached a stumbling block with glibc 2.1.2. In
gdb_proc_service.h there are the following two definitions:
#ifndef HAVE_PRGREGSET_T
typedef gregset_t prgregset_t; /* BOGUS BOGUS BOGUS */
#endif
#ifndef HAVE_PRFPREGSET_T
typedef fpregset_t prfpregset_t; /* BOGUS BOGUS BOGUS */
#endif
The BOGUS comments are accurate. Neither gregset_t or fpregset_t are defined in
<sys/procfs.h>. prgregset_t and prfpregset_t are also used in gdb_threads_db.h
as well without checking the defines from config.h. I'm trying this on 2.1.3
ATM, but for the most part, the installed base of users is using 2.1.2 on ARM
Linux. Any thoughts on how I could get around this?
Scott
--
Scott Bambrough - Software Engineer
REBEL.COM http://www.rebel.com
NetWinder http://www.netwinder.org
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: GDB Patches <gdb-patches@sourceware.cygnus.com>
Subject: [PATCH] gdbarch cleanups part 1
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38E2E686.2227D8F9@cygnus.com>
X-SW-Source: 2000-q1/msg01122.html
Content-length: 5983
FYI,
I committed the attatched cleanups.
Andrew
\x03
Thu Mar 30 12:09:50 2000 Andrew Cagney <cagney@b1.cygnus.com>
* gdbarch.h, gdbarch.c: Re-indent. Remove FIXMEs.
* gdbarch.sh: Re-sync with gdbarch.[hc].
Index: gdbarch.sh
===================================================================
RCS file: /cvs/src/src/gdb/gdbarch.sh,v
retrieving revision 1.5
diff -p -r1.5 gdbarch.sh
*** gdbarch.sh 2000/03/21 20:40:43 1.5
--- gdbarch.sh 2000/03/30 05:31:15
***************
*** 1,7 ****
#!/usr/local/bin/bash
# Architecture commands for GDB, the GNU debugger.
! # Copyright 1998-1999 Free Software Foundation, Inc.
#
# This file is part of GDB.
#
--- 1,7 ----
#!/usr/local/bin/bash
# Architecture commands for GDB, the GNU debugger.
! # Copyright 1998-2000 Free Software Foundation, Inc.
#
# This file is part of GDB.
#
***************
*** 19,24 ****
--- 19,40 ----
# along with this program; if not, write to the Free Software
# Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ compare_new ()
+ {
+ file=$1
+ if ! test -r ${file}
+ then
+ echo "${file} missing? cp new-${file} ${file}" 1>&2
+ elif diff -c ${file} new-${file}
+ then
+ echo "${file} unchanged" 1>&2
+ else
+ echo "${file} has changed? cp new-${file} ${file}" 1>&2
+ fi
+ }
+
+
+ # Format of the input table
read="class level macro returntype function formal actual attrib default init invalid_p fmt print print_p description"
# dump out/verify the doco
*************** fi
*** 259,264 ****
--- 275,282 ----
copyright ()
{
cat <<EOF
+ /* *INDENT-OFF* */ /* THIS FILE IS GENERATED */
+
/* Dynamic architecture support for GDB, the GNU debugger.
Copyright 1998-1999, Free Software Foundation, Inc.
*************** cat <<EOF
*** 279,286 ****
Foundation, Inc., 59 Temple Place - Suite 330,
Boston, MA 02111-1307, USA. */
- /* *INDENT-OFF* */ /* \`\`typedef (f)();'' confuses indent */
-
/* This file was created with the aid of \`\`gdbarch.sh''.
The bourn shell script \`\`gdbarch.sh'' creates the files
--- 297,302 ----
*************** extern void gdbarch_dump (void);
*** 742,756 ****
EOF
exec 1>&2
#../move-if-change new-gdbarch.h gdbarch.h
! if ! test -r gdbarch.h
! then
! echo "gdbarch.h missing? cp new-gdbarch.h gdbarch.h" 1>&2
! elif diff -c gdbarch.h new-gdbarch.h
! then
! echo "gdbarch.h unchanged" 1>&2
! else
! echo "gdbarch.h has changed? cp new-gdbarch.h gdbarch.h" 1>&2
! fi
#
--- 758,764 ----
EOF
exec 1>&2
#../move-if-change new-gdbarch.h gdbarch.h
! compare_new gdbarch.h
#
*************** struct gdbarch_tdep *
*** 1076,1082 ****
gdbarch_tdep (struct gdbarch *gdbarch)
{
if (gdbarch_debug >= 2)
- /* FIXME: gdb_std??? */
fprintf_unfiltered (gdb_stdlog, "gdbarch_tdep called\n");
return gdbarch->tdep;
}
--- 1084,1089 ----
*************** do
*** 1098,1104 ****
echo " if (gdbarch->${function} == 0)"
echo " internal_error (\"gdbarch: gdbarch_${function} invalid\");"
echo " if (gdbarch_debug >= 2)"
- echo " /* FIXME: gdb_std??? */"
echo " fprintf_unfiltered (gdb_stdlog, \"gdbarch_${function} called\n\");"
test "${actual}" = "-" && actual=""
if [ "${returntype}" = "void" ]
--- 1105,1110 ----
*************** do
*** 1131,1137 ****
echo " internal_error (\"gdbarch: gdbarch_${function} invalid\");"
fi
echo " if (gdbarch_debug >= 2)"
- echo " /* FIXME: gdb_std??? */"
echo " fprintf_unfiltered (gdb_stdlog, \"gdbarch_${function} called\n\");"
echo " return gdbarch->${function};"
echo "}"
--- 1137,1142 ----
*************** do
*** 1149,1155 ****
echo "gdbarch_${function} (struct gdbarch *gdbarch)"
echo "{"
echo " if (gdbarch_debug >= 2)"
- echo " /* FIXME: gdb_std??? */"
echo " fprintf_unfiltered (gdb_stdlog, \"gdbarch_${function} called\n\");"
echo " return gdbarch->${function};"
echo "}"
--- 1154,1159 ----
*************** extern void _initialize_gdbarch (void);
*** 1965,1970 ****
--- 1969,1976 ----
void
_initialize_gdbarch ()
{
+ struct cmd_list_element *c;
+
add_prefix_cmd ("endian", class_support, set_endian,
"Set endianness of target.",
&endianlist, "set endian ", 0, &setlist);
*************** _initialize_gdbarch ()
*** 1991,2015 ****
tm_print_insn_info.memory_error_func = dis_asm_memory_error;
tm_print_insn_info.print_address_func = dis_asm_print_address;
! add_show_from_set (add_set_cmd ("archdebug",
class_maintenance,
var_zinteger,
(char *)&gdbarch_debug,
"Set architecture debugging.\n\\
! When non-zero, architecture debugging is enabled.", &setlist),
! &showlist);
}
EOF
# close things off
exec 1>&2
#../move-if-change new-gdbarch.c gdbarch.c
! if ! test -r gdbarch.c
! then
! echo "gdbarch.c missing? cp new-gdbarch.c gdbarch.c" 1>&2
! elif diff -c gdbarch.c new-gdbarch.c
! then
! echo "gdbarch.c unchanged" 1>&2
! else
! echo "gdbarch.c has changed? cp new-gdbarch.c gdbarch.c" 1>&2
! fi
--- 1997,2022 ----
tm_print_insn_info.memory_error_func = dis_asm_memory_error;
tm_print_insn_info.print_address_func = dis_asm_print_address;
! add_show_from_set (add_set_cmd ("arch",
class_maintenance,
var_zinteger,
(char *)&gdbarch_debug,
"Set architecture debugging.\n\\
! When non-zero, architecture debugging is enabled.", &setdebuglist),
! &showdebuglist);
! c = add_set_cmd ("archdebug",
! class_maintenance,
! var_zinteger,
! (char *)&gdbarch_debug,
! "Set architecture debugging.\n\\
! When non-zero, architecture debugging is enabled.", &setlist);
!
! deprecate_cmd (c, "set debug arch");
! deprecate_cmd (add_show_from_set (c, &showlist), "show debug arch");
}
EOF
# close things off
exec 1>&2
#../move-if-change new-gdbarch.c gdbarch.c
! compare_new gdbarch.c
From msnyder@cygnus.com Sat Apr 01 00:00:00 2000
From: msnyder@cygnus.com
To: gdb-patches@sourceware.cygnus.com
Cc: cagney@cygnus.com, fnasser@cygnus.com
Subject: [PATCH]: swat a warning in cli-out.c
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200003240110.RAA21711@seadog.cygnus.com>
X-SW-Source: 2000-q1/msg00960.html
Content-length: 1137
This eliminates a warning on 64-bit solaris.
2000-03-23 Michael Snyder <msnyder@seadog.cygnus.com>
* cli-out.h: include gdb_string.h to avoid compiler warnings.
Index: ChangeLog
===================================================================
RCS file: /cvs/src/src/gdb/ChangeLog,v
retrieving revision 1.170
diff -c -r1.170 ChangeLog
*** ChangeLog 2000/03/23 23:43:19 1.170
--- ChangeLog 2000/03/24 01:08:15
***************
*** 1,3 ****
--- 1,7 ----
+ 2000-03-23 Michael Snyder <msnyder@seadog.cygnus.com>
+
+ * cli-out.h: include gdb_string.h to avoid compiler warnings.
+
2000-03-23 Fernando Nasser <fnasser@cygnus.com>
From David Whedon <dwhedon@gordian.com>
Index: cli-out.c
===================================================================
RCS file: /cvs/src/src/gdb/cli-out.c,v
retrieving revision 1.2
diff -c -r1.2 cli-out.c
*** cli-out.c 2000/02/20 18:23:31 1.2
--- cli-out.c 2000/03/24 01:08:15
***************
*** 23,28 ****
--- 23,29 ----
#include "defs.h"
#include "ui-out.h"
#include "cli-out.h"
+ #include "gdb_string.h"
/* Convenience macro for allocting typesafe memory. */
From ezannoni@cygnus.com Sat Apr 01 00:00:00 2000
From: Elena Zannoni <ezannoni@cygnus.com>
To: gdb-patches@sourceware.cygnus.com
Subject: PATCH corefiles reading on alpha-linux
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <14526.63171.337788.889969@kwikemart.cygnus.com>
X-SW-Source: 2000-q1/msg00461.html
Content-length: 1733
gdb/config/alpha/alpha-linux.mh lists core-regset.o as one of
the NATDEPFILES.
This causes _initialize_core_regset() to be called, and this in turn
calls add_core_fns with bfd_target_elf_flavour.
Later on, _initialize_core_alpha() adds another core function
structure with the same flavour. When a core file is loaded, this
causes a warning to be printed, because both function sets match the
expected bfd flavour.
I am going to check this in. OK?
Elena
Index: alpha-linux.mh
===================================================================
RCS file: /cvs/src/src/gdb/config/alpha/alpha-linux.mh,v
retrieving revision 1.1.1.3
diff -c -r1.1.1.3 alpha-linux.mh
*** alpha-linux.mh 1999/12/22 21:45:12 1.1.1.3
--- alpha-linux.mh 2000/03/02 23:15:59
***************
*** 2,8 ****
XDEPFILES= ser-tcp.o
XM_FILE= xm-alphalinux.h
NAT_FILE= nm-linux.h
! NATDEPFILES= infptrace.o inftarg.o corelow.o core-regset.o alpha-nat.o \
fork-child.o solib.o linux-thread.o lin-thread.o
LOADLIBES = -ldl -rdynamic
--- 2,8 ----
XDEPFILES= ser-tcp.o
XM_FILE= xm-alphalinux.h
NAT_FILE= nm-linux.h
! NATDEPFILES= infptrace.o inftarg.o corelow.o alpha-nat.o \
fork-child.o solib.o linux-thread.o lin-thread.o
LOADLIBES = -ldl -rdynamic
Index: ChangeLog
===================================================================
RCS file: /cvs/src/src/gdb/ChangeLog,v
retrieving revision 1.95
diff -c -r1.95 ChangeLog
*** ChangeLog 2000/03/02 15:44:27 1.95
--- ChangeLog 2000/03/02 23:17:32
***************
*** 1,3 ****
--- 1,8 ----
+ 2000-03-02 Elena Zannoni <ezannoni@kwikemart.cygnus.com>
+
+ * config/alpha/alpha-linux.mh: Remove core-regset.o fron the
+ NATDEPFILES list.
+
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Linux sigtramp detection code moved to its proper place
[not found] ` <200003182227.RAA07055@indy.delorie.com>
@ 2000-04-01 0:00 ` Chris Faylor
0 siblings, 0 replies; 3+ messages in thread
From: Chris Faylor @ 2000-04-01 0:00 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: kettenis, kevinb, jimb, gdb-patches
On Sat, Mar 18, 2000 at 05:27:17PM -0500, Eli Zaretskii wrote:
>
>> 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?
I am sympathetic to the plight of DOS users but this sounds like it is
something that could, in the short term, be handled by a program or perl
script fairly easily. If you actually have a solution for DOS, then
maybe that file or script should be part of the distribution and we
should not have to worry about this severe filename limitation.
IMO, in the long-term intelligent use of subdirectories should reduce
the size of all of the filenames.
cgf
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Fernando Nasser <fnasser@redhat.com>
Cc: Scott Bambrough <scottb@netwinder.org>, GDB Patches Mail List <gdb-patches@sourceware.cygnus.com>
Subject: Re: Patch fallen through the cracks?
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38C7C1C8.C4A8796A@cygnus.com>
References: <38C7ADD4.A6697C36@netwinder.org> <38C7BD11.9A8188CF@redhat.com>
X-SW-Source: 2000-q1/msg00624.html
Content-length: 692
Fernando Nasser wrote:
>
> Scott Bambrough wrote:
> >
> > Can someone approve this patch please. It shouldn't be a problem.
> >
> > http://sourceware.cygnus.com/ml/gdb-patches/2000-q1/msg00367.html
> >
>
> I would rather have it xfail'ed. It means that we know this test won't
> work on this platform but it is not ding what we want (this is what pass
> would mean).
I thought the patch was basically correct - the arm has that brain dead
wacko swapped double format.
The only suggestion I've had made would be to test a more generic
attribute indicating the exact format of a double V long rather than
test the arm target. Other platforms can have the same problem.
enjoy,
Andrew
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Mark Kettenis <kettenis@wins.uva.nl>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: [PATCH] Fix for target.c:do_target_signal_to_host()
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38A90F10.E61AF586@cygnus.com>
References: <200002142116.e1ELGrL06391@delius.kettenis.local>
X-SW-Source: 2000-q1/msg00153.html
Content-length: 1447
Mark Kettenis wrote:
>
> Hi,
>
> I noticed that under Linux, if I send a RT signal N to the program I'm
> debugging, GDB actually sends signal N - 1, e.g. if you continue with
>
> signal SIG35
>
> GDB will tell you that the program terminated with SIG34.
>
> The appended patch fixes this.
If you add a comment noting that:
o TARGET_SIGNAL_REALTIME_32 isn't
contigious with TARGET_SIGNAL_REALTIME_32
o TARGET_SIGNAL_REALTIME_33 is 33 by defintion.
then it can go straight in.
Andrew
>
> Mark
>
> 2000-02-14 Mark Kettenis <kettenis@gnu.org>
>
> * target.c (do_target_signal_to_host): Do not use REALTIME_LO in
> the conversion of the signal number. TARGET_SIGNAL_REALTIME_33 is
> 33 by definition, whereas REALTIME_LO might be 32 on systems that
> have SIG32 such as Linux.
>
> Index: gdb/target.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/target.c,v
> retrieving revision 1.2
> diff -u -r1.2 target.c
> --- gdb/target.c 2000/02/09 08:52:47 1.2
> +++ gdb/target.c 2000/02/14 21:09:27
> @@ -2061,7 +2061,7 @@
> && oursig <= TARGET_SIGNAL_REALTIME_63)
> {
> int retsig =
> - (int) oursig - (int) TARGET_SIGNAL_REALTIME_33 + REALTIME_LO;
> + (int) oursig - (int) TARGET_SIGNAL_REALTIME_33 + 33;
> if (retsig < REALTIME_HI)
> return retsig;
> }
From jimb@zwingli.cygnus.com Sat Apr 01 00:00:00 2000
From: Jim Blandy <jimb@zwingli.cygnus.com>
To: Tom Tromey <tromey@cygnus.com>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: Patch: hash tables for msymbols
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <npzosbejsi.fsf@zwingli.cygnus.com>
References: <87aeowo9jq.fsf@cygnus.com> <npr9drfz3b.fsf@zwingli.cygnus.com> <200003032252.OAA01491@ferrule.cygnus.com>
X-SW-Source: 2000-q1/msg00550.html
Content-length: 262
> I don't have write permission for gdb on sourceware. Nor do I want it
> right now. My gdb hacking time was a one-time-only fluke (more or
> less).
Oops. I'll commit it then. I'll look over Keith's fix, too. (I
thought everything was initialized, but...)
From jlarmour@redhat.co.uk Sat Apr 01 00:00:00 2000
From: Jonathan Larmour <jlarmour@redhat.co.uk>
To: Fernando Nasser <fnasser@redhat.com>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: thumb_skip_prologue too adventurous
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38D5389B.6A481BFA@redhat.co.uk>
References: <38D3FFC8.32082A85@redhat.co.uk> <38D40052.AF731E81@redhat.co.uk> <38D5064B.40AE9470@redhat.com>
X-SW-Source: 2000-q1/msg00787.html
Content-length: 4848
Fernando Nasser wrote:
> I am not sure if there isn't a better solution for this, but for now I
> would say that you should check your change in as an emergency fix.
I don't have checkin rights to the "src" repository, so I'd be grateful if
you could do this for me.
> I
> am assuming you ran the testsuite and it did not cause any regressions,
> right? (I don't think it will cause any)
Nope - no regressions.
> I may latter add another change to check first if there is information
> about the prologue end in the symbol table. I don't know why this was
> not checked before, I just noticed it now, looking at you patch.
Don't worry - it is checked, but it is done in arm_skip_prologue, before
thumb_skip_prologue is called.
> I wrote this thumb prologue scan code to match the new compiler (gcc)
> prologue generation. As everything is new, both Nick and I used the
> testsuite results to verify our work. The case you mention does not have
> a testsuite case. I wonder if you could add a test case?
I've never done a GDB testcase before, but here goes - I've attached one. It
runs at the end of break.exp. The complication is that we need to start
over, because the problematic programs are the ones compiled with
optimization. So we have to jump through all the same hoops as at the start
of the file. Some of this stuff might be overkill, but it definitely seems
to work.
I agree the addition of this test is A Good Thing as we've had these types
of problems before on other targets with optimized code.
Hope this helps. Obviously let me know if there are any problems with it.
Jifl
2000-03-19 Jonathan Larmour <jlarmour@redhat.co.uk>
* gdb.base/break.exp: Add new test for setting breakpoints on
optimized code so we can test breakpoints work even when function
prologues may be optimized away
--
Red Hat, 35 Cambridge Place, Cambridge, UK. CB2 1NS Tel: +44 (1223) 728762
"Plan to be spontaneous tomorrow." || These opinions are all my own fault
Index: gdb/testsuite/gdb.base/break.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.base/break.exp,v
retrieving revision 1.2
diff -u -5 -p -r1.2 break.exp
--- gdb/testsuite/gdb.base/break.exp 2000/02/16 00:11:07 1.2
+++ gdb/testsuite/gdb.base/break.exp 2000/03/19 20:26:34
@@ -799,10 +799,83 @@ proc test_next_with_recursion {} {
}
test_clear_command
test_next_with_recursion
+
+#********
+
+# build a new file with optimization enabled so that we can try breakpoints
+# on targets with optimized prologues
+
+set binfileo2 ${objdir}/${subdir}/${testfile}o2
+
+if { [gdb_compile "${srcdir}/${subdir}/${srcfile}" "${binfileo2}" executable {debug additional_flags="-O2" }] != "" } {
+ gdb_suppress_entire_file "Testcase compile failed, so all tests in this file will automatically fail."
+}
+
+if [get_compiler_info ${binfileo2}] {
+ return -1
+}
+
+gdb_exit
+gdb_start
+gdb_reinitialize_dir $srcdir/$subdir
+gdb_load ${binfileo2}
+
+if [target_info exists gdb_stub] {
+ gdb_step_for_stub;
+}
+
+#
+# test break at function
+#
+gdb_test "break main" \
+ "Breakpoint.*at.* file .*$srcfile, line.*" \
+ "breakpoint function, optimized file"
+
+#
+# test break at function
+#
+gdb_test "break marker4" \
+ "Breakpoint.*at.* file .*$srcfile, line.*" \
+ "breakpoint small function, optimized file"
+
+#
+# run until the breakpoint at main is hit. For non-stubs-using targets.
+#
+if ![target_info exists use_gdb_stub] {
+ if [istarget "*-*-vxworks*"] then {
+ send_gdb "run vxmain \"2\"\n"
+ set timeout 120
+ verbose "Timeout is now $timeout seconds" 2
+ } else {
+ send_gdb "run\n"
+ }
+ gdb_expect {
+ -re "The program .* has been started already.*y or n. $" {
+ send_gdb "y\n"
+ exp_continue
+ }
+ -re "Starting program.*Breakpoint \[0-9\]+,.*main .*argc.*argv.* at .*$srcfile:75.*75\[\t \]+if .argc.* \{.*$gdb_prompt $"\
+ { pass "run until function breakpoint, optimized file" }
+ -re ".*$gdb_prompt $" { fail "run until function breakpoint, optimized file" }
+ timeout { fail "run until function breakpoint, optimized file (timeout)" }
+ }
+} else {
+ if ![target_info exists gdb_stub] {
+ gdb_test continue ".*Continuing\\..*Breakpoint \[0-9\]+, main \\(argc=.*, argv=.*, envp=.*\\) at .*$srcfile:75.*75\[\t \]+if .argc.*\{.*" "stub continue, optimized file"
+ }
+}
+
+#
+# run until the breakpoint at a small function
+#
+gdb_test continue "Continuing\\..*Breakpoint \[0-9\]+, marker4 \\(d=177601976\\) at .*$srcfile:51.*51\[\t \]+void.*marker4.*" \
+ "run until breakpoint set at small function, optimized file"
+
+
# Reset the default arguments for VxWorks
if [istarget "*-*-vxworks*"] {
set timeout 10
verbose "Timeout is now $timeout seconds" 2
send_gdb "set args main\n"
From cgf@cygnus.com Sat Apr 01 00:00:00 2000
From: Chris Faylor <cgf@cygnus.com>
To: Tom Tromey <tromey@cygnus.com>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: Patch: hash tables for msymbols
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <20000304235333.A4155@cygnus.com>
References: <87aeowo9jq.fsf@cygnus.com> <npr9drfz3b.fsf@zwingli.cygnus.com> <20000303182733.A2742@cygnus.com> <87vh328rze.fsf@cygnus.com>
X-SW-Source: 2000-q1/msg00517.html
Content-length: 393
On Sat, Mar 04, 2000 at 12:17:41PM -0700, Tom Tromey wrote:
>>>>>> "Chris" == Chris Faylor <cgf@cygnus.com> writes:
>Chris> I believe that Fred Fish has also come up with a similar
>Chris> "speedup" patch. I don't know compares to Tom's, though.
>
>His patch ignores the demangling problem. I believe it removes some
>gdb functionality.
Ah. That's right. Thanks for clarifying that.
cgf
From dan@cgsoftware.com Sat Apr 01 00:00:00 2000
From: dan@cgsoftware.com (Daniel Berlin+list.gdb-patches)
To: Andrew Cagney <ac131313@cygnus.com>
Cc: GDB Patches <gdb-patches@sourceware.cygnus.com>
Subject: Re: RFA Replace gdb/TODO with issues50
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <n1np56q0.fsf@dan.resnet.rochester.edu>
References: <38DAED11.C314EA48@cygnus.com>
X-SW-Source: 2000-q1/msg00976.html
Content-length: 547
Andrew Cagney <ac131313@cygnus.com> writes:
I'm all for that, i've taken care of everything with the word C++ or
exception in the TODO file already (thought not all of it is perfect
and in yet).
> Hello,
>
> I'd like to propose that the file gdb/TODO be emptied and then refilled
> with a heavily edited version of:
>
> http://sourceware.cygnus.com/gdb/issues50.html
>
> To the best of my knowledge large chunks of the existing TODO file are
> either wrong or irrelevant. I think starting from scratch would be more
> useful.
>
> Andrew
From shebs@apple.com Sat Apr 01 00:00:00 2000
From: Stan Shebs <shebs@apple.com>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: Michael Snyder <msnyder@cygnus.com>, gdb-patches@sourceware.cygnus.com
Subject: Re: gdb.texinfo broken?
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38D82684.89633B0B@apple.com>
References: <38D6CF69.6844@cygnus.com> <200003211819.NAA12435@indy.delorie.com> <38D7C977.FA3@cygnus.com> <5mitygglxs.fsf@jtc.redbacknetworks.com> <38D7FDD1.D54DE1D8@cygnus.com>
X-SW-Source: 2000-q1/msg00892.html
Content-length: 483
Andrew Cagney wrote:
>
> "J.T. Conklin" wrote:
>
> > It looks like the changes to the directory entry require the latest
> > makeinfo. I tried to use makeinfo from texinfo-3.2 and it failed,
> > makeinfo from texinfo-4.0 works.
>
> >From memory, the possibility of requiring texinfo 4.0 as part of
> building GDB 5 was considered and rejected :-(
Yeah, I have to revert - tried it on one of Apple's MkLinux systems,
which claims to have texinfo 3.9, and it fell down too.
Stan
From dj@delorie.com Sat Apr 01 00:00:00 2000
From: DJ Delorie <dj@delorie.com>
To: shebs@apple.com
Cc: nickc@cygnus.com, jtc@redback.com, gdb-patches@sourceware.cygnus.com
Subject: Re: Add support for WinCE toolchains
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200002230024.TAA11216@envy.delorie.com>
References: <200002222350.PAA09035@elmo.cygnus.com> <38B32684.530F4F66@apple.com>
X-SW-Source: 2000-q1/msg00315.html
Content-length: 435
> This should get a special mention in gdb/NEWS, and ideally in README
> also; this is one of those situations where you'll be glad you
> forestalled a slew of complaints and bug reports by documenting it
> in several places.
Is it acceptable to add notes to configure, so that if you said
"./configure --target=arm-pe" it could print out "Note: if you wanted
Windows CE, use arm-wince-pe instead" ? Maybe in the toplevel configure?
From tromey@cygnus.com Sat Apr 01 00:00:00 2000
From: Tom Tromey <tromey@cygnus.com>
To: David Taylor <taylor@cygnus.com>
Cc: tromey@cygnus.com, gdb-patches@sourceware.cygnus.com
Subject: Re: Patch: breakpoint range doc patch
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200001162255.OAA06804@ferrule.cygnus.com>
References: <200001162232.RAA08484@texas.cygnus.com>
X-SW-Source: 2000-q1/msg00020.html
Content-length: 320
>>>>> "David" == David Taylor <taylor@cygnus.com> writes:
David> I'm not the maintainer for gdb/doc/gdb.texinfo, nor for
David> gdb/breakpoint.c (and this change is improving the
David> documentation of functionality implemented by that file), but I
David> approve it.
That's good enough for me.
I checked it in.
Tom
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Jimmy Guo <guo@cup.hp.com>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: regression analysis: gdb.sum postprocessing script
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38DEFEB1.EB573B72@cygnus.com>
References: <Pine.LNX.4.10.10003241103440.15236-100000@hpcll168.cup.hp.com>
X-SW-Source: 2000-q1/msg01046.html
Content-length: 910
Jimmy Guo wrote:
>
> Here is a Perl script I wrote to postprocess one or more gdb.sum files
> and provide a complete dejagnu test outcome summary (or diff if more
> than one gdb.sum files are given). It's most useful if you want to have
> a complete view of regression status between two source trees and/or if
> you set up your testing to run multiple passes (to see how a test point
> behaves in different passes), however you can use it just on one test
> run's gdb.sum file and play around with the options to get test outcome
> presented in a much organized and useful way than going through the flat
> gdb.sum file.
I have a personal preference for keeping perl scripts out of the main
GDB sources :-(
Now if someone rewrote it to use either TCL, DEJAGNU or SH then I'd have
to think about it again - they are required to run the testsuite.
Perhaps a link/entry on the web page or ftp site.
Andrew
From msnyder@cygnus.com Sat Apr 01 00:00:00 2000
From: Michael Snyder <msnyder@cygnus.com>
To: gdb-patches@sourceware.cygnus.com
Cc: pes@regent.e-technik.tu-muenchen.de
Subject: Re: RFA: infrun.c, breakpoint.c: Kludge for Solaris x86 hardware watchpoint support
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38E13FD7.38E@cygnus.com>
References: <200003130947.KAA07528@reisser.regent.e-technik.tu-muenchen.de> <38E132C8.454C@cygnus.com>
X-SW-Source: 2000-q1/msg01097.html
Content-length: 215
Michael Snyder wrote:
> BTW, next time could you also include the ChangeLog entry
> in the diffs?
Oops, I stand corrected. I guess omitting the ChangeLog
from the diffs is the policy. Sorry for the confusion.
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: "Peter.Schauer" <Peter.Schauer@regent.e-technik.tu-muenchen.de>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: RFD: printcmd.c: Changing output width of p/a and x/a
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38D5EB6E.61C7D7D1@cygnus.com>
References: <200003072113.WAA26267@reisser.regent.e-technik.tu-muenchen.de>
X-SW-Source: 2000-q1/msg00807.html
Content-length: 1675
"Peter.Schauer" wrote:
> Would you expect
>
> (gdb) p/a (char)-1
(I guess you mean ``(signed char) -1''
>
> to yield
>
> $1 = 0xff (truncation to length of value, will cause testsuite
> regressions, which have to be adressed by changing
> the expect patterns)
> or
>
> $1 = 0xffffffff (truncation to size of pointer)
I suspect the latter. The value is being printed as if it were being
interpreted as an address (but I'm not the CLI expert).
>
> Here is a patch to truncate to the size of a pointer, please let me know
> if you want this to be changed to truncate to the length of the value.
>
> 2000-03-07 Peter Schauer <pes@regent.e-technik.tu-muenchen.de>
>
> * printcmd.c (print_scalar_formatted): Truncate addresses to the
> size of a target pointer before passing them to print_address.
>
> *** ./printcmd.c.orig Sun Mar 5 17:35:36 2000
> --- ./printcmd.c Tue Mar 7 19:59:46 2000
> ***************
> *** 443,449 ****
> break;
>
> case 'a':
> ! print_address (unpack_pointer (type, valaddr), stream);
> break;
>
> case 'c':
> --- 443,455 ----
> break;
>
> case 'a':
> ! {
> ! /* Truncate address to the size of a target pointer. */
> ! CORE_ADDR addr = unpack_pointer (type, valaddr);
> ! if (TARGET_PTR_BIT < (sizeof (CORE_ADDR) * HOST_CHAR_BIT))
> ! addr &= ((CORE_ADDR) 1 << TARGET_PTR_BIT) - 1;
> ! print_address (addr, stream);
> ! }
> break;
I'd include a comment noteing that shifting by
sizeof(CORE_ADDR)*HOST_CHAR_BIT is dangerous.
Andrew
From hjl@lucon.org Sat Apr 01 00:00:00 2000
From: "H . J . Lu" <hjl@lucon.org>
To: Jim Kingdon <kingdon@redhat.com>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: GDB 5.0 2000-03-05
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <20000306094553.B28105@lucon.org>
References: <38C2320A.E2134B29@cygnus.com> <20000305094341.A10426@lucon.org> <br9dojaan.fsf@rtl.cygnus.com>
X-SW-Source: 2000-q1/msg00540.html
Content-length: 1913
On Mon, Mar 06, 2000 at 09:08:48AM -0800, Jim Kingdon wrote:
> > Linux people are looking for something better than gdb 4.17.0.1x to
> > debug Linuxthreads. It will be very disappointing if 5.0 fails to do
> > so.
>
> True, it would be disappointing. Anyway, here is my attempt to
> summarize what is up with Linux (based of course on
> http://sourceware.cygnus.com/gdb/issues50.html ). In case it isn't
> obvious, it is up to Linux folks (HJ/JimB/MarkK/me/whoever to) get
> fixes checked in, we don't want to keep "5.0 release central" (Andrew)
> waiting.
I may be able to spend sometime on it next week.
>
> * Spurious SIGTRAP bug. No one has diagnosed this bug as far as I
> know, although JimB was working on it. This one is probably the most
> serious.
Do you have URL for the bug report.
>
> * lin-thread cannot handle thread exit. Should we think about
> disabling lin-thread in favor of linux-thread for 5.0? Or to put it
> another way, has lin-thread gotten enough testing? There might
I don't think so.
> be other variations on this theme, such as a note in the
> documentation about how deleting/renaming libthread_db might be a
> workaround, although I'm not sure that really helps much.
I think it is a good ide for 5.0.
>
> * dlclose(). Any reactions MarkK? Or JimB? Note that issues50.html
> points to a withdrawn patch; the most recent is:
> http://sourceware.cygnus.com/ml/gdb-patches/2000-q1/msg00454.html
>
> * 2.0.x kernel patch. MarkK? issues50.html points to the latest
> patch on this as far as I know:
> http://sourceware.cygnus.com/ml/gdb-patches/1999-q4/msg00294.html
>
> * hardware watchpoints. Does not strike me as important for 5.0 as
> the above, but if someone has time, should be worth a review. It is
> nice to see some patches out there.
I have some old patches for it. I will work on it when I find time
next week.
H.J.
From fnasser@cygnus.com Sat Apr 01 00:00:00 2000
From: Fernando Nasser <fnasser@cygnus.com>
To: gdb-patches@sourceware.cygnus.com, Elena Zannoni <ezannoni@cygnus.com>
Subject: RFA: Patch to blockframe.c, frame.h, arm-tdep.c and fr30-tdep.c (prologue cache)
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38ACA4D6.993AFF74@cygnus.com>
X-SW-Source: 2000-q1/msg00240.html
Content-length: 8728
I believe the following fixes a bug found by Elena.
Fernando
2000-02-17 Fernando Nasser <fnasser@totem.to.cygnus.com>
* blockframe.c (check_prologue_cache, save_prologue_cache,
flush_prologue_cache): Slightly improved version of a prologue
cache
used by some targets. Here there is a flush mechanism so we
never use
stale data.
* frame.h: Prototypes for the above functions.
* arm-tdep.c (check_prologue_cache, save_prologue_cache):
Deleted.
Moved (with changes) to blockframe.c.
--
Fernando Nasser
Red Hat - Toronto E-Mail: fnasser@cygnus.com
2323 Yonge Street, Suite #300 Tel: 416-482-2661 ext. 311
Toronto, Ontario M4P 2C9 Fax: 416-482-6299
Index: blockframe.c
===================================================================
RCS file: /cvs/src/src/gdb/blockframe.c,v
retrieving revision 1.1.1.11
diff -c -p -r1.1.1.11 blockframe.c
*** blockframe.c 1999/12/22 21:45:03 1.1.1.11
--- blockframe.c 2000/02/18 01:38:15
*************** flush_cached_frames ()
*** 269,274 ****
--- 269,275 ----
current_frame = NULL; /* Invalidate cache */
select_frame (NULL, -1);
+ flush_prolog_cache (); /* Invalidate prologue cache as well. */
annotate_frames_invalid ();
}
*************** reinit_frame_cache ()
*** 284,289 ****
--- 285,354 ----
{
select_frame (get_current_frame (), 0);
}
+ }
+
+ /* Check if prologue for this frame's PC has already been scanned. If
+ it has, copy the relevant information about that prologue and
+ return non-zero. Otherwise do not copy anything and return zero.
+
+ The information saved in the cache includes:
+ * the frame register number;
+ * the size of the stack frame;
+ * the offsets of saved regs (relative to the old SP); and
+ * the offset from the stack pointer to the frame pointer
+
+ The cache contains only one entry, since this is adequate for the
+ typical sequence of prologue scan requests we get. When performing
+ a backtrace, GDB will usually ask to scan the same function twice
+ in a row (once to get the frame chain, and once to fill in the
+ extra frame information). */
+
+ static struct frame_info prologue_cache;
+ static int prologue_cache_valid = 0; /* Indicate if contents are
valid. */
+
+ static int
+ check_prologue_cache (struct frame_info *fi)
+ {
+ int i;
+
+ if ((prolog_cache_valid)
+ && (fi->pc == prologue_cache.pc))
+ {
+ fi->framereg = prologue_cache.framereg;
+ fi->framesize = prologue_cache.framesize;
+ fi->frameoffset = prologue_cache.frameoffset;
+ for (i = 0; i <= NUM_REGS; i++)
+ fi->fsr.regs[i] = prologue_cache.fsr.regs[i];
+ return 1;
+ }
+ else
+ return 0;
+ }
+
+ /* Copy the prologue information from fi to the prologue cache. */
+
+ static void
+ save_prologue_cache (struct frame_info *fi)
+ {
+ int i;
+
+ prologue_cache.pc = fi->pc;
+ prologue_cache.framereg = fi->framereg;
+ prologue_cache.framesize = fi->framesize;
+ prologue_cache.frameoffset = fi->frameoffset;
+
+ for (i = 0; i <= NUM_REGS; i++)
+ prologue_cache.fsr.regs[i] = fi->fsr.regs[i];
+
+ prologue_cache_valid = 1;
+ }
+
+ /* Flush the prologue cache. */
+
+ static void
+ flush_prologue_cache ()
+ {
+ prologue_cache_valid = 0;
}
/* Return nonzero if the function for this frame lacks a prologue.
Many
Index: frame.h
===================================================================
RCS file: /cvs/src/src/gdb/frame.h,v
retrieving revision 1.1.1.11
diff -c -p -r1.1.1.11 frame.h
*** frame.h 2000/02/02 00:21:06 1.1.1.11
--- frame.h 2000/02/18 01:38:15
*************** extern void flush_cached_frames PARAMS (
*** 181,186 ****
--- 181,191 ----
extern void reinit_frame_cache PARAMS ((void));
+ extern static int check_prologue_cache PARAMS ((struct frame_info *));
+
+ extern static void save_prologue_cache PARAMS ((struct frame_info *));
+
+ extern static void flush_prologue_cache PARAMS ((void));
#ifdef FRAME_FIND_SAVED_REGS
/* XXX - deprecated */
Index: arm-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/arm-tdep.c,v
retrieving revision 1.3
diff -c -p -r1.3 arm-tdep.c
*** arm-tdep.c 2000/02/17 19:51:04 1.3
--- arm-tdep.c 2000/02/18 01:38:16
*************** thumb_scan_prologue (struct frame_info *
*** 576,635 ****
}
}
- /* Check if prologue for this frame's PC has already been scanned. If
- it has, copy the relevant information about that prologue and
- return non-zero. Otherwise do not copy anything and return zero.
-
- The information saved in the cache includes:
- * the frame register number;
- * the size of the stack frame;
- * the offsets of saved regs (relative to the old SP); and
- * the offset from the stack pointer to the frame pointer
-
- The cache contains only one entry, since this is adequate for the
- typical sequence of prologue scan requests we get. When performing
- a backtrace, GDB will usually ask to scan the same function twice
- in a row (once to get the frame chain, and once to fill in the
- extra frame information). */
-
- static struct frame_info prologue_cache;
-
- static int
- check_prologue_cache (struct frame_info *fi)
- {
- int i;
-
- if (fi->pc == prologue_cache.pc)
- {
- fi->framereg = prologue_cache.framereg;
- fi->framesize = prologue_cache.framesize;
- fi->frameoffset = prologue_cache.frameoffset;
- for (i = 0; i <= NUM_REGS; i++)
- fi->fsr.regs[i] = prologue_cache.fsr.regs[i];
- return 1;
- }
- else
- return 0;
- }
-
-
- /* Copy the prologue information from fi to the prologue cache. */
-
- static void
- save_prologue_cache (struct frame_info *fi)
- {
- int i;
-
- prologue_cache.pc = fi->pc;
- prologue_cache.framereg = fi->framereg;
- prologue_cache.framesize = fi->framesize;
- prologue_cache.frameoffset = fi->frameoffset;
-
- for (i = 0; i <= NUM_REGS; i++)
- prologue_cache.fsr.regs[i] = fi->fsr.regs[i];
- }
-
-
/* This function decodes an ARM function prologue to determine:
1) the size of the stack frame
2) which registers are saved on it
--- 576,581 ----
Index: fr30-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/fr30-tdep.c,v
retrieving revision 1.1.1.4
diff -c -p -r1.1.1.4 fr30-tdep.c
*** fr30-tdep.c 1999/07/07 20:06:09 1.1.1.4
--- fr30-tdep.c 2000/02/18 01:38:16
*************** _initialize_fr30_tdep ()
*** 251,318 ****
tm_print_insn = print_insn_fr30;
}
- /* Function: check_prologue_cache
- Check if prologue for this frame's PC has already been scanned.
- If it has, copy the relevant information about that prologue and
- return non-zero. Otherwise do not copy anything and return zero.
-
- The information saved in the cache includes:
- * the frame register number;
- * the size of the stack frame;
- * the offsets of saved regs (relative to the old SP); and
- * the offset from the stack pointer to the frame pointer
-
- The cache contains only one entry, since this is adequate
- for the typical sequence of prologue scan requests we get.
- When performing a backtrace, GDB will usually ask to scan
- the same function twice in a row (once to get the frame chain,
- and once to fill in the extra frame information).
- */
-
- static struct frame_info prologue_cache;
-
- static int
- check_prologue_cache (fi)
- struct frame_info *fi;
- {
- int i;
-
- if (fi->pc == prologue_cache.pc)
- {
- fi->framereg = prologue_cache.framereg;
- fi->framesize = prologue_cache.framesize;
- fi->frameoffset = prologue_cache.frameoffset;
- for (i = 0; i <= NUM_REGS; i++)
- fi->fsr.regs[i] = prologue_cache.fsr.regs[i];
- return 1;
- }
- else
- return 0;
- }
-
-
- /* Function: save_prologue_cache
- Copy the prologue information from fi to the prologue cache.
- */
-
- static void
- save_prologue_cache (fi)
- struct frame_info *fi;
- {
- int i;
-
- prologue_cache.pc = fi->pc;
- prologue_cache.framereg = fi->framereg;
- prologue_cache.framesize = fi->framesize;
- prologue_cache.frameoffset = fi->frameoffset;
-
- for (i = 0; i <= NUM_REGS; i++)
- {
- prologue_cache.fsr.regs[i] = fi->fsr.regs[i];
- }
- }
-
-
/* Function: scan_prologue
Scan the prologue of the function that contains PC, and record what
we find in PI. PI->fsr must be zeroed by the called. Returns the
--- 251,256 ----
From taylor@cygnus.com Sat Apr 01 00:00:00 2000
From: David Taylor <taylor@cygnus.com>
To: Kevin Buettner <kevinb@cygnus.com>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: [PATCH RFA] utils.c should not assume that sizeof(long) == 32
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200003201738.MAA22436@texas.cygnus.com>
X-SW-Source: 2000-q1/msg00817.html
Content-length: 1306
Date: Sat, 18 Mar 2000 15:08:04 -0700
From: Kevin Buettner <kevinb@cygnus.com>
The following patch fixes a problem on IA-64 where I was seeing the
following behavior...
(gdb) print 3.0 * 4.0
$1 = 24
(gdb) print 2.0
$2 = 4
This bug was also responsible for a number of testsuite failures.
May I check this in?
Approved.
* utils.c (floatformat_from_doublest): Don't assume that a long
will be exactly 32 bits in length.
Index: utils.c
===================================================================
RCS file: /cvs/src/src/gdb/utils.c,v
retrieving revision 1.4
diff -u -p -r1.4 utils.c
--- utils.c 2000/03/04 02:23:06 1.4
+++ utils.c 2000/03/18 21:43:59
@@ -2771,7 +2771,7 @@ floatformat_from_doublest (fmt, from, to
mant_bits = mant_bits_left < 32 ? mant_bits_left : 32;
mant *= 4294967296.0;
- mant_long = (unsigned long) mant;
+ mant_long = ((unsigned long) mant) & 0xffffffffL;
mant -= mant_long;
/* If the integer bit is implicit, then we need to discard it.
@@ -2782,6 +2782,7 @@ floatformat_from_doublest (fmt, from, to
&& fmt->intbit == floatformat_intbit_no)
{
mant_long <<= 1;
+ mant_long &= 0xffffffffL;
mant_bits -= 1;
}
From eliz@delorie.com Sat Apr 01 00:00:00 2000
From: Eli Zaretskii <eliz@delorie.com>
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, 01 Apr 2000 00:00:00 -0000
Message-id: <200003182227.RAA07058@indy.delorie.com>
References: <200003162241.RAA19616@zwingli.cygnus.com> <1000316225504.ZM3009@ocotillo.lan> <npsnxp8ix6.fsf@zwingli.cygnus.com>
X-SW-Source: 2000-q1/msg00773.html
Content-length: 622
> *** 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 shebs@apple.com Sat Apr 01 00:00:00 2000
From: Stan Shebs <shebs@apple.com>
To: Kevin Buettner <kevinb@cygnus.com>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: [PATCH RFA] testsuite changes needed for AIX 4.3
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38A9E4F9.514007E1@apple.com>
References: <1000215230816.ZM2175@ocotillo.lan>
X-SW-Source: 2000-q1/msg00162.html
Content-length: 845
Kevin Buettner wrote:
>
> I hereby reqest approval for committing the following changes:
>
> * gdb.base/pointers.c (usevar): New function.
> (main): Make sure that global variables v_int_pointer2, rptr,
> and y are all referenced someplace in the program by calling
> usevar() on them. [Some linkers delete symbols which are
> never referenced. The space remains, but there's no way to
> get a (symbolic) handle on the variable from the debugger.]
>
> * gdb.base/scope.exp: For powerpc-*-*, xfail the same tests
> that rs6000-*-* does.
This looks reasonable to me, with the same question as Mark Kettenis
raises: are the xfails unconditional because the tests fail whether
xlc or gcc is used as the compiler? If they pass with xlc, then you
need to test gcc_compiled.
Stan
From jtc@redback.com Sat Apr 01 00:00:00 2000
From: jtc@redback.com (J.T. Conklin)
To: gdb-patches@sourceware.cygnus.com
Subject: RFA: i386/tm-nsbd.h, i386/nm-nbsd.h
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <5m66uggiur.fsf@jtc.redbacknetworks.com>
X-SW-Source: 2000-q1/msg00871.html
Content-length: 1734
I submit the enclosed patch for approval. These changes enable
floating point register support on NetBSD/i386.
--jtc
2000-03-21 J.T. Conklin <jtc@redback.com>
* i386/tm-nbsd.h (NUM_REGS): Removed.
(HAVE_I387_REGS): Defined.
* i386/nm-nbsd.h (FLOAT_INFO): Removed.
Index: tm-nbsd.h
===================================================================
RCS file: /cvs/src/src/gdb/config/i386/tm-nbsd.h,v
retrieving revision 1.1.1.2
diff -c -3 -p -r1.1.1.2 tm-nbsd.h
*** tm-nbsd.h 1999/07/07 20:13:21 1.1.1.2
--- tm-nbsd.h 2000/03/21 20:22:36
***************
*** 21,31 ****
#ifndef TM_NBSD_H
#define TM_NBSD_H
#include "i386/tm-i386bsd.h"
#include "tm-nbsd.h"
-
- #undef NUM_REGS
- #define NUM_REGS 16
#define JB_ELEMENT_SIZE sizeof(int) /* jmp_buf[_JBLEN] is array of ints */
#define JB_PC 0 /* Setjmp()'s return PC saved here */
--- 21,30 ----
#ifndef TM_NBSD_H
#define TM_NBSD_H
+ #define HAVE_I387_REGS
+
#include "i386/tm-i386bsd.h"
#include "tm-nbsd.h"
#define JB_ELEMENT_SIZE sizeof(int) /* jmp_buf[_JBLEN] is array of ints */
#define JB_PC 0 /* Setjmp()'s return PC saved here */
Index: nm-nbsd.h
===================================================================
RCS file: /cvs/src/src/gdb/config/i386/nm-nbsd.h,v
retrieving revision 1.1.1.2
diff -c -3 -p -r1.1.1.2 nm-nbsd.h
*** nm-nbsd.h 1999/07/07 20:12:53 1.1.1.2
--- nm-nbsd.h 2000/03/21 20:22:36
***************
*** 24,31 ****
/* Get generic NetBSD native definitions. */
#include "nm-nbsd.h"
- /* #define FLOAT_INFO { i386_float_info(); } */
-
#define REGISTER_U_ADDR(addr, blockend, regno) \
(addr) = i386_register_u_addr ((blockend),(regno));
--- 24,29 ----
--
J.T. Conklin
RedBack Networks
From fnasser@redhat.com Sat Apr 01 00:00:00 2000
From: Fernando Nasser <fnasser@redhat.com>
To: GDB Patches <gdb-patches@sourceware.cygnus.com>
Subject: Re: [Maint] Second testsuite maintainer
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38D8C648.3FE00B1C@redhat.com>
References: <38D84B37.B90E15AB@cygnus.com> <38D8C5BA.20C4B77@redhat.com>
X-SW-Source: 2000-q1/msg00903.html
Content-length: 307
Sorry folks.
That was a personal message and I pressed the wrong button by mistake.
:-(
--
Fernando Nasser
Red Hat, Inc. - Toronto E-Mail: fnasser@redhat.com
2323 Yonge Street, Suite #300 Tel: 416-482-2661 ext. 311
Toronto, Ontario M4P 2C9 Fax: 416-482-6299
From kevinb@cygnus.com Sat Apr 01 00:00:00 2000
From: Kevin Buettner <kevinb@cygnus.com>
To: gdb-patches@sourceware.cygnus.com
Subject: [PATCH] symtab.h, symfile.h, symfile.c, and solib.c changes
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <1000321225350.ZM26428@ocotillo.lan>
X-SW-Source: 2000-q1/msg00881.html
Content-length: 8162
I just committed the following changes. I've built/run the test suite
on three platforms (linux/ia32, linux/ia64, linux/ppc) and all looks
well.
* symtab.h (MAX_SECTIONS, struct section_addr_info,
symbol_file_add): Move declarations from here...
* symfile.h: ...to here.
* solib.c (symbol_add_stub): Make symbol_file_add () aware of
all section addresses, not just .text.
* symfile.h, symfile.c (free_section_addr_info,
build_section_addr_info_from_section_table): New functions.
* symfile.h (MAX_SECTIONS): Increase value to 40.
* symfile.c (syms_from_objfile): Add bounds check prior to
accessing ``other'' array in a section_addr_info_struct.
Remove unused variable section_offsets.
(add_symbol_file_command): Remove unused variable text_addr.
Index: solib.c
===================================================================
RCS file: /cvs/src/src/gdb/solib.c,v
retrieving revision 1.5
diff -u -p -r1.5 solib.c
--- solib.c 2000/03/17 20:12:23 1.5
+++ solib.c 2000/03/21 22:12:33
@@ -1155,6 +1155,7 @@ symbol_add_stub (arg)
{
register struct so_list *so = (struct so_list *) arg; /* catch_errs bogon */
CORE_ADDR text_addr = 0;
+ struct section_addr_info *sap;
/* Have we already loaded this shared object? */
ALL_OBJFILES (so->objfile)
@@ -1181,15 +1182,12 @@ symbol_add_stub (arg)
+ LM_ADDR (so);
}
- {
- struct section_addr_info section_addrs;
-
- memset (§ion_addrs, 0, sizeof (section_addrs));
- section_addrs.text_addr = text_addr;
-
- so->objfile = symbol_file_add (so->so_name, so->from_tty,
- §ion_addrs, 0, OBJF_SHARED);
- }
+ sap = build_section_addr_info_from_section_table (so->sections,
+ so->sections_end);
+ sap->text_addr = text_addr;
+ so->objfile = symbol_file_add (so->so_name, so->from_tty,
+ sap, 0, OBJF_SHARED);
+ free_section_addr_info (sap);
return (1);
}
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/21 22:12:37
@@ -461,6 +461,58 @@ find_lowest_section (abfd, sect, obj)
*lowest = sect;
}
+
+/* Build (allocate and populate) a section_addr_info struct from
+ an existing section table. */
+
+extern struct section_addr_info *
+build_section_addr_info_from_section_table (const struct section_table *start,
+ const struct section_table *end)
+{
+ struct section_addr_info *sap;
+ const struct section_table *stp;
+ int oidx;
+
+ sap = xmalloc (sizeof (struct section_addr_info));
+ memset (sap, 0, sizeof (struct section_addr_info));
+
+ for (stp = start, oidx = 0; stp != end; stp++)
+ {
+ if (strcmp (stp->the_bfd_section->name, ".text") == 0)
+ sap->text_addr = stp->addr;
+ else if (strcmp (stp->the_bfd_section->name, ".data") == 0)
+ sap->data_addr = stp->addr;
+ else if (strcmp (stp->the_bfd_section->name, ".bss") == 0)
+ sap->bss_addr = stp->addr;
+
+ if (stp->the_bfd_section->flags & (SEC_ALLOC | SEC_LOAD)
+ && oidx < MAX_SECTIONS)
+ {
+ sap->other[oidx].addr = stp->addr;
+ sap->other[oidx].name = xstrdup (stp->the_bfd_section->name);
+ sap->other[oidx].sectindex = stp->the_bfd_section->index;
+ oidx++;
+ }
+ }
+
+ return sap;
+}
+
+
+/* Free all memory allocated by build_section_addr_info_from_section_table. */
+
+extern void
+free_section_addr_info (struct section_addr_info *sap)
+{
+ int idx;
+
+ for (idx = 0; idx < MAX_SECTIONS; idx++)
+ if (sap->other[idx].name)
+ free (sap->other[idx].name);
+ free (sap);
+}
+
+
/* Parse the user's idea of an offset for dynamic linking, into our idea
of how to represent it for fast symbol reading. This is the default
version of the sym_fns.sym_offsets function for symbol readers that
@@ -531,7 +583,6 @@ syms_from_objfile (objfile, addrs, mainl
int mainline;
int verbo;
{
- struct section_offsets *section_offsets;
asection *lower_sect;
asection *sect;
CORE_ADDR lower_offset;
@@ -738,7 +789,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 */
@@ -1460,7 +1513,6 @@ add_symbol_file_command (args, from_tty)
int from_tty;
{
char *name = NULL;
- CORE_ADDR text_addr;
int flags = OBJF_USERLOADED;
char *arg;
int expecting_option = 0;
Index: symfile.h
===================================================================
RCS file: /cvs/src/src/gdb/symfile.h,v
retrieving revision 1.1.1.6
diff -u -p -r1.1.1.6 symfile.h
--- symfile.h 1999/10/19 02:46:39 1.1.1.6
+++ symfile.h 2000/03/21 22:12:37
@@ -54,6 +54,29 @@ struct psymbol_allocation_list
int size;
};
+/* Define an array of addresses to accommodate non-contiguous dynamic
+ loading of modules. This is for use when entering commands, so we
+ can keep track of the section names until we read the file and
+ can map them to bfd sections. This structure is also used by
+ solib.c to communicate the section addresses in shared objects to
+ symbol_file_add (). */
+
+#define MAX_SECTIONS 40
+struct section_addr_info
+{
+ /* Sections whose names are always known to gdb. */
+ CORE_ADDR text_addr;
+ CORE_ADDR data_addr;
+ CORE_ADDR bss_addr;
+ /* Sections whose names are file format dependant. */
+ struct other_sections
+ {
+ CORE_ADDR addr;
+ char *name;
+ int sectindex;
+ } other[MAX_SECTIONS];
+};
+
/* Structure to keep track of symbol reading functions for various
object file types. */
@@ -162,6 +185,23 @@ syms_from_objfile PARAMS ((struct objfil
extern void
new_symfile_objfile PARAMS ((struct objfile *, int, int));
+
+extern struct objfile *
+symbol_file_add PARAMS ((char *, int, struct section_addr_info *, int, int));
+
+/* Build (allocate and populate) a section_addr_info struct from
+ an existing section table. */
+
+struct section_table;
+extern struct section_addr_info *
+build_section_addr_info_from_section_table (const struct section_table *start,
+ const struct section_table *end);
+
+/* Free all memory allocated by build_section_addr_info_from_section_table. */
+
+extern void
+free_section_addr_info (struct section_addr_info *);
+
extern struct partial_symtab *
start_psymtab_common PARAMS ((struct objfile *, struct section_offsets *,
Index: symtab.h
===================================================================
RCS file: /cvs/src/src/gdb/symtab.h,v
retrieving revision 1.3
diff -u -p -r1.3 symtab.h
--- symtab.h 2000/03/14 19:58:02 1.3
+++ symtab.h 2000/03/21 22:12:39
@@ -837,27 +837,6 @@ struct section_offsets
(sizeof (struct section_offsets) \
+ sizeof (((struct section_offsets *) 0)->offsets) * (SECT_OFF_MAX-1))
-/* Define an array of addresses to accommodate non-contiguous dynamic
- loading of modules. This is for use when entering commands, so we
- can keep track of the section names until we read the file and
- can map them to bfd sections. */
-
-#define MAX_SECTIONS 12
-struct section_addr_info
-{
- /* Sections whose names are always known to gdb. */
- CORE_ADDR text_addr;
- CORE_ADDR data_addr;
- CORE_ADDR bss_addr;
- /* Sections whose names are file format dependant. */
- struct other_sections
- {
- CORE_ADDR addr;
- char *name;
- int sectindex;
- } other[MAX_SECTIONS];
-};
-
/* Each source file or header is represented by a struct symtab.
These objects are chained through the `next' field. */
@@ -1436,9 +1415,6 @@ extern struct symtab *
extern void
clear_solib PARAMS ((void));
-
-extern struct objfile *
-symbol_file_add PARAMS ((char *, int, struct section_addr_info *, int, int));
/* source.c */
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2000-04-01 0:00 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <200003162241.RAA19616@zwingli.cygnus.com>
[not found] ` <1000316225504.ZM3009@ocotillo.lan>
[not found] ` <npsnxp8ix6.fsf@zwingli.cygnus.com>
2000-03-18 14:27 ` Linux sigtramp detection code moved to its proper place Eli Zaretskii
2000-04-01 0:00 ` Mark Kettenis
[not found] ` <20000316180048.A30640@cygnus.com>
[not found] ` <200003162311.e2GNBUH00362@delius.kettenis.local>
[not found] ` <20000316193609.D30640@cygnus.com>
[not found] ` <200003182227.RAA07055@indy.delorie.com>
2000-04-01 0:00 ` Chris Faylor
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox