Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Fernando Nasser <fnasser@cygnus.com>
To: Mark Kettenis <kettenis@wins.uva.nl>
Cc: gdb@sourceware.cygnus.com
Subject: 14 chars limit [Was: Re: Moving Linux-specific stuff out of i386-tdep.c]
Date: Sat, 01 Apr 2000 00:00:00 -0000	[thread overview]
Message-ID: <38C6D2DC.44C3FC6@cygnus.com> (raw)
In-Reply-To: <200003082121.e28LLRu05681@delius.kettenis.local>

Mark Kettenis wrote:
> 
> 1. Do we still care about the filename limits of older System V
>    systems?  i386-linux-nat.c is longer than 14 characters which is a
>    no-no according to the GNU conding standards.
> 

There are several files now with 14+ chars.  I am just about to add one (with 16).

Is this still relevant?

-- 
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 hjl@valinux.com Sat Apr 01 00:00:00 2000
From: "H . J . Lu" <hjl@valinux.com>
To: Stan Shebs <shebs@apple.com>
Cc: gdb-patches@sourceware.cygnus.com, GDB <gdb@sourceware.cygnus.com>
Subject: Re: A patch for gnu-regex
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <20000307155806.A30106@valinux.com>
References: <20000307134103.A20533@valinux.com> <38C585BB.3F7B1AC7@apple.com>
X-SW-Source: 2000-q1/msg00572.html
Content-length: 6084

On Tue, Mar 07, 2000 at 02:42:02PM -0800, Stan Shebs wrote:
> "H . J . Lu" wrote:
> > 
> > I believe gnu-regex is maintained in glibc 2. I'd like to use the one
> > in glibc 2 instead of the one in gdb.
> 
> I don't know if there is any more elegant way to handle the linux.mh vs
> linuxlibc1.mh distinction (although we should try, instead of making
> still more file semi-clones), but you could simplify the source files by
> making a gdb_regex.h similar to the other gdb_*.h substitute files, and
> put the #if sequence in it.
> 

Here is a new patch.


-- 
H.J. Lu (hjl@gnu.org)
---
2000-03-07  H.J. Lu  <hjl@gnu.org>

	* gdb-regex.h: New. Include <regex.h> for glibc 2 and include
	"gnu-regex.h" otherwise.

        * irix5-nat.c: Include "gdb-regex.h" instead of "gnu-regex.h".
	* monitor.c: Likewise.
	* osfsolib.c: Likewise.
	* solib.c: Likewise.
	* source.c: Likewise.
	* symtab.c: Likewise.

	* Makefile.in (REGEX): Changed to @REGEX@.
	(REGEX1): Removed.
	(ADD_DEPS): Use $(REGEX) instead of $(REGEX1).

	* configure.in (REGEX): New. Subsstitue @REGEX@ in Makefile.in.
	* configure: Regenerated.

Index: Makefile.in
===================================================================
RCS file: /work/cvs/gnu/gdb/gdb/Makefile.in,v
retrieving revision 1.1.1.9
diff -u -p -r1.1.1.9 Makefile.in
--- Makefile.in	2000/03/07 18:42:08	1.1.1.9
+++ Makefile.in	2000/03/07 23:28:45
@@ -285,8 +290,7 @@ HLDENV = @HLDENV@
 
 # We are using our own version of REGEX now to be consistent across
 # machines.
-REGEX = gnu-regex.o
-REGEX1 = gnu-regex.o
+REGEX = @REGEX@
 
 # If your system is missing alloca(), or, more likely, it's there but
 # it doesn't work, then refer to libiberty.
@@ -308,7 +312,7 @@ CDEPS = $(XM_CDEPS) $(TM_CDEPS) $(NAT_CD
 	$(OPCODES) $(MMALLOC) $(INTL_DEPS) $(LIBIBERTY) $(CONFIG_DEPS)
 
 ADD_FILES = $(REGEX) $(XM_ADD_FILES) $(TM_ADD_FILES) $(NAT_ADD_FILES)
-ADD_DEPS = $(REGEX1) $(XM_ADD_FILES) $(TM_ADD_FILES) $(NAT_ADD_FILES)
+ADD_DEPS = $(REGEX) $(XM_ADD_FILES) $(TM_ADD_FILES) $(NAT_ADD_FILES)
 
 VERSION = 20000204
 DIST=gdb
Index: configure.in
===================================================================
RCS file: /work/cvs/gnu/gdb/gdb/configure.in,v
retrieving revision 1.1.1.6
diff -u -p -r1.1.1.6 configure.in
--- configure.in	2000/03/07 18:42:10	1.1.1.6
+++ configure.in	2000/03/07 23:47:24
@@ -101,6 +101,24 @@ AC_C_CONST
 AC_CHECK_FUNCS(setpgid sbrk sigaction isascii bzero bcopy btowc poll sigprocmask)
 AC_FUNC_ALLOCA
 
+dnl See if we have GNU regex in glibc 2.
+AC_MSG_CHECKING(for GNU regex in glibc 2)
+AC_CACHE_VAL(gdb_cv_have_glibc_2,
+[AC_TRY_COMPILE([#include <features.h>],
+[#if !defined __GLIBC__ || __GLIBC__ < 2
+#error It is not glibc 2.
+#endif
+],
+		[gdb_cv_have_glibc_2=yes],
+		[gdb_cv_have_glibc_2=no])])
+AC_MSG_RESULT($gdb_cv_have_glibc_2)
+if test $gdb_cv_have_glibc_2 = yes; then
+  REGEX=
+else
+  REGEX="gnu-regex.o"
+fi
+AC_SUBST(REGEX)
+
 dnl See if ptrace.h provides the PTRACE_GETREGS request.
 AC_MSG_CHECKING(for PTRACE_GETREGS)
 AC_CACHE_VAL(gdb_cv_have_ptrace_getregs,
--- /dev/null	Tue May  5 13:32:27 1998
+++ gdb-regex.h	Tue Mar  7 15:47:50 2000
@@ -0,0 +1,7 @@
+#ifndef _GDB_REGEX_H
+#if defined __GLIBC__ && __GLIBC__ >= 2
+#include <regex.h>
+#else
+#include "gnu-regex.h"
+#endif
+#endif /* _GDB_REGEX_H */
Index: irix5-nat.c
===================================================================
RCS file: /work/cvs/gnu/gdb/gdb/irix5-nat.c,v
retrieving revision 1.1.1.3
diff -u -p -r1.1.1.3 irix5-nat.c
--- irix5-nat.c	1999/11/19 23:38:46	1.1.1.3
+++ irix5-nat.c	2000/03/07 23:24:47
@@ -278,7 +278,7 @@ fetch_core_registers (core_reg_sect, cor
 #include "objfiles.h"
 #include "command.h"
 #include "frame.h"
-#include "gnu-regex.h"
+#include "gdb-regex.h"
 #include "inferior.h"
 #include "language.h"
 #include "gdbcmd.h"
Index: monitor.c
===================================================================
RCS file: /work/cvs/gnu/gdb/gdb/monitor.c,v
retrieving revision 1.1.1.5
diff -u -p -r1.1.1.5 monitor.c
--- monitor.c	2000/03/07 18:42:14	1.1.1.5
+++ monitor.c	2000/03/07 23:24:50
@@ -50,7 +50,7 @@
 #include "monitor.h"
 #include "gdbcmd.h"
 #include "inferior.h"
-#include "gnu-regex.h"
+#include "gdb-regex.h"
 #include "dcache.h"
 #include "srec.h"
 
Index: osfsolib.c
===================================================================
RCS file: /work/cvs/gnu/gdb/gdb/osfsolib.c,v
retrieving revision 1.1.1.3
diff -u -p -r1.1.1.3 osfsolib.c
--- osfsolib.c	1999/11/19 23:38:50	1.1.1.3
+++ osfsolib.c	2000/03/07 23:24:55
@@ -36,7 +36,7 @@
 #include "command.h"
 #include "target.h"
 #include "frame.h"
-#include "gnu-regex.h"
+#include "gdb-regex.h"
 #include "inferior.h"
 #include "language.h"
 #include "gdbcmd.h"
Index: solib.c
===================================================================
RCS file: /work/cvs/gnu/gdb/gdb/solib.c,v
retrieving revision 1.1.1.4
diff -u -p -r1.1.1.4 solib.c
--- solib.c	2000/03/07 18:42:17	1.1.1.4
+++ solib.c	2000/03/07 23:25:01
@@ -49,7 +49,7 @@
 #include "command.h"
 #include "target.h"
 #include "frame.h"
-#include "gnu-regex.h"
+#include "gdb-regex.h"
 #include "inferior.h"
 #include "environ.h"
 #include "language.h"
Index: source.c
===================================================================
RCS file: /work/cvs/gnu/gdb/gdb/source.c,v
retrieving revision 1.1.1.3
diff -u -p -r1.1.1.3 source.c
--- source.c	2000/02/04 20:21:58	1.1.1.3
+++ source.c	2000/03/07 23:25:07
@@ -33,7 +33,7 @@
 #include "gdb_stat.h"
 #include <fcntl.h>
 #include "gdbcore.h"
-#include "gnu-regex.h"
+#include "gdb-regex.h"
 #include "symfile.h"
 #include "objfiles.h"
 #include "annotate.h"
Index: symtab.c
===================================================================
RCS file: /work/cvs/gnu/gdb/gdb/symtab.c,v
retrieving revision 1.1.1.4
diff -u -p -r1.1.1.4 symtab.c
--- symtab.c	2000/03/07 18:42:17	1.1.1.4
+++ symtab.c	2000/03/07 23:25:15
@@ -30,7 +30,7 @@
 #include "objfiles.h"
 #include "gdbcmd.h"
 #include "call-cmds.h"
-#include "gnu-regex.h"
+#include "gdb-regex.h"
 #include "expression.h"
 #include "language.h"
 #include "demangle.h"
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Michael Hayes <m.hayes@elec.canterbury.ac.nz>
Cc: gdb@sourceware.cygnus.com
Subject: Re: Cycle stepping
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38A4FC30.F3F69EBF@cygnus.com>
References: <14500.60988.450983.214268@ongaonga.elec.canterbury.ac.nz>
X-SW-Source: 2000-q1/msg00242.html
Content-length: 1118

Michael Hayes wrote:
> 
> I'm in the process of revitalising the tic4x target for submission.
> One big change that I've noticed is that a simulator can no longer use
> any of gdb's routines.
> 
> Now one useful feature we had with the c4x simulator was to provide
> single cycle stepping to observe the operation of the pipeline.  This
> was achieved by adding a couple of new commands to gdb's interpreter
> (stepc and nextc) whenever the c4x simulator was fired up.  Now in the
> process of making the c4x simulator stand-alone, does anyone know of a
> simple way that this functionality can be added to gdb?
> 
> Presently, stepc is similar to stepi but we use a flag to tell the
> simulator to stop after a cycle.  Is there a mechanism for
> communicating parameters like this to the simulator to avoid having to
> add another argument to target_resume?

You could table a proposal that ``step'' become an enum - run=0,
stepc=1, stepi=2.  Which would accomodate backward compatibility.

	Andrew

(Disclaimer - I've not thought this through and from memory you also
need a bit of serious WaitForInferior hacking).
From guo@cup.hp.com Sat Apr 01 00:00:00 2000
From: Jimmy Guo <guo@cup.hp.com>
To: gdb@sourceware.cygnus.com
Subject: Re: cvsup & sourceware repositories?
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <Pine.LNX.4.10.10003162342590.8409-100000@hpcll168.cup.hp.com>
X-SW-Source: 2000-q1/msg00734.html
Content-length: 2789

<< added the missing command line I mentioned at the end of the message >>

OK, here is a summary of the steps involved for me to create a local
repository behind a firewall:

- SOCKS5 (needed if you are behind a firewall)
  + Download:
    http://www.socks.nec.com/cgi-bin/download.pl

  + Build and install.

  + Configure to use a socks5 server your site provides:
    * Create /etc/libsocks5.conf:
sockd @=<your_socks_server>,<your_socks_server>.<domain> 0.0.0.0 0.0.0.0

  + Reference:
    http://www.socks.nec.com/socksv5.html

  + How to socksify an application:
    http://www.socks.nec.com/how2socksify.html

- CVS
  + Download:
    http://www.cyclic.com/pub/

  + Build and install.

  + Reference Manual, etc.:
    http://www.loria.fr/~molli/cvs-index.html

- rsync

  + Download:
    http://rsync.samba.org/

  + Socksify rsync source (needed if you are going to use rsync from
    behind a firewall), the quick'n'dirty approach:
    * main.c (main): add 'SOCKSinit (argv[0]);' to the beginning
    of main ().
    + rsync.h: add '#define SOCKS' and '#include <socks.h>' to the
    beginning of file.
    + Makefile.in: add '-L/usr/local/lib' (or the libsocks5 install
    location) and '-lsocks5' to the rsync link line.

  + Configure / Make / Install.

  + Reference:
    rsync(1) man page.
    http://sourceware.cygnus.com/sourceware/ under 'anonymous rsync' link.    

- Local repository creation:
  % mkdir -p <local_repository_root>
  % cd <local_repository_root>
  % rsync --archive --delete --checksum --compress --stats \
    rsync://sourceware.cygnus.com/src-cvs .

- Extract source (this creates <work_directory>/src/ tree with all
  necessary gdb and dejagnu components):
  % setenv CVSROOT <local_repository_root>
  % cd <work_directory>
  % cvs checkout -r HEAD dejagnu gdb

- Routine synchronization of src-cvs repository:
  Use the same rsync command above to synchronize.

That's it!  BTW the <local_repository_root>/CVSROOT/modules file lists
the module aliases / names in the repository, and I found it useful to
decide the module names to use in the cvs checkout command line.
Also, the rsync command line below dumps the list of repositories
available, which I used to figure out that the repository name
for src/cvs is actually src-cvs (that was not apparent to me as a
non-CVS user and was not mentioned in the
sourceware.cygnus.com/sourceware 'anonymous rsync' link):

  % rsync --archive --delete --checksum --compress --stats \
    rsync://sourceware.cygnus.com/ .

- Jimmy Guo, guo@cup.hp.com


>When you get it working, I would appreciate hearing about the procedure
>you used to (finally) make it work.  (You might just want to send a
>followup reply to gdb@sourceware because I suspect that there are others
>out there who'd also like to know.)


      parent reply	other threads:[~2000-04-01  0:00 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <200003082121.e28LLRu05681@delius.kettenis.local>
     [not found] ` <1000308222742.ZM8876@ocotillo.lan>
     [not found]   ` <200003091349.IAA19958@indy.delorie.com>
2000-04-01  0:00     ` Moving Linux-specific stuff out of i386-tdep.c Andrew Cagney
2000-04-01  0:00 ` Andrew Cagney
2000-04-01  0:00   ` Mark Kettenis
2000-04-01  0:00 ` Fernando Nasser [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=38C6D2DC.44C3FC6@cygnus.com \
    --to=fnasser@cygnus.com \
    --cc=gdb@sourceware.cygnus.com \
    --cc=kettenis@wins.uva.nl \
    /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