From: Eli Zaretskii <eliz@gnu.org>
To: Fernando Nasser <fnasser@cygnus.com>
Cc: DJ Delorie <dj@delorie.com>,
gdb-patches@sourceware.cygnus.com,
Michael Snyder <msnyder@cygnus.com>
Subject: Re: Shell escape in the DJGPP port of GDB
Date: Sun, 22 Aug 1999 03:14:00 -0000 [thread overview]
Message-ID: <199908221014.GAA04181@mescaline.gnu.org> (raw)
In-Reply-To: <199908202013.QAA26688@envy.delorie.com>
> One more question: is it really necessary to put the chdir() call under
> ifdef __DJGPP__ or is it just for saving time when it is not necessary?
Actually, I *did* have a reason for #ifdef'ing that call to chdir.
But it wasn't performance what I was thinking about. My reason was
that on all DOS/Windows systems chdir doesn't change the current
drive. So, if GDB called `system' when the current working directory
was "d:/foo/bar", and whatever program(s) that were run by `system'
changed to a directory "c:/usr/bin", then calling chdir won't return
you to "d:/foo/bar" without an additional system call which switches
to drive D: as well. DJGPP's chdir does that automagically.
I didn't want this problem to be swept under the carpet when (and if)
the source is compiled with anything other than DJGPP. If I left
chdir there for non-DJGPP environments, they would only see the bug in
the rare cases that the drive is changed during `system', which makes
the bug much less visible and harder to debug.
Of course, if DJGPP is the only environment that is supposed to use
this branch of code, then the #ifdef can be safely removed.
From ac131313@cygnus.com Mon Aug 23 03:15:00 1999
From: Andrew Cagney <ac131313@cygnus.com>
To: gdb-patches@sourceware.cygnus.com
Subject: For review: build libgdb.a and then build gdb
Date: Mon, 23 Aug 1999 03:15:00 -0000
Message-id: <37C11D42.62D71737@cygnus.com>
X-SW-Source: 1999-q3/msg00202.html
Content-length: 4127
Hello,
The attached patch changes the final GDB build into a two stage process
- build a library and then link GDB against that. The final objective
is to simplify the task of integrating things like insight.
At the same time I flushed a few remaining references to the old libgdb.
Andrew
Mon Aug 23 19:36:17 1999 Andrew Cagney <cagney@b1.cygnus.com>
* Makefile.in (libgdb.a): New target.
(gdb$(EXEEXT)): Add dependency on libgdb.a.
(libgdb-files, LIBGDB_OBS, libgdb, LIBGDBDEPS, LIBGDBFILES):
Delete.
Index: Makefile.in
===================================================================
RCS file: /cvs/cvsfiles/devo/gdb/Makefile.in,v
retrieving revision 1.687
diff -p -r1.687 Makefile.in
*** Makefile.in 1999/08/16 20:42:54 1.687
--- Makefile.in 1999/08/23 10:05:16
*************** COMMON_OBS = version.o blockframe.o brea
*** 606,615 ****
c-valprint.o cp-valprint.o ch-valprint.o f-valprint.o m2-valprint.o \
nlmread.o serial.o mdebugread.o os9kread.o top.o utils.o
! OBS = $(COMMON_OBS) $(ANNOTATE_OBS) main.o
- LIBGDB_OBS =
-
TSOBS = inflow.o
NTSOBS = standalone.o
--- 606,613 ----
c-valprint.o cp-valprint.o ch-valprint.o f-valprint.o m2-valprint.o \
nlmread.o serial.o mdebugread.o os9kread.o top.o utils.o
! OBS = $(COMMON_OBS) $(ANNOTATE_OBS)
TSOBS = inflow.o
NTSOBS = standalone.o
*************** init.c: $(OBS) $(TSOBS)
*** 747,774 ****
.PRECIOUS: init.c
# Removing the old gdb first works better if it is running, at least on SunOS.
! gdb$(EXEEXT): $(OBS) $(BUILD_TUI) $(TSOBS) $(ADD_DEPS) $(CDEPS) init.o
rm -f gdb$(EXEEXT)
! $(HLDENV) $(CC_LD) $(INTERNAL_LDFLAGS) $(WIN32LDAPP) -o gdb$(EXEEXT) \
! init.o $(OBS) $(TSOBS) $(TUI_LIBRARY) $(ADD_FILES) $(CLIBS) $(LOADLIBES)
nlm: force
rootme=`pwd`; export rootme; $(MAKE) $(TARGET_FLAGS_TO_PASS) DO=all DODIRS=nlm subdir_do
-
- libgdb: libgdb-files $(LIBGDB_OBS)
! # libproc is not listed here because all-libproc is a dependency of all-gui,
! # not all-gdb, and thus might be built after us.
! LIBGDBDEPS=$(COMMON_OBS) $(LIBGDB_OBS) $(TSOBS) $(ADD_DEPS) $(CDEPS) init.o
! # libproc needs to be before libiberty for alloca.
! LIBGDBFILES=$(COMMON_OBS) $(LIBGDB_OBS) $(TSOBS) ../libproc/libproc.a \
! $(ADD_DEPS) $(CDEPS) init.o
!
! libgdb-files: $(LIBGDBDEPS) Makefile.in
! -rm -f libgdb-files
! for i in $(LIBGDBFILES); do\
! echo $$i >> libgdb-files;\
! done
saber_gdb: $(SFILES) $(DEPFILES) copying.c version.c
#setopt load_flags $(CFLAGS) $(BFD_CFLAGS) -DHOST_SYS=SUN4_SYS
--- 745,766 ----
.PRECIOUS: init.c
# Removing the old gdb first works better if it is running, at least on SunOS.
! gdb$(EXEEXT): libgdb.a $(ADD_DEPS) $(CDEPS)
rm -f gdb$(EXEEXT)
! $(HLDENV) $(CC_LD) $(INTERNAL_LDFLAGS) $(WIN32LDAPP) -o gdb$(EXEEXT) main.o libgdb.a $(TUI_LIBRARY) $(CLIBS) $(LOADLIBES)
nlm: force
rootme=`pwd`; export rootme; $(MAKE) $(TARGET_FLAGS_TO_PASS) DO=all DODIRS=nlm subdir_do
! # Create a library of the gdb object files and build GDB by linking
! # against that.
! #
! # init.o is very important. It pulls in the rest of GDB.
! LIBGDB_OBS= $(OBS) $(TSOBS) $(ADD_FILES) init.o
! libgdb.a: $(LIBGDB_OBS)
! -rm -f libgdb.a
! $(AR) q libgdb.a $(LIBGDB_OBS)
! $(RANLIB) libgdb.a
saber_gdb: $(SFILES) $(DEPFILES) copying.c version.c
#setopt load_flags $(CFLAGS) $(BFD_CFLAGS) -DHOST_SYS=SUN4_SYS
*************** clean mostlyclean:
*** 858,864 ****
@$(MAKE) $(FLAGS_TO_PASS) DO=clean "DODIRS=$(SUBDIRS)" subdir_do
rm -f *.o *.a $(ADD_FILES) *~ init.c-tmp
rm -f init.c version.c
! rm -f gdb$(EXEEXT) core make.log libgdb-files
rm -f gdb[0-9]$(EXEEXT)
# This used to depend on c-exp.tab.c m2-exp.tab.c TAGS
--- 850,856 ----
@$(MAKE) $(FLAGS_TO_PASS) DO=clean "DODIRS=$(SUBDIRS)" subdir_do
rm -f *.o *.a $(ADD_FILES) *~ init.c-tmp
rm -f init.c version.c
! rm -f gdb$(EXEEXT) core make.log
rm -f gdb[0-9]$(EXEEXT)
# This used to depend on c-exp.tab.c m2-exp.tab.c TAGS
prev parent reply other threads:[~1999-08-22 3:14 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <37BDA912.4AA1190D@cygnus.com>
1999-08-20 12:20 ` DJ Delorie
[not found] ` <37BDAD71.510A96A1@cygnus.com>
[not found] ` <199908202005.QAA26613@envy.delorie.com>
[not found] ` <37BDB5E2.4318@cygnus.com>
[not found] ` <199908202013.QAA26688@envy.delorie.com>
1999-08-22 3:14 ` Eli Zaretskii [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=199908221014.GAA04181@mescaline.gnu.org \
--to=eliz@gnu.org \
--cc=dj@delorie.com \
--cc=fnasser@cygnus.com \
--cc=gdb-patches@sourceware.cygnus.com \
--cc=msnyder@cygnus.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox