From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Snyder To: Andrew Cagney Cc: Alexandre Oliva , gdb-patches@sourceware.cygnus.com Subject: Re: ARM frame fp is not always FP_REGNUM Date: Tue, 04 Jul 2000 08:56:00 -0000 Message-id: <396208DF.76CA@cygnus.com> References: <39617827.29D15730@cygnus.com> X-SW-Source: 2000-07/msg00038.html Andrew Cagney wrote: > > Alexandre Oliva wrote: > > > > read_relative_register_raw_bytes_for_frame() would optimize access to > > FP_REGNUM by not re-reading it when the value of FP is already known. > > However, because FP is not always available, sometimes the value of SP > > is stored in the frame structure as the value of FP. In this case, > > reading the value of FP_REGNUM will get you SP instead of the actual > > value of the FP register. This patch fixes this bug. Ok to install? > > I'm not sure about this. > > FP_REGNUM refers to GDB's internal frame-handle / frame-pointer / > frame-base variable. It doesn't refer to the ISA register that is seen > in architectures such as ARM or VAX. Unfortunatly, some architectures > have both and this leads to confusion. Huh??? FP_REGNUM refers to a register. The "fp" that is displayed by "info registers" sometimes refers to gdb's internal pseudo-frame or virtual frame location, but the constant FP_REGNUM is a real hardware register. > What exactly is the behavour you're seeing and what behavour are you > trying to achieve. > > Andrew >From msnyder@cygnus.com Tue Jul 04 08:57:00 2000 From: Michael Snyder To: Alexandre Oliva Cc: Andrew Cagney , gdb-patches@sourceware.cygnus.com Subject: Re: ARM frame fp is not always FP_REGNUM Date: Tue, 04 Jul 2000 08:57:00 -0000 Message-id: <39620927.5D1E@cygnus.com> References: <39617827.29D15730@cygnus.com> X-SW-Source: 2000-07/msg00039.html Content-length: 601 Alexandre Oliva wrote: > > On Jul 4, 2000, Andrew Cagney wrote: > > > FP_REGNUM refers to GDB's internal frame-handle / frame-pointer / > > frame-base variable. > > On ARM, it's register 11, which is a real register. But SP_REGNUM is > register 13. Then, when framereg == 13 in EXTRA_FRAME_INFO, `info > regs' will display the value of r13 for r11, and the actual value of > r11 cannot be obtained. Yes it can. If you say "print $fp" you will get the value of register 11. I know this is confusing -- nay, broken. We've talked for a long time about what to do about it. >From kettenis@wins.uva.nl Tue Jul 04 15:58:00 2000 From: Mark Kettenis To: ac131313@cygnus.com Cc: gdb-patches@sourceware.cygnus.com Subject: [PATCH] TODO update. Date: Tue, 04 Jul 2000 15:58:00 -0000 Message-id: <200007042258.e64MwK200871@delius.kettenis.local> X-SW-Source: 2000-07/msg00040.html Content-length: 953 Andrew, Prompted by your snippet of the TODO file, I tweaked it somewhat to reflect reality a bit closer. Mark Index: TODO =================================================================== RCS file: /cvs/src/src/gdb/TODO,v retrieving revision 1.37 diff -u -p -r1.37 TODO --- TODO 2000/06/23 08:12:27 1.37 +++ TODO 2000/07/04 22:54:35 @@ -35,11 +35,9 @@ x86 targets. x86 linux GDB and SIGALRM (???) http://sourceware.cygnus.com/ml/gdb/2000-q1/msg00803.html -I know there are problems with single stepping through signal -handlers. These problems were present in 4.18. They were just masked -because 4.18 failed to recognize signal handlers. Fixing it is not -easy, and will require changes to handle_inferior_event(), that I -prefer not to make before the 5.0 release. +This problem has been fixed, but a regression test still needs to be +added to the testsuite: + http://sourceware.cygnus.com/ml/gdb-patches/2000-05/msg00309.html Mark >From ac131313@cygnus.com Tue Jul 04 19:11:00 2000 From: Andrew Cagney To: msnyder@cygnus.com Cc: Alexandre Oliva , gdb-patches@sourceware.cygnus.com Subject: Re: ARM frame fp is not always FP_REGNUM Date: Tue, 04 Jul 2000 19:11:00 -0000 Message-id: <396298DC.4543E9BF@cygnus.com> References: <39617827.29D15730@cygnus.com> <396208DF.76CA@cygnus.com> X-SW-Source: 2000-07/msg00041.html Content-length: 1919 Michael Snyder wrote: > > Andrew Cagney wrote: > > > > Alexandre Oliva wrote: > > > > > > read_relative_register_raw_bytes_for_frame() would optimize access to > > > FP_REGNUM by not re-reading it when the value of FP is already known. > > > However, because FP is not always available, sometimes the value of SP > > > is stored in the frame structure as the value of FP. In this case, > > > reading the value of FP_REGNUM will get you SP instead of the actual > > > value of the FP register. This patch fixes this bug. Ok to install? > > > > I'm not sure about this. > > > > FP_REGNUM refers to GDB's internal frame-handle / frame-pointer / > > frame-base variable. It doesn't refer to the ISA register that is seen > > in architectures such as ARM or VAX. Unfortunatly, some architectures > > have both and this leads to confusion. > > Huh??? FP_REGNUM refers to a register. > The "fp" that is displayed by "info registers" sometimes > refers to gdb's internal pseudo-frame or virtual frame location, > but the constant FP_REGNUM is a real hardware register. I read it as the hardware or pseudo register that directly corresponds to GDB's ``$fp'' pseudo register. parse.c:build_parse() maps $fp -> FP_REGNUM. (mental note, fix buffer overrun in build_parse()). Some targets have a real $fp (ARM, VAX) so the obvious thing to do was to map FP_REGNUM onto the real register. Other targets don't have a real $fp so it is mapped onto a pseudo register (MIPS). As Alexandre pointed out, things relied on pseudo-$fp <-> FP_REGNUM <-> frame->frame <-> hardware-$fp but in modern times, with frameless functions, this makes little sense. My reading of the doco is that, when the target has a true hardware $fp, then the pseudo $fp register shouldn't be provided. Per other e-mail, I think this can be implemented by invalidating FP_REGNUM (set it to -1) and instead provide read_fp() and write_fp(). Andrew >From ac131313@cygnus.com Wed Jul 05 01:01:00 2000 From: Andrew Cagney To: GDB Patches Subject: Delete sim/SIM_HAVE_BREAKPOINTS and gdb/SIM_HAS_BREAKPOINTS Date: Wed, 05 Jul 2000 01:01:00 -0000 Message-id: <3962EB23.D6E08550@cygnus.com> X-SW-Source: 2000-07/msg00042.html Content-length: 1262 Hello, One of the target macros that keeps lurking in GDB is SIM_HAS_BREAKPOINTS. Checking the actual code, I've found that only the d30v actually uses it. (The d30v is a VLIW embedded processor). Given that the functionality provided by SIM_HAS_BREAKPOINTS can be implemented using other more direct means I'd like to propose that the macro be purged. The idea behind the code (and sounds good in theory) was that the simulator should administer its breakpoints directly. Unfortunatly, reality got in the way, and several things conspired to ensure that it was never widely adopted. Of note are: o as I mentioned, only one target adopted it in the end. Several other sim targets think that they are using the mechanism but a more careful examination of the source code reveals otherwize :-) o turns out that equivalent functionality can be achieved by having GDB pass signals back to the simulator when an unknown breakpoint is encountered. It also turns out that providing this functionality is far more useful. o It used the s/w breakpoint mechanism, just like GDB. If it had exploited the sim/common h/w breakpoint and watchpoint framework then I suspect it would be heavily used. Any comments? Andrew >From ac131313@cygnus.com Wed Jul 05 01:14:00 2000 From: Andrew Cagney To: Bill Nottingham Cc: gdb-patches@sourceware.cygnus.com Subject: Re: [PATCH] Makefile.in: fix install-info Date: Wed, 05 Jul 2000 01:14:00 -0000 Message-id: <3962EE1D.DDC6A3AE@cygnus.com> References: <20000613001035.B4580@nostromo.devel.redhat.com> X-SW-Source: 2000-07/msg00043.html Content-length: 1122 Bill Nottingham wrote: > > This patch fixes 'make install-info' so that > > ./configure --infodir=/usr/share/info > make install-info infodir=/somewhere/else/usr/share/info > > works correctly. Is this the correct place to fix this, or > does this need changed somewhere else? For the way GDB is currently set up, it (I believe) is correct. automake does it very differently but we're not using automake. I've applied/tested the change. Thanks! Andrew > 2000-06-12 Bill Nottingham > > * Makefile.in: add $(infodir) to FLAGS_TO_PASS > > Index: Makefile.in > =================================================================== > RCS file: /cvs/src/src/gdb/Makefile.in,v > retrieving revision 1.35 > diff -u -p -r1.35 Makefile.in > --- Makefile.in 2000/06/12 06:09:04 1.35 > +++ Makefile.in 2000/06/13 04:01:17 > @@ -368,6 +368,7 @@ ANNOTATE_OBS = annotate.o > FLAGS_TO_PASS = \ > "prefix=$(prefix)" \ > "exec_prefix=$(exec_prefix)" \ > + "infodir=$(infodir)" \ > "against=$(against)" \ > "AR=$(AR)" \ > "AR_FLAGS=$(AR_FLAGS)" \ >From ac131313@cygnus.com Wed Jul 05 01:29:00 2000 From: Andrew Cagney To: Eli Zaretskii Cc: gdb-patches@sourceware.cygnus.com Subject: Re: [patch] Set SER_HARDWIRE using autoconf Date: Wed, 05 Jul 2000 01:29:00 -0000 Message-id: <3962F1B8.325BE74@cygnus.com> References: <39447FB9.DD0ED9BE@cygnus.com> <200006180452.AAA01630@indy.delorie.com> X-SW-Source: 2000-07/msg00044.html Content-length: 1635 Eli Zaretskii wrote: > > > Date: Mon, 12 Jun 2000 16:14:17 +1000 > > From: Andrew Cagney > > > > I've checked in the attached. By default a target will be built with > > ser-tcp.o. go32*-*-* is currently the only exception. > > Andrew, > > I didn't have time to actually test this change, but I think this is > wrong: the DJGPP port uses "i386-pc-msdosdjgpp" as the value of $host. > The value if ${gdb_host} is set to "go32", but I don't think you are > referencing that variable in configure.in (reproduced below), are you? > > I think to get this right, you need to allow both go32*-*-* and > *-*-*djgpp in ${host}. Up, yes. Does: case ${host} in *go32* ) SER_HARDWIRE=ser-go32.o ;; *djgpp* ) SER_HARDWIRE= ;; esac look safer? Andrew > > Index: configure.in > > =================================================================== > > RCS file: /cvs/src/src/gdb/configure.in,v > > retrieving revision 1.36 > > diff -p -r1.36 configure.in > > *** configure.in 2000/06/11 01:39:08 1.36 > > --- configure.in 2000/06/12 06:04:04 > > *************** AC_CACHE_CHECK([for cygwin], gdb_cv_os_c > > *** 626,631 **** > > --- 626,640 ---- > > lose > > #endif],[gdb_cv_os_cygwin=yes],[gdb_cv_os_cygwin=no])]) > > > > + > > + dnl Figure out which of the many generic ser-*.c files the _host_ supports. > > + SER_HARDWIRE="ser-unix.o ser-pipe.o ser-tcp.o" > > + case ${host} in > > + go32*-*-* ) SER_HARDWIRE=ser-go32.o ;; > > + esac > > + AC_SUBST(SER_HARDWIRE) > > + > > + > > dnl Figure out which term library to use. > > if test x$gdb_host = xgo32; then > > TERM_LIB= >From ac131313@cygnus.com Wed Jul 05 01:48:00 2000 From: Andrew Cagney To: BINUTILS Patches , GDB Patches Cc: Andreas Jaeger Subject: Re: Update config.guess, config.sub, texinfo.tex Date: Wed, 05 Jul 2000 01:48:00 -0000 Message-id: <3962F60E.E492A153@cygnus.com> References: <3931F0DF.868A3085@cygnus.com> <3934E6D5.C2AEB97@cygnus.com> X-SW-Source: 2000-07/msg00045.html Content-length: 5720 Andreas Jaeger wrote: > > >>>>> Andrew Cagney writes: > > Andrew> Andrew Cagney wrote: > >> > >> FYI, > >> > >> I intend updating these with more recent copies from the official > >> releases. For texinfo.tex that would be makeinfo-4.0. > > Andrew> The texinfo.tex file is now in. > > The most recent version of texinfo.tex is on ftp.gnu.org as a single > file. > ls -l manual/texinfo.tex > -rw-r--r-- 1 aj users 200234 May 17 09:58 manual/texinfo.tex > > It contains: > \def\texinfoversion{2000-05-16.11} > > I advise to use that version instead, > Andreas (I've just got back to this) I intend bringing in: \def\texinfoversion{2000-05-28.15} obtained from ftp://ftp.gnu.org/gnu/texinfo.tex (I couldn't find the file manual/texinfo.tex :-) The differences between it and the current texinfo.tex (from makeinfo 4.0) are attatched. Any problems? Andrew ? diffs Index: texinfo.tex =================================================================== RCS file: /cvs/src/src/texinfo/texinfo.tex,v retrieving revision 1.2 diff -p -r1.2 texinfo.tex *** texinfo.tex 2000/05/31 10:18:58 1.2 --- texinfo.tex 2000/07/05 08:41:43 *************** *** 3,9 **** % Load plain if necessary, i.e., if running under initex. \expandafter\ifx\csname fmtname\endcsname\relax\input plain\fi % ! \def\texinfoversion{1999-09-25.10} % % Copyright (C) 1985, 86, 88, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99 % Free Software Foundation, Inc. --- 3,9 ---- % Load plain if necessary, i.e., if running under initex. \expandafter\ifx\csname fmtname\endcsname\relax\input plain\fi % ! \def\texinfoversion{2000-05-28.15} % % Copyright (C) 1985, 86, 88, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99 % Free Software Foundation, Inc. *************** *** 214,219 **** --- 214,222 ---- \normalturnoffactive % \ in index entries must not stay \, e.g., if % the page break happens to be in the middle of an example. \shipout\vbox{% + % Do this early so pdf references go to the beginning of the page. + \ifpdfmakepagedest \pdfmkdest{\the\pageno} \fi + % \ifcropmarks \vbox to \outervsize\bgroup \hsize = \outerhsize \vskip-\topandbottommargin *************** *** 243,250 **** \unvbox\footlinebox \fi % - \ifpdfmakepagedest \pdfmkdest{\the\pageno} \fi - % \ifcropmarks \egroup % end of \vbox\bgroup \hfil\egroup % end of (centering) \line\bgroup --- 246,251 ---- *************** where each line of input produces a line *** 891,897 **** \fi} \def\pdfmkdest#1{\pdfdest name{#1@} xyz} \def\pdfmkpgn#1{#1@} ! \let\linkcolor = \Cyan \def\endlink{\Black\pdfendlink} % Adding outlines to PDF; macros for calculating structure of outlines % come from Petr Olsak --- 892,898 ---- \fi} \def\pdfmkdest#1{\pdfdest name{#1@} xyz} \def\pdfmkpgn#1{#1@} ! \let\linkcolor = \Blue % was Cyan, but that seems light? \def\endlink{\Black\pdfendlink} % Adding outlines to PDF; macros for calculating structure of outlines % come from Petr Olsak *************** where each line of input produces a line *** 906,912 **** \closein 1 \indexnofonts \def\tt{} ! % thanh's hack / proper braces in bookmarks \edef\mylbrace{\iftrue \string{\else}\fi}\let\{=\mylbrace \edef\myrbrace{\iffalse{\else\string}\fi}\let\}=\myrbrace % --- 907,914 ---- \closein 1 \indexnofonts \def\tt{} ! \let\_ = \normalunderscore ! % Thanh's hack / proper braces in bookmarks \edef\mylbrace{\iftrue \string{\else}\fi}\let\{=\mylbrace \edef\myrbrace{\iffalse{\else\string}\fi}\let\}=\myrbrace % *************** where each line of input produces a line *** 1670,1676 **** } % Subroutines used in generating headings ! % Produces Day Month Year style of output. \def\today{% \number\day\space \ifcase\month --- 1672,1681 ---- } % Subroutines used in generating headings ! % This produces Day Month Year style of output. ! % Only define if not already defined, in case a txi-??.tex file has set ! % up a different format (e.g., txi-cs.tex does this). ! \ifx\today\undefined \def\today{% \number\day\space \ifcase\month *************** where each line of input produces a line *** 1679,1684 **** --- 1684,1690 ---- \or\putwordMSep\or\putwordMOct\or\putwordMNov\or\putwordMDec \fi \space\number\year} + \fi % @settitle line... specifies the title of the document, for headings. % It generates no output of its own. *************** width0pt\relax} \fi *** 4710,4716 **** \def\deftypeivarheader#1#2#3{% \dosubind{vr}{\code{#3}}{\putwordof\ \code{#1}}% entry in variable index \begingroup ! \defname{#3}{\putwordInstanceVariableof\ \code{#1}}% \defvarargs{#3}% \endgroup } --- 4716,4723 ---- \def\deftypeivarheader#1#2#3{% \dosubind{vr}{\code{#3}}{\putwordof\ \code{#1}}% entry in variable index \begingroup ! \defname{\defheaderxcond#2\relax$$$#3} ! {\putwordInstanceVariableof\ \code{#1}}% \defvarargs{#3}% \endgroup } *************** should work if nowhere else does.} *** 5794,5800 **** % Use @afourwide to print on European A4 paper in wide format. \def\afourwide{% \afourpaper ! \internalpagesizes{9.5in}{6.5in}{\hoffset}{\normaloffset}{\bindingoffset}{7mm}% % \globaldefs = 0 } --- 5801,5807 ---- % Use @afourwide to print on European A4 paper in wide format. \def\afourwide{% \afourpaper ! \internalpagesizes{6.5in}{9.5in}{\hoffset}{\normaloffset}{\bindingoffset}{7mm}% % \globaldefs = 0 } >From rearnsha@arm.com Wed Jul 05 02:37:00 2000 From: Richard Earnshaw To: Andrew Cagney Cc: rearnsha@arm.com Subject: Re: ARM frame fp is not always FP_REGNUM Date: Wed, 05 Jul 2000 02:37:00 -0000 Message-id: <200007050936.KAA06640@cam-mail2.cambridge.arm.com> References: <396298DC.4543E9BF@cygnus.com> X-SW-Source: 2000-07/msg00046.html Content-length: 1260 > > > > Huh??? FP_REGNUM refers to a register. > > The "fp" that is displayed by "info registers" sometimes > > refers to gdb's internal pseudo-frame or virtual frame location, > > but the constant FP_REGNUM is a real hardware register. > > I read it as the hardware or pseudo register that directly corresponds > to GDB's ``$fp'' pseudo register. parse.c:build_parse() maps $fp -> > FP_REGNUM. (mental note, fix buffer overrun in build_parse()). Some > targets have a real $fp (ARM, VAX) so the obvious thing to do was to map > FP_REGNUM onto the real register. Other targets don't have a real $fp > so it is mapped onto a pseudo register (MIPS). > > As Alexandre pointed out, things relied on pseudo-$fp <-> FP_REGNUM <-> > frame->frame <-> hardware-$fp but in modern times, with frameless > functions, this makes little sense. > > My reading of the doco is that, when the target has a true hardware $fp, > then the pseudo $fp register shouldn't be provided. Per other e-mail, I > think this can be implemented by invalidating FP_REGNUM (set it to -1) > and instead provide read_fp() and write_fp(). On ARM, FP is a well-known alias for R11. Giving the value of any register other than r11 if the user types $fp would be *very* misleading. R.