* [Patch 2/7]: 68HC11 port of gdb (sim)
@ 2000-06-25 13:36 Stephane Carrez
[not found] ` <200006260537.BAA09053@indy.delorie.com>
0 siblings, 1 reply; 2+ messages in thread
From: Stephane Carrez @ 2000-06-25 13:36 UTC (permalink / raw)
To: gdb-patches
[-- Attachment #1: Type: text/plain, Size: 1134 bytes --]
Hi!
This patch represents the 68hc11 simulator. I've compressed the patch
because there are the following new files:
gdb/sim/m68hc11/ChangeLog
gdb/sim/m68hc11/config.in
gdb/sim/m68hc11/configure.in
gdb/sim/m68hc11/dv-m68hc11.c
gdb/sim/m68hc11/dv-m68hc11eepr.c
gdb/sim/m68hc11/dv-m68hc11sio.c
gdb/sim/m68hc11/dv-m68hc11spi.c
gdb/sim/m68hc11/dv-m68hc11tim.c
gdb/sim/m68hc11/dv-nvram.c
gdb/sim/m68hc11/emulos.c
gdb/sim/m68hc11/gencode.c
gdb/sim/m68hc11/interp.c
gdb/sim/m68hc11/interrupts.c
gdb/sim/m68hc11/interrupts.h
gdb/sim/m68hc11/m68hc11_sim.c
gdb/sim/m68hc11/sim-main.h
The file gdb/sim/m68hc11/dv-nvram.c is the non-volatile ram emulation.
This implementation is rather generic. It is in no way
dependent of the 68hc11. May be some day, it would be good
to move it to some common place.
There is a ChangeLog file in gdb/sim/m68hc11. It contains my ChangeLogs
starting from May 1999.
Stephane
Here is the ChangeLog for gdb/sim.
2000-06-25 Stephane Carrez <stcarrez@worldnet.fr>
* configure.in: Recognize m68hc11 target.
* configure: Regenerate.
sim-m68hc11.diffs.gz
[-- Attachment #2: sim-m68hc11.diffs.gz --]
[-- Type: application/x-gzip, Size: 46679 bytes --]
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: [Patch 2/7]: 68HC11 port of gdb (sim)
[not found] ` <200006260537.BAA09053@indy.delorie.com>
@ 2000-06-27 13:06 ` Stephane Carrez
0 siblings, 0 replies; 2+ messages in thread
From: Stephane Carrez @ 2000-06-27 13:06 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Stephane.Carrez, gdb-patches
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 20543 bytes --]
Hi!
Eli Zaretskii a écrit :
>
> > Date: Mon, 26 Jun 2000 00:38:33 +0200
> > From: Stephane Carrez <Stephane.Carrez@free.fr>
> >
> > This patch represents the 68hc11 simulator.
>
> Thanks!
>
> > gdb/sim/m68hc11/dv-m68hc11.c
> > gdb/sim/m68hc11/dv-m68hc11eepr.c
> > gdb/sim/m68hc11/dv-m68hc11sio.c
> > gdb/sim/m68hc11/dv-m68hc11spi.c
> > gdb/sim/m68hc11/dv-m68hc11tim.c
>
> The names of these 5 files all clash after truncation to DOS 8+3
> namespace limits, so they make it harder for users to unpack the GDB
> distribution on MS-DOS and Windows 3.X systems. Since these files are
> all in an m68hc11 subdirectory, I wonder whether you could remove the
> m68hc11 part from the file names altogether?
I've tried to follow the mips simulator where the file names are
dv-tx3904cpu.c
dv-tx3904irc.c
dv-tx3904sio.c
dv-tx3904tmr.c
and they have the same problem you pointed out (mn10300 either).
I understand a rationale to restrict to 14 characters, but 8 is too short.
Stephane
-----------------------------------------------------------------------
Home Office
E-mail: stcarrez@worldnet.fr Stephane.Carrez@sun.com
WWW: http://home.worldnet.fr/stcarrez http://www.sun.com
Mail: 17, rue Foucher Lepelletier 6, avenue Gustave Eiffel
92130 Issy Les Moulineaux 78182 Saint Quentin en Yvelines
France
From eliz@delorie.com Tue Jun 27 22:17:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: Stephane.Carrez@worldnet.fr
Cc: Stephane.Carrez@free.fr, gdb-patches@sourceware.cygnus.com
Subject: Re: [Patch 2/7]: 68HC11 port of gdb (sim)
Date: Tue, 27 Jun 2000 22:17:00 -0000
Message-id: <200006280517.BAA11564@indy.delorie.com>
References: <3959260D.DF114B91@worldnet.fr>
X-SW-Source: 2000-06/msg00313.html
Content-length: 1616
> Date: Wed, 28 Jun 2000 00:09:17 +0200
> From: Stephane Carrez <Stephane.Carrez@worldnet.fr>
> >
> > > gdb/sim/m68hc11/dv-m68hc11.c
> > > gdb/sim/m68hc11/dv-m68hc11eepr.c
> > > gdb/sim/m68hc11/dv-m68hc11sio.c
> > > gdb/sim/m68hc11/dv-m68hc11spi.c
> > > gdb/sim/m68hc11/dv-m68hc11tim.c
> >
> > The names of these 5 files all clash after truncation to DOS 8+3
> > namespace limits, so they make it harder for users to unpack the GDB
> > distribution on MS-DOS and Windows 3.X systems. Since these files are
> > all in an m68hc11 subdirectory, I wonder whether you could remove the
> > m68hc11 part from the file names altogether?
>
> I've tried to follow the mips simulator where the file names are
>
> dv-tx3904cpu.c
> dv-tx3904irc.c
> dv-tx3904sio.c
> dv-tx3904tmr.c
>
> and they have the same problem you pointed out (mn10300 either).
Yes, and they will all probably be changed in the future. But the
fact other files have the same problem is still not a good reason to
introduce new problems.
Each such file requires additions to scripts that fix the file-naming
problems on 8+3 filesystems, and it would be nice to avoid these
maintenanace headaches.
> I understand a rationale to restrict to 14 characters, but 8 is too short.
I don't see how so. If I remove the redundant parts from a name such
as dv-m68hc11eepr.c, I'm left with eepr.c, which still leaves a lot of
real estate to play with.
I respectfully request to try to avoid additional file-name related
problems when introducing new files. Solving these problems is a
long-term goal of the GDB maintenance. Thank you for your
cooperation.
From cgf@cygnus.com Thu Jun 29 22:06:00 2000
From: Chris Faylor <cgf@cygnus.com>
To: Eli Zaretskii <eliz@is.elta.co.il>
Cc: markh@frazier.landmark.com, gdb-patches@sourceware.cygnus.com, markh@saturn.landmark.com
Subject: Re: gdb-5.0/gdb/doc/Makefile.in patch -- is this patch really correct?
Date: Thu, 29 Jun 2000 22:06:00 -0000
Message-id: <20000630010635.A14862@cygnus.com>
References: <200006231835.OAA07083@fwr.landmark.com> <200006250818.EAA07995@indy.delorie.com>
X-SW-Source: 2000-06/msg00314.html
Content-length: 2915
On Sun, Jun 25, 2000 at 04:18:17AM -0400, Eli Zaretskii wrote:
>> From: markh@frazier.landmark.com
>> Date: Fri, 23 Jun 2000 14:35:24 -0400
>>
>> Here is a patch file to fix a bug in the 'install-info' target. The
>> target does not work correctly if the debugger is being built in a
>> directory other than the source directory.
>
>Thanks, I committed this to the trunk.
I've just been bitten by this patch and I don't really understand it.
The .info files that should be installed come from the build directory
not from the source directory. I don't see any .info* files in gdb/doc
at all.
I noticed this while producing a cygwin net release. "make install-info"
complained about the lack of *.info* files to install.
Here are the contents of my build 'doc' directory:
GDBvn.texi gdb-cfg.texi gdb.info-11 gdb.info-3 gdb.info-7 gdbint.info-1 stabs.info-1
Makefile gdb.info gdb.info-12 gdb.info-4 gdb.info-8 gdbint.info-2 stabs.info-2
config.log gdb.info-1 gdb.info-13 gdb.info-5 gdb.info-9 gdbint.info-3 stabs.info-3
config.status gdb.info-10 gdb.info-2 gdb.info-6 gdbint.info stabs.info stabs.info-4
And this is the source directory:
CVS Makefile.in agentexpr.texi configure gdbgui.texinfo lpsrc.sed stabs.texinfo
ChangeLog Makefile.in.orig all-cfg.texi configure.in gdbint.texinfo psrc.sed
LRS a4rc.sed annotate.texi gdb.texinfo libgdb.texinfo refcard.tex
There are *.texinfo files here but no *.info files.
It seems to me that the previous code was correct and should have worked
whether you were building in the same directory as the source or not.
cgf
>> I think that the same bug
>> exists for the 'install-html' target, but I did not pursue this because
>> I did not find any .html files in the gdb distribution.
>
>No, the install-html target doesn't need this change, because the
>*.html files are not part of the distribution. If someone wants to
>install them, they will have to be generated first, in which case they
>are created in the same directory where GDB is built. Thus no need to
>chdir to $(srcdir) in that case.
>
>>
>> diff -u2 Makefile.in.orig Makefile.in
>> --- Makefile.in.orig Wed May 17 07:54:04 2000
>> +++ Makefile.in Tue Jun 20 12:24:48 2000
>> @@ -115,7 +115,8 @@
>> install-info: info
>> $(SHELL) $(srcdir)/../../mkinstalldirs $(infodir)
>> + (cd $(srcdir); \
>> for i in *.info* ; do \
>> $(INSTALL_DATA) $$i $(infodir)/$$i ; \
>> - done
>> + done)
>> @if $(SHELL) -c 'install-info --version | sed 1q | fgrep -s -v -i debian' >/dev/null 2>&1; then \
>> list='gdb.info gdbint.info stabs.info'; \
>>
>> --
>> ## Mark Harig
>> ## Landmark Systems, Reston, Virginia, USA
>> ## Email: mharig@landmark.com
>>
--
cgf@cygnus.com Cygnus Solutions, a Red Hat company
http://sourceware.cygnus.com/ http://www.redhat.com/
From geoffk@desire.geoffk.org Fri Jun 30 00:53:00 2000
From: Geoff Keating <geoffk@desire.geoffk.org>
To: gdb-patches@sourceware.cygnus.com
Subject: gdb doesn't build sparc-solaris X powerpc-eabi
Date: Fri, 30 Jun 2000 00:53:00 -0000
Message-id: <200006300753.AAA03954@desire.geoffk.org>
X-SW-Source: 2000-06/msg00315.html
Content-length: 1822
I get this:
gcc -c -g -O2 -I. -I/a/bluey/bluey/geoffk/co/binutils-mainline/src/gdb -I/a/bluey/bluey/geoffk/co/binutils-mainline/src/gdb/config -DHAVE_CONFIG_H -I/a/bluey/bluey/geoffk/co/binutils-mainline/src/gdb/../include/opcode -I/a/bluey/bluey/geoffk/co/binutils-mainline/src/gdb/../readline/.. -I../bfd -I/a/bluey/bluey/geoffk/co/binutils-mainline/src/gdb/../bfd -I/a/bluey/bluey/geoffk/co/binutils-mainline/src/gdb/../include -I../intl -I/a/bluey/bluey/geoffk/co/binutils-mainline/src/gdb/../intl -Wimplicit -Wreturn-type -Wcomment -Wtrigraphs -Wformat -Wparentheses -Wpointer-arith -Wuninitialized /a/bluey/bluey/geoffk/co/binutils-mainline
/a/bluey/bluey/geoffk/co/binutils-mainline/src/gdb/rs6000-tdep.c:60: warning: `DEFAULT_LR_SAVE' redefined
tm.h:31: warning: this is the location of the previous definition
/a/bluey/bluey/geoffk/co/binutils-mainline/src/gdb/rs6000-tdep.c: In function `skip_prologue':
/a/bluey/bluey/geoffk/co/binutils-mainline/src/gdb/rs6000-tdep.c:395: warning: `last_prologue_pc' might be used uninitialized in this function
/a/bluey/bluey/geoffk/co/binutils-mainline/src/gdb/rs6000-tdep.c: At top level:
/a/bluey/bluey/geoffk/co/binutils-mainline/src/gdb/rs6000-tdep.c:689: conflicting types for `rs6000_pop_frame'
tm.h:57: previous declaration of `rs6000_pop_frame'
/a/bluey/bluey/geoffk/co/binutils-mainline/src/gdb/rs6000-tdep.c:994: warning: static declaration for `ppc_push_return_address' follows non-static
with today's (well, yesterday's, but a few hours ago) sourceware CVS,
configured on my sparc-sun-solaris2.6 box "sloth" with
/a/bluey/bluey/geoffk/co/binutils-mainline/src/configure --prefix=/sloth/delay/tbox/objs-20000630T053227Z --target=powerpc-eabisim
Is someone actively working on this, or should I submit a patch?
--
- Geoffrey Keating <geoffk@cygnus.com>
From eliz@delorie.com Fri Jun 30 01:47:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: cgf@cygnus.com
Cc: markh@frazier.landmark.com, gdb-patches@sourceware.cygnus.com, markh@saturn.landmark.com
Subject: Re: gdb-5.0/gdb/doc/Makefile.in patch -- is this patch really correct?
Date: Fri, 30 Jun 2000 01:47:00 -0000
Message-id: <200006300846.EAA14373@indy.delorie.com>
References: <200006231835.OAA07083@fwr.landmark.com> <200006250818.EAA07995@indy.delorie.com> <20000630010635.A14862@cygnus.com>
X-SW-Source: 2000-06/msg00316.html
Content-length: 893
> From: Chris Faylor <cgf@cygnus.com>
> Date: Fri, 30 Jun 2000 01:06:35 -0400
>
> I've just been bitten by this patch and I don't really understand it.
>
> The .info files that should be installed come from the build directory
> not from the source directory. I don't see any .info* files in gdb/doc
> at all.
Did you look in the source distribution on ftp.gnu.org, or somewhere
else? I just looked in the GDB 5.0 distribution as downloaded from
the GNU site, and the Info files are there in gdb/doc directory.
I believe the GNU standards require that source distributions come
with Info files, so that end users won't need to run `makeinfo' to
produce them.
In addition, the *diff.bz2 files for the snapshots include diffs for
the *.info* files as well. So it seems that you should have had the
Info files in the source directory. Can you try to understand why you
didn't have them?
From cgf@cygnus.com Fri Jun 30 07:19:00 2000
From: Chris Faylor <cgf@cygnus.com>
To: Eli Zaretskii <eliz@is.elta.co.il>
Cc: markh@frazier.landmark.com, gdb-patches@sourceware.cygnus.com, markh@saturn.landmark.com
Subject: Re: gdb-5.0/gdb/doc/Makefile.in patch -- is this patch really correct?
Date: Fri, 30 Jun 2000 07:19:00 -0000
Message-id: <20000630101845.A5618@cygnus.com>
References: <200006231835.OAA07083@fwr.landmark.com> <200006250818.EAA07995@indy.delorie.com> <20000630010635.A14862@cygnus.com> <200006300846.EAA14373@indy.delorie.com>
X-SW-Source: 2000-06/msg00317.html
Content-length: 1501
On Fri, Jun 30, 2000 at 04:46:53AM -0400, Eli Zaretskii wrote:
>> From: Chris Faylor <cgf@cygnus.com>
>> Date: Fri, 30 Jun 2000 01:06:35 -0400
>>
>> I've just been bitten by this patch and I don't really understand it.
>>
>> The .info files that should be installed come from the build directory
>> not from the source directory. I don't see any .info* files in gdb/doc
>> at all.
>
>Did you look in the source distribution on ftp.gnu.org, or somewhere
>else? I just looked in the GDB 5.0 distribution as downloaded from
>the GNU site, and the Info files are there in gdb/doc directory.
I looked in the directory that I've checked out via CVS. AFAICT, there are
no *.info files there.
Ok. I've logged into sourceware and looked in the gdb/doc directory.
No info files there either.
>I believe the GNU standards require that source distributions come
>with Info files, so that end users won't need to run `makeinfo' to
>produce them.
Even if that is the case, since the Makefile builds the info files in
the build directory via the 'gdb.info' rule, blindly cd'ing to the
source directory can't be the correct way to handle this.
IMO, the files should be found VPATH.
>In addition, the *diff.bz2 files for the snapshots include diffs for
>the *.info* files as well. So it seems that you should have had the
>Info files in the source directory. Can you try to understand why you
>didn't have them?
I don't have them because I don't download snapshots. As a GDB developer,
I use CVS.
cgf
From cgf@cygnus.com Fri Jun 30 07:33:00 2000
From: Chris Faylor <cgf@cygnus.com>
To: Eli Zaretskii <eliz@is.elta.co.il>, markh@frazier.landmark.com, gdb-patches@sourceware.cygnus.com, markh@saturn.landmark.com
Subject: [RFA] Use VPATH to find info files for installation.
Date: Fri, 30 Jun 2000 07:33:00 -0000
Message-id: <20000630103304.B5618@cygnus.com>
References: <200006231835.OAA07083@fwr.landmark.com> <200006250818.EAA07995@indy.delorie.com> <20000630010635.A14862@cygnus.com> <200006300846.EAA14373@indy.delorie.com> <20000630101845.A5618@cygnus.com>
X-SW-Source: 2000-06/msg00318.html
Content-length: 2303
On Fri, Jun 30, 2000 at 10:18:45AM -0400, Chris Faylor wrote:
>Even if that is the case, since the Makefile builds the info files in
>the build directory via the 'gdb.info' rule, blindly cd'ing to the
>source directory can't be the correct way to handle this.
>
>IMO, the files should be found VPATH.
How about this?
cgf
Fri Jun 30 10:26:38 2000 Christopher Faylor <cgf@cygnus.com>
* Makefile.in (install-info): Find files to install via VPATH since
info files can be in either the source or the build directory.
Index: Makefile.in
===================================================================
RCS file: /cvs/src/src/gdb/doc/Makefile.in,v
retrieving revision 1.10
diff -u -p -r1.10 Makefile.in
--- Makefile.in 2000/06/25 08:12:30 1.10
+++ Makefile.in 2000/06/30 14:32:01
@@ -62,6 +62,9 @@ GDBMI_DIR = ${gdbdir}/mi
SET_TEXINPUTS = \
TEXINPUTS=${TEXIDIR}:.:$(srcdir):$(READLINE_DIR):$(GDBMI_DIR):$$TEXINPUTS
+# Files which should be generated via 'info' and installed by 'install-info'
+INFO_FILES = gdb.info gdbint.info stabs.info
+
# There may be alternate predefined collections of switches to configure
# the GDB manual. Normally this is not done in synch with the software
# config system, since this choice tends to be independent; most people
@@ -108,7 +111,7 @@ SFILES_DOC = $(SFILES_LOCAL) $(GDBMI_DIR
all install:
-info: gdb.info gdbint.info stabs.info
+info: $(INFO_FILES)
dvi: gdb.dvi gdbint.dvi stabs.dvi refcard.dvi
ps: gdb.ps gdbint.ps stabs.ps refcard.ps
html: gdb_toc.html gdbint_toc.html stabs_toc.html
@@ -116,15 +119,15 @@ pdf: gdb.pdf gdbint.pdf stabs.pdf
all-doc: info dvi ps # pdf
diststuff: info
-install-info: info
+install-info: $(INFO_FILES)
$(SHELL) $(srcdir)/../../mkinstalldirs $(infodir)
- (cd $(srcdir); \
- for i in *.info* ; do \
- $(INSTALL_DATA) $$i $(infodir)/$$i ; \
- done)
+ for j in $?; do \
+ for i in $$i*; do \
+ $(INSTALL_DATA) $$i $(infodir)/$$i ; \
+ done; \
+ done
@if $(SHELL) -c 'install-info --version | sed 1q | fgrep -s -v -i debian' >/dev/null 2>&1; then \
- list='gdb.info gdbint.info stabs.info'; \
- for file in $$list; do \
+ for file in $?; do \
echo " install-info --info-dir=$(infodir) $(infodir)/$$file";\
install-info --info-dir=$(infodir) $(infodir)/$$file || :;\
done; \
From nsd@redhat.com Fri Jun 30 08:59:00 2000
From: Nick Duffek <nsd@redhat.com>
To: geoffk@desire.geoffk.org
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: gdb doesn't build sparc-solaris X powerpc-eabi
Date: Fri, 30 Jun 2000 08:59:00 -0000
Message-id: <200006301559.LAA04746@nog.bosbc.com>
References: <200006300753.AAA03954@desire.geoffk.org>
X-SW-Source: 2000-06/msg00319.html
Content-length: 3930
On 30-Jun-2000, Geoff Keating wrote:
>Is someone actively working on this, or should I submit a patch?
Recently I posted the appended patch under the subject "Re: recent gdb
changes break powerpc-eabi target?", but I haven't yet received
confirmation that it works. Would you mind trying it?
Nick
Index: gdb/rs6000-tdep.c
===================================================================
diff -up gdb/rs6000-tdep.c gdb/rs6000-tdep.c
--- gdb/rs6000-tdep.c Tue Jun 20 21:19:07 2000
+++ gdb/rs6000-tdep.c Tue Jun 20 21:17:27 2000
@@ -56,9 +56,6 @@
#define SIG_FRAME_LR_OFFSET 108
#define SIG_FRAME_FP_OFFSET 284
-/* Default offset from SP where the LR is stored */
-#define DEFAULT_LR_SAVE 8
-
/* To be used by skip_prologue. */
struct rs6000_framedata
@@ -2048,7 +2045,7 @@ rs6000_gdbarch_init (struct gdbarch_info
set_gdbarch_call_dummy_breakpoint_offset_p (gdbarch, 1);
set_gdbarch_call_dummy_breakpoint_offset (gdbarch, 0);
set_gdbarch_call_dummy_start_offset (gdbarch, 0);
- set_gdbarch_pc_in_call_dummy (gdbarch, rs6000_pc_in_call_dummy);
+ set_gdbarch_pc_in_call_dummy (gdbarch, generic_pc_in_call_dummy);
set_gdbarch_call_dummy_p (gdbarch, 1);
set_gdbarch_call_dummy_stack_adjust_p (gdbarch, 0);
set_gdbarch_get_saved_register (gdbarch, generic_get_saved_register);
Index: gdb/config/rs6000/tm-rs6000.h
===================================================================
diff -up gdb/config/rs6000/tm-rs6000.h gdb/config/rs6000/tm-rs6000.h
--- gdb/config/rs6000/tm-rs6000.h Tue Jun 20 21:19:13 2000
+++ gdb/config/rs6000/tm-rs6000.h Tue Jun 20 21:18:24 2000
@@ -94,6 +94,9 @@ extern void aix_process_linenos (void);
prev->next ? FRAME_SAVED_PC (prev->next) : read_pc ());
#define INIT_FRAME_PC(fromleaf, prev) /* nothing */
+/* Default offset from SP where the LR is stored */
+#define DEFAULT_LR_SAVE 8
+
/* Usually a function pointer's representation is simply the address
of the function. On the RS/6000 however, a function pointer is
represented by a pointer to a TOC entry. This TOC entry contains
Index: gdb/config/powerpc/tm-ppc-eabi.h
===================================================================
diff -up gdb/config/powerpc/tm-ppc-eabi.h gdb/config/powerpc/tm-ppc-eabi.h
--- gdb/config/powerpc/tm-ppc-eabi.h Tue Jun 20 21:19:23 2000
+++ gdb/config/powerpc/tm-ppc-eabi.h Tue Jun 20 21:17:58 2000
@@ -30,8 +30,6 @@
#undef DEFAULT_LR_SAVE
#define DEFAULT_LR_SAVE 4 /* eabi saves LR at 4 off of SP */
-#define GDB_TARGET_POWERPC
-
#undef PC_LOAD_SEGMENT
#undef PROCESS_LINENUMBER_HOOK
@@ -42,38 +40,6 @@
#define ELF_OBJECT_FORMAT 1
#define TARGET_BYTE_ORDER_SELECTABLE_P 1
-
-/* return true if a given `pc' value is in `call dummy' function. */
-/* FIXME: This just checks for the end of the stack, which is broken
- for things like stepping through gcc nested function stubs. */
-#undef PC_IN_CALL_DUMMY
-
-/* generic dummy frame stuff */
-
-
-
-/* target-specific dummy_frame stuff */
-
-extern struct frame_info *rs6000_pop_frame (struct frame_info *frame);
-
-extern CORE_ADDR ppc_push_return_address (CORE_ADDR, CORE_ADDR);
-
-#undef PUSH_DUMMY_FRAME
-#define PUSH_DUMMY_FRAME generic_push_dummy_frame ()
-
-#define PUSH_RETURN_ADDRESS(PC, SP) ppc_push_return_address (PC, SP)
-
-/* override the standard get_saved_register function with
- one that takes account of generic CALL_DUMMY frames */
-#define GET_SAVED_REGISTER(raw_buffer, optimized, addrp, frame, regnum, lval) \
- generic_get_saved_register (raw_buffer, optimized, addrp, frame, regnum, lval)
-
-#define USE_GENERIC_DUMMY_FRAMES 1
-#define CALL_DUMMY_BREAKPOINT_OFFSET (0)
-#define CALL_DUMMY_LOCATION AT_ENTRY_POINT
-#define CALL_DUMMY_ADDRESS() entry_point_address ()
-#undef CALL_DUMMY_START_OFFSET
-#define CALL_DUMMY_START_OFFSET 0
/* The value of symbols of type N_SO and N_FUN maybe null when
it shouldn't be. */
From guo@cup.hp.com Fri Jun 30 09:26:00 2000
From: Jimmy Guo <guo@cup.hp.com>
To: Chris Faylor <cgf@cygnus.com>
Cc: Eli Zaretskii <eliz@is.elta.co.il>, markh@frazier.landmark.com, gdb-patches@sourceware.cygnus.com, markh@saturn.landmark.com
Subject: Re: [RFA] Use VPATH to find info files for installation.
Date: Fri, 30 Jun 2000 09:26:00 -0000
Message-id: <Pine.LNX.4.10.10006300924310.29205-100000@hpcll168.cup.hp.com>
References: <20000630103304.B5618@cygnus.com>
X-SW-Source: 2000-06/msg00320.html
Content-length: 162
>+ for j in $?; do \
>+ for i in $$i*; do \
^^^^
$$j*?
>+ $(INSTALL_DATA) $$i $(infodir)/$$i ; \
>+ done; \
>+ done
- Jimmy Guo, guo@cup.hp.com
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2000-06-27 13:06 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-06-25 13:36 [Patch 2/7]: 68HC11 port of gdb (sim) Stephane Carrez
[not found] ` <200006260537.BAA09053@indy.delorie.com>
2000-06-27 13:06 ` Stephane Carrez
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox