From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephane Carrez To: Eli Zaretskii 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 13:06:00 -0000 Message-id: <3959260D.DF114B91@worldnet.fr> References: <395689E9.2E071E0@free.fr> <200006260537.BAA09053@indy.delorie.com> X-SW-Source: 2000-06/msg00312.html Hi! Eli Zaretskii a écrit : > > > Date: Mon, 26 Jun 2000 00:38:33 +0200 > > From: Stephane Carrez > > > > 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 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 > > > > > 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 To: Eli Zaretskii 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 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 >From eliz@delorie.com Fri Jun 30 01:47:00 2000 From: Eli Zaretskii 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 > 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 To: Eli Zaretskii 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 >> 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 To: Eli Zaretskii , 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 * 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 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 To: Chris Faylor Cc: Eli Zaretskii , 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: 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