* Re: A patch for gnu-regex
2000-04-01 0:00 ` A patch for gnu-regex Andrew Cagney
@ 2000-04-01 0:00 ` H . J . Lu
0 siblings, 0 replies; 3+ messages in thread
From: H . J . Lu @ 2000-04-01 0:00 UTC (permalink / raw)
To: Andrew Cagney; +Cc: Mark Kettenis, jtc, shebs, gdb
On Fri, Mar 10, 2000 at 10:01:08AM +1100, Andrew Cagney wrote:
>
> I would like to see GDB-5 provide consistent behavour across all the
> random GNU/Linux distributions that are out there. I think this is
> consistent with other applications that rely on regexp - VI being a very
> very good example. I also want to be able to say, with some certainty,
> that a users regexp problem is attributable to GDB and _not_ random
> regexp of the day.
It seems that gdb is the only program you care on a GNU/Linux system.
You don't care if glibc nor other system programs work correctly or
not. As a long time Linux C library developer, I have received so
many bug reports derived from the system programs. I don't see
many Linux people go out to get their own replacements for the broken
functions in libc. I guess that is the one difference between Linux
and GNU. We are not writing replacements. We are working on the system
default.
>
> A GNU/Linux distributor is free to build a GDB that regexp from an
> installed glibc. Actually such a distributor is free to do what ever
> they like :-)
Are you saying as far as gdb is concerned, you have no interests
whatsoever in glibc nor helping glibc developers and GNU/Linux
distributors? If it is true, that is too bad.
H.J.
From grante@visi.com Sat Apr 01 00:00:00 2000
From: Grant Edwards <grante@visi.com>
To: gdb@sourceware.cygnus.com
Subject: RDI target broken in 000215 snapshot
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <20000221104541.A28578@visi.com>
X-SW-Source: 2000-q1/msg00361.html
Content-length: 746
The RDI target support seems to be broken in the 000215
snapshot. I'm unable to execute any of the eCos test programs,
or any other applictions I've written. (they run fine with a
patched-up 4.18 gdb). I don't know what's wrong with it and
won't have time to look at it for a while.
Is somebody currently working on the RDI code? If so, I'll
leave well enough alone until the code stabilizes.
[I've gotten fed up with the RDI code that only lets you use
certain devices for the serial connection to the target (and
the one I have connected is never one of the allowed devices),
so I decided to fix the code to allow the user to specify any
device he wants. For now I guess I'll work with 4.18 sources.]
--
Grant Edwards
grante@visi.com
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Eli Zaretskii <eliz@delorie.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: annotate.texi
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38C74298.B562FDD1@cygnus.com>
References: <200003070832.DAA14451@indy.delorie.com>
X-SW-Source: 2000-q1/msg00633.html
Content-length: 589
Eli Zaretskii wrote:
>
> Is there any reason why annotate.texi shouldn't be @include'd by
> gdb.texinfo and be part of the manual? Right now, "set annotate" is
> not documented at all, and annotate.texi seems to be just what the
> doctor ordered...
I just wonder if we want to encourage its use :-)
> And while at that, NEWS seems to be in the need of some work, it
> doesn't mention many of the new features that already are in the CVS
> tree. I would like at least to mention the improvements in the DJGPP
> version.
A call for news is on my list of pre 5.0 things-to-do.
Andrew
From rearnsha@arm.com Sat Apr 01 00:00:00 2000
From: Richard Earnshaw <rearnsha@arm.com>
To: Grant Edwards <grante@visi.com>
Cc: rearnsha@arm.com
Subject: Re: Address of variable doesn't work (ARM-ELF 4.18)?
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200001271540.PAA27230@cam-mail2.cambridge.arm.com>
References: <20000126103232.A15413@visi.com>
X-SW-Source: 2000-q1/msg00061.html
Content-length: 689
grante@visi.com said:
> Using arm-elf-gdb 4.18, how do I get gdb to print the address of a
> variable or to use the address of a variable as the argument for an
> 'x' command?
Info address should give you what you want, and a lot more besides. It
works even if the symbol you have asked for is in a register.
(gdb) info address main
Symbol "main" is a function at address 0x3b064.
(gdb) info address optimize
Symbol "optimize" is static storage at address 0x3214d4.
(gdb) info address argc
Symbol "argc" is an argument at offset 68.
(gdb) info address p
Symbol "p" is a local variable at frame offset -20.
(gdb) info address c
Symbol "c" is a variable in register l0.
Richard.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: A patch for gnu-regex
[not found] ` <5m4saivyew.fsf@jtc.redbacknetworks.com>
@ 2000-04-01 0:00 ` Andrew Cagney
2000-04-01 0:00 ` H . J . Lu
[not found] ` <20000307211842.C1573@lucon.org>
1 sibling, 1 reply; 3+ messages in thread
From: Andrew Cagney @ 2000-04-01 0:00 UTC (permalink / raw)
To: H . J . Lu; +Cc: Mark Kettenis, jtc, shebs, gdb
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 30521 bytes --]
"H . J . Lu" wrote:
> > This patch is definitly much better than the original.
> >
> > Unfortunatly, I don't think that selecting a pre-installed regexp should
> > be the default. My rationale (As Mark? noted) is that ensuring that a
> > GDB release provides consistent behavour between systems (1) is more
>
> Please remember, we, Linux, want to provide a consistent behavour
> cross the whole system. I think, Cygnus and FSF, haven't got rid of
> the idea that you are providing some replacements for some existing
> programs. When you build a Linux system from the source, do you like
> N copies for the same thing everywhere? If I were you, I would want
> everyone to use the
While I can understand viewpoint you're attributing to both that company
formally known as Cygnus and the FSF, it wasn't actually my overriding
concern (As an asside, the (1) ment to have a footnote pointing out I
had GNU/Linux systems in mind when I wrote this).
I would like to see GDB-5 provide consistent behavour across all the
random GNU/Linux distributions that are out there. I think this is
consistent with other applications that rely on regexp - VI being a very
very good example. I also want to be able to say, with some certainty,
that a users regexp problem is attributable to GDB and _not_ random
regexp of the day.
A GNU/Linux distributor is free to build a GDB that regexp from an
installed glibc. Actually such a distributor is free to do what ever
they like :-)
enjoy,
Andrew
From Guenther.Grau@marconicomms.com Sat Apr 01 00:00:00 2000
From: Guenther Grau <Guenther.Grau@marconicomms.com>
To: "H . J . Lu" <hjl@lucon.org>
Cc: gdb@sourceware.cygnus.com
Subject: Re: A patch for gnu-regex
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38C7EE20.FFD45517@marconicomms.com>
References: <38C585BB.3F7B1AC7@apple.com> <20000307155806.A30106@valinux.com> <5mg0u2l3g0.fsf@jtc.redbacknetworks.com> <20000307162127.D485@lucon.org> <200003080044.e280iGB00429@delius.kettenis.local> <5m4saivyew.fsf@jtc.redbacknetworks.com> <38C7B8BD.26C0E220@cygnus.com> <38C7C369.97CF2A7F@marconicomms.com> <20000309100518.A7546@lucon.org>
X-SW-Source: 2000-q1/msg00655.html
Content-length: 2675
"H . J . Lu" wrote:
>
> On Thu, Mar 09, 2000 at 04:29:45PM +0100, Guenther Grau wrote:
> > Andrew Cagney wrote:
> > >
> > [...]
> > > > http://sourceware.cygnus.com/ml/gdb-patches/2000-q1/msg00562.html
> > > > http://sourceware.cygnus.com/ml/gdb-patches/2000-q1/msg00566.html
> > >
> > > This patch is definitly much better than the original.
> > >
> > > Unfortunatly, I don't think that selecting a pre-installed regexp should
> > > be the default. My rationale (As Mark? noted) is that ensuring that a
> > > GDB release provides consistent behavour between systems (1) is more
> > > important than having it select the latest/greatest random regexp.
> >
> > I support this (not that it matters :-). If H.J. Lu wants it on
> > Linux, he can ./configure --with-libc-regex or --with-native-regex,
>
> --with-libc-regex and --with-native-regex are misleading since
> the regex in gdb coms from the Linux C library.
It might be a derived version, but it is not the same.
So what's the problem with these names? And if you don't
like them, find another name that suits you :-) How about
--with-linux-libc-regex-and-not-the-linux-libc-derived-version-within-gdb
or
--with-working-native-regex
;-) ?
What, if the gdb regex-implementation were not derived from
the linux libc-regex implementation? Would you still care
about the name of the option? Is this a problem of gdb not
giving credit to the linux regex implementation? There is
a lot of stuff in linux which doesn't give proper credit
to the original work it was derived from.
> > but the default should be the regex within gdb.
>
> Are you speaking as a Linux/Hurd user? As far as I know, my patch will
No.
> only affect Linux and Hurd? If you are a Linux/Hurd user, do you
> have a "known to work" regex in your C library? If not, should you
> be worried?
Well, that depends. People running an old Linux with a broken
regex should probably be worried, but if they are still using it,
they haven't encountered the bugs yet, so why worry? If they
encounter the bug later somewhen with a different application,
they probably blame the other application, but not gdb.
If they put the next gdb release on their system and it doesn't
run properly due to regex problems, they blame gdb, not the
broken regex implementation in libc. This is what we should avoid.
IMHO, the best solution would be to create a set of tests, which
check if the native regex implementation works properly and decide
which implementation to use based on this result (and maybe even
tell the user to upgrade their bogus version of libc). This is what
./configure is all about. The only problem is that it is a lot
more work.
Guenther
From hjl@lucon.org Sat Apr 01 00:00:00 2000
From: "H . J . Lu" <hjl@lucon.org>
To: Jim Kingdon <kingdon@redhat.com>
Cc: toddpw@windriver.com, kettenis@wins.uva.nl, gdb-patches@sourceware.cygnus.com, gdb@sourceware.cygnus.com
Subject: Another revised patch for dlclose
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <20000308103740.A3530@lucon.org>
References: <200003080849.AAA18417@alabama.wrs.com> <200003081441.JAA02876@devserv.devel.redhat.com>
X-SW-Source: 2000-q1/msg00611.html
Content-length: 4624
On Wed, Mar 08, 2000 at 09:41:00AM -0500, Jim Kingdon wrote:
>
> There are a few loose ends in freeing, but it is the tangled logic in
> find_solib that is tripping us up more than the freeing.
Here is a new patch. It seems to work with the testcase. Any
comments?
H.J.
----
2000-03-08 H.J. Lu <hjl@gnu.org>
Inspired by patches from Sam Lantinga (slouken@devolution.com):
* solib.c (solib_verify): New function. Unload the shared
object when it is deleted and dump symbols from the unloaded
shared object.
* solib.h (SOLIB_VERIFY): New. Defined as solib_verify.
* infrun.c (handle_inferior_event): Also call SOLIB_VERIFY ()
if it is defined when we hit the internal debug breakpoint for
shared libraries in the dynamic linker.
Index: solib.c
===================================================================
RCS file: /work/cvs/gnu/gdb/gdb/solib.c,v
retrieving revision 1.1.1.4
retrieving revision 1.7
diff -u -p -r1.1.1.4 -r1.7
--- solib.c 2000/03/07 18:42:17 1.1.1.4
+++ solib.c 2000/03/08 18:36:11 1.7
@@ -950,6 +950,84 @@ open_symbol_file_object (arg)
return 1;
}
#endif /* SVR4_SHARED_LIBS */
+
+/*
+
+GLOBAL FUNCTION
+
+ solib_verify -- check solib list consistency and dump symbols
+ from unloaded shared objects
+
+SYNOPSIS
+
+ void solib_verify (void)
+
+DESCRIPTION
+
+ This module is called whenever we hit a dynamic linker
+ breakpoint and allows us to check the consistency of our shared
+ object list and unload objects which are no longer valid in the
+ in the inferior. Without this, dynamic unlinking of objects
+ could crash us. This function should only be called when we
+ hit the internal debug breakpoint for shared libraries in the
+ dynamic linker.
+
+ */
+
+void
+solib_verify (void)
+{
+#ifdef SVR4_SHARED_LIBS
+ if (debug_base)
+ {
+ static int solib_unloading = 0;
+
+ read_memory (debug_base, (char *) &debug_copy,
+ sizeof (struct r_debug));
+ if (debug_copy.r_state == RT_DELETE)
+ solib_unloading = 1;
+ else if (solib_unloading && debug_copy.r_state == RT_CONSISTENT)
+ {
+ struct so_list *so = NULL, *next, *so_next, *saved;
+
+ /* Get the current list of loaded shared libraries. */
+ saved = so_list_head;
+ so_list_head = NULL;
+ while ((so = find_solib (so)) != NULL);
+ so = so_list_head;
+ so_list_head = saved;
+
+ /* We compare the current list against what we have. */
+ for (next = so_list_head; next; next = next->next)
+ {
+ for (so_next = so; so_next; so_next = so_next->next)
+ if (strcmp (so_next->so_name, next->so_name) == 0)
+ break;
+
+ if (!so_next)
+ {
+ /* We didn't find it in the current list. Unload it.
+ Since the dynamic linker can only unload one
+ shared library at a time, we stop here. Also
+ free_objfile () will call clear_solib (). It will
+ clear everything for us. */
+ free_objfile (next->objfile);
+ break;
+ }
+ }
+
+ /* Free the current list of loaded shared libraries. */
+ for (so_next = so; so_next; so_next = next)
+ {
+ next = so_next->next;
+ free (so_next);
+ }
+
+ solib_unloading = 0;
+ }
+ }
+#endif /* SVR4_SHARED_LIBS */
+}
/*
Index: solib.h
===================================================================
RCS file: /work/cvs/gnu/gdb/gdb/solib.h,v
retrieving revision 1.1.1.1
retrieving revision 1.2
diff -u -p -r1.1.1.1 -r1.2
--- solib.h 1999/09/09 00:38:38 1.1.1.1
+++ solib.h 2000/03/07 21:55:11 1.2
@@ -37,6 +37,14 @@ clear_solib PARAMS ((void));
extern void
solib_add PARAMS ((char *, int, struct target_ops *));
+/* Called to check solib list consistency and dump symbols from
+ unloaded shared objects. */
+
+#define SOLIB_VERIFY() solib_verify ()
+
+extern void
+solib_verify PARAMS ((void));
+
/* Function to be called when the inferior starts up, to discover the names
of shared libraries that are dynamically linked, the base addresses to
which they are linked, and sufficient information to read in their symbols
Index: infrun.c
===================================================================
RCS file: /work/cvs/gnu/gdb/gdb/infrun.c,v
retrieving revision 1.1.1.6
retrieving revision 1.2
diff -u -p -r1.1.1.6 -r1.2
--- infrun.c 2000/03/07 18:42:13 1.1.1.6
+++ infrun.c 2000/03/07 21:55:11 1.2
@@ -2416,6 +2416,9 @@ handle_inferior_event (struct execution_
/* Switch terminal for any messages produced by
breakpoint_re_set. */
target_terminal_ours_for_output ();
+#ifdef SOLIB_VERIFY
+ SOLIB_VERIFY ();
+#endif
SOLIB_ADD (NULL, 0, NULL);
target_terminal_inferior ();
}
From rose@netcom.com Sat Apr 01 00:00:00 2000
From: Ken Rose <rose@netcom.com>
To: davidwilliams@ozemail.com.au
Cc: crossgcc@sourceware.cygnus.com, gdb@sourceware.cygnus.com
Subject: Re: gdbstubs library posted at sourceforge
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200001311640.IAA08446@netcom.com>
X-SW-Source: 2000-q1/msg00077.html
Content-length: 1433
David Williams wrote:
>As far as I understand LGPL license (having read it several times now) as a
>minimum if the LGPL gdbstub code is included in a product of mine then I have
>to make the source for the gdbstub and the object code available so that users
>can modify the stub code and re-link with the supplied objects to create a new
>"executable". Making these available is not really a problem for me. I assume
>referring the user to a suitable web site (of mine) where such source and
>objects would be available would be satisfactory. The problem for my users is
>then that the "executable" as such needs to be written into flash memory. To do
>this the user would have to pull apart the device and then connect two pins on
>the PCB and then use some other software running on a PC (not normally supplied
>to the user) to download and program the flash memory with the new image. This
>is normally done as a factory proceedure. How far do I have to go to meet LGPL
>requirements???
There was an on-line discussion about three years ago (unfortunately, I've
forgotten where,exactly) that Stallman got involved with. His opinion seemed
to be that once you've provided the appropriate source & object code, you've
done what the license requires. If the software then needs to be installed
in a ROM in the middle of an ASIC, that's the user's problem, not yours.
If he voids the warranty by doing it, that's his problem, too.
From kettenis@wins.uva.nl Sat Apr 01 00:00:00 2000
From: Mark Kettenis <kettenis@wins.uva.nl>
To: mark@codesourcery.com
Cc: Peter.Schauer@Regent.E-Technik.TU-Muenchen.DE, kingdon@redhat.com, donnte@microsoft.com, gdb@sourceware.cygnus.com
Subject: Re: Regressions problem (200 failures)
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200003021246.e22CkWL00549@delius.kettenis.local>
References: <bd7pe3t7t.fsf@rtl.cygnus.com> <200003021010.LAA13693@reisser.regent.e-technik.tu-muenchen.de> <20000302023420H.mitchell@codesourcery.com>
X-SW-Source: 2000-q1/msg00497.html
Content-length: 1704
From: Mark Mitchell <mark@codesourcery.com>
Date: Thu, 02 Mar 2000 02:34:20 -0800
>>>>> "Peter" == Peter Schauer <Peter.Schauer@Regent.E-Technik.TU-Muenchen.DE> writes:
Peter> For practical debugging purposes (especially C++), the line
Peter> number information (and thus the breakpoint) has to be put
Peter> before the initialization code for local variables, so that
Peter> we can debug object initialization.
But the line number itself doesn't have to indicate the `{'; it could
indicate the next line, if that's what GDB wants. This is more
possible than it used to be since the C++ front-end now puts out whole
functions at once, rather than processing a statement at a time.
Still, it's non-trivial.
The following might be relevant for this discussion:
The comment on symtab.c:find_function_start_sal() says:
/* Given a function symbol SYM, find the symtab and line for the start
of the function.
If the argument FUNFIRSTLINE is nonzero, we want the first line
of real code inside the function. */
If you look at the implementation of find_function_start_sal() you'll
see that it uses SKIP_PROLOGUE to skip over the function prologue if
FUNFIRSTLINE is nonzero, and then chooses the next line after the
prologue. So GDB shouldn't have any problems with line notes for the
prologue.
The implementation of SKIP_PROLOGUE for the i386 lives in
i386-tdep.c:i386_skip_prologue(). According to the ChangeLog, this
code has not been changed since early 1994 (Hi Peter!), and it is not
unlikely that it has suffered some bit rot since then. Are the
prologue's generated by GCC any different from those generated back in
1994?
Mark
From johan.rydberg@netinsight.se Sat Apr 01 00:00:00 2000
From: Johan Rydberg <johan.rydberg@netinsight.se>
To: gdb@sourceware.cygnus.com
Subject: probelms with registers
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38C292EF.50B53C09@netinsight.se>
X-SW-Source: 2000-q1/msg00547.html
Content-length: 682
Hi!
I'm developing a "gdb-simulator" for a CPU, and it seems to
work pretty good. But I have some questions. When I try to
display the registers it says everyone except the link register
is unavailable. Why this? It also fetches the PC register, but
it also says it's unavailable.
And, how do I from gdb call the `sim_info´ function? Right
now I have implemented a "sim info" command, but since it's
defined in the simulator interface I guess that there's a
better way to do this.
regards,
Johan.
--
Johan Rydberg johan.rydberg@netinsight.net
Net Insight AB, Sweden direct: +46-8-685 04 17
http://www.netinsight.net phone: +46-8-685 04 00
fax: +46-8-685 04 20
From kingdon@redhat.com Sat Apr 01 00:00:00 2000
From: Jim Kingdon <kingdon@redhat.com>
To: gdb@sourceware.cygnus.com
Subject: Re: unloading shared objects
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <bln3l1hed.fsf@rtl.cygnus.com>
References: <200003131759.SAA07581@reisser.regent.e-technik.tu-muenchen.de> <np4saabhsk.fsf@zwingli.cygnus.com>
X-SW-Source: 2000-q1/msg00697.html
Content-length: 1875
> At present, GDB assumes that we know the shared object's load address
> when we read the symbols. Perhaps this is a poor assumption, but it
> is pretty fundamental to the current symbol table structure. I'm not
> going to fix that as part of this dlclose change.
Well, objfile_relocate was written to address this. But I agree,
trying to fix this as part of the dlclose fix could be biting off more
than is warranted.
> - free_objfile calls CLEAR_SOLIB, which isn't what we want, I think.
Ouch. That looks really bad. I suspect the CLEAR_SOLIB call can and
should be moved up to symbol_file_command (note the call to
SOLIB_RESTART - currently vestigial at least on Linux - which relates
to the issue of whether to nuke all the shared library symbols on
every run of the program).
> - Selecting a core file and attaching to a process both add the shared
> libraries' sections to the target_ops structure. When we unload a
> shared library, we close the BFD those sections refer to. We
> need to remove those sections from the target_ops structure.
You noticed that one too, eh? ;-).
> - Should solib.c be maintaining its own list of shared objects at all,
> or should it always retrieve the full link map from the inferior,
> and use the objfile list itself as our record of what we know about?
Haven't looked at the code long enough to have a really good feel for
this, but I think you are probably right. That your changes to nuke
find_solib separate out the inferior access code enough to make the
above practical.
Anyway, thanks for writing this code and let me know if there is
anything else I can do (at the moment, various ideas and encouragement
seem like a better way for me to help than writing code - not only was
my solib.c code somewhat buggy/unpopular, but I didn't really enjoy
writing it either :-)).
From hjl@valinux.com Sat Apr 01 00:00:00 2000
From: "H . J . Lu" <hjl@valinux.com>
To: gdb-patches@sourceware.cygnus.com
Cc: GDB <gdb@sourceware.cygnus.com>
Subject: A patch for gnu-regex
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <20000307134103.A20533@valinux.com>
X-SW-Source: 2000-q1/msg00568.html
Content-length: 10618
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.
H.J.
---
2000-03-07 H.J. Lu <hjl@gnu.org>
* config/alpha/alpha-linux.mh (REGEX, REGEX1): Clear.
* config/i386/linux.mh: Likewise.
* config/m68k/linux.mh: Likewise.
* config/powerpc/linux.mh: Likewise.
* config/sparc/linux.mh: Likewise.
* config/alpha/alpha-linuxlibc1.mh: New.
* config/i386/linuxlibc1.mh: Likewise.
* config/powerpc/linuxlibc1.mh: Likewise.
* config/sparc/linuxlibc1.mh: Likewise.
* configure.host (alpha*-*-linux*libc1): New host.
(i[3456]86-*-linux*libc1): Likewise.
(i[3456]86-*-linux*libc5): Likewise.
(powerpc-*-linux*libc1): Likewise.
(sparc-*-linux*libc1): Likewise.
(sparc-*-linux*libc5): Likewise.
* irix5-nat.c: Include <regex.h> instead of "gnu-regex.h" for
glibc 2.
* monitor.c: Likewise.
* osfsolib.c: Likewise.
* solib.c: Likewise.
* source.c: Likewise.
* symtab.c: Likewise.
Index: config/alpha/alpha-linux.mh
===================================================================
RCS file: /work/cvs/gnu/gdb/gdb/config/alpha/alpha-linux.mh,v
retrieving revision 1.1.1.3
diff -u -p -r1.1.1.3 alpha-linux.mh
--- config/alpha/alpha-linux.mh 2000/03/07 18:42:19 1.1.1.3
+++ config/alpha/alpha-linux.mh 2000/03/07 18:44:07
@@ -1,4 +1,9 @@
# Host: Little-endian Alpha running Linux
+
+# We should use the one in glibc 2.
+REGEX=
+REGEX1=
+
XDEPFILES= ser-tcp.o
XM_FILE= xm-alphalinux.h
NAT_FILE= nm-linux.h
Index: config/i386/linux.mh
===================================================================
RCS file: /work/cvs/gnu/gdb/gdb/config/i386/linux.mh,v
retrieving revision 1.1.1.2
retrieving revision 1.2
diff -u -p -r1.1.1.2 -r1.2
--- config/i386/linux.mh 2000/01/18 17:07:18 1.1.1.2
+++ config/i386/linux.mh 2000/03/07 21:31:30 1.2
@@ -1,10 +1,14 @@
# Host: Intel 386 running GNU/Linux
+# We should use the one in glibc 2.
+REGEX=
+REGEX1=
+
XM_FILE= xm-linux.h
XDEPFILES= ser-tcp.o
NAT_FILE= nm-linux.h
NATDEPFILES= infptrace.o solib.o inftarg.o fork-child.o corelow.o \
- core-aout.o i386v-nat.o i386-linux-nat.o linux-thread.o lin-thread.o
+ core-aout.o i386-linux-nat.o linux-thread.o lin-thread.o
LOADLIBES = -ldl -rdynamic
Index: config/m68k/linux.mh
===================================================================
RCS file: /work/cvs/gnu/gdb/gdb/config/m68k/linux.mh,v
retrieving revision 1.1.1.2
diff -u -p -r1.1.1.2 linux.mh
--- config/m68k/linux.mh 2000/01/18 17:07:22 1.1.1.2
+++ config/m68k/linux.mh 2000/01/18 17:08:57
@@ -1,5 +1,9 @@
# Host: Motorola m68k running Linux
+# We should use the one in glibc 2.
+REGEX=
+REGEX1=
+
XM_FILE= xm-linux.h
XDEPFILES= ser-tcp.o
Index: config/powerpc/linux.mh
===================================================================
RCS file: /work/cvs/gnu/gdb/gdb/config/powerpc/linux.mh,v
retrieving revision 1.1.1.2
diff -u -p -r1.1.1.2 linux.mh
--- config/powerpc/linux.mh 2000/03/07 18:42:23 1.1.1.2
+++ config/powerpc/linux.mh 2000/03/07 18:44:08
@@ -1,5 +1,9 @@
# Host: PowerPC, running Linux
+# We should use the one in glibc 2.
+REGEX=
+REGEX1=
+
XM_FILE= xm-linux.h
XDEPFILES= ser-tcp.o
XM_CLIBS=
Index: config/sparc/linux.mh
===================================================================
RCS file: /work/cvs/gnu/gdb/gdb/config/sparc/linux.mh,v
retrieving revision 1.1.1.2
diff -u -p -r1.1.1.2 linux.mh
--- config/sparc/linux.mh 2000/01/18 17:07:30 1.1.1.2
+++ config/sparc/linux.mh 2000/01/18 17:08:58
@@ -1,4 +1,9 @@
# Host: Sparcstation, running Linux
+
+# We should use the one in glibc 2.
+REGEX=
+REGEX1=
+
XDEPFILES= ser-tcp.o
XM_FILE= xm-linux.h
NAT_FILE= nm-linux.h
Index: configure.host
===================================================================
RCS file: /work/cvs/gnu/gdb/gdb/configure.host,v
retrieving revision 1.1.1.2
diff -u -p -r1.1.1.2 configure.host
--- configure.host 2000/01/18 17:06:53 1.1.1.2
+++ configure.host 2000/01/18 17:08:52
@@ -34,6 +34,7 @@ a29k-*-*) gdb_host=ultra3 ;;
alpha*-*-osf1*) gdb_host=alpha-osf1 ;;
alpha*-*-osf2*) gdb_host=alpha-osf2 ;;
alpha*-*-osf[3456789]*) gdb_host=alpha-osf3 ;;
+alpha*-*-linux*libc1) gdb_host=alpha-linuxlibc1 ;;
alpha*-*-linux*) gdb_host=alpha-linux ;;
arm*-*-linux*) gdb_host=linux ;;
@@ -60,6 +61,8 @@ i[3456]86-*-freebsd*) gdb_host=fbsd ;;
i[3456]86-*-netbsd*) gdb_host=nbsd ;;
i[3456]86-*-go32*) gdb_host=go32 ;;
i[3456]86-*-msdosdjgpp*) gdb_host=go32 ;;
+i[3456]86-*-linux*libc1|i[3456]86-*-linux*libc5)
+ gdb_host=linuxlibc1 ;;
i[3456]86-*-linux*) gdb_host=linux ;;
i[3456]86-*-lynxos*) gdb_host=i386lynx ;;
i[3456]86-*-mach3*) gdb_host=i386m3 ;;
@@ -134,6 +137,7 @@ ns32k-utek-sysv*) gdb_host=merlin ;;
powerpc-*-aix*) gdb_host=aix ;;
powerpcle-*-cygwin*) gdb_host=cygwin ;;
powerpcle-*-solaris*) gdb_host=solaris ;;
+powerpc-*-linux*libc1) gdb_host=linuxlibc1 ;;
powerpc-*-linux*) gdb_host=linux ;;
# OBSOLETE pn-*-*) gdb_host=pn ;;
@@ -146,6 +150,8 @@ rs6000-*-lynxos*) gdb_host=rs6000lynx ;;
rs6000-*-aix4*) gdb_host=aix4 ;;
rs6000-*-*) gdb_host=rs6000 ;;
+sparc-*-linux*libc1|sparc-*-linux*libc5)
+ gdb_host=linuxlibc1 ;;
sparc-*-linux*) gdb_host=linux ;;
sparc-*-lynxos*) gdb_host=sparclynx ;;
sparc-*-netbsdelf*) gdb_host=nbsdelf ;;
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 1999/11/19 23:40:52
@@ -278,10 +278,14 @@ fetch_core_registers (core_reg_sect, cor
#include "objfiles.h"
#include "command.h"
#include "frame.h"
-#include "gnu-regex.h"
#include "inferior.h"
#include "language.h"
#include "gdbcmd.h"
+#if defined __GLIBC__ && __GLIBC__ >= 2
+#include <regex.h>
+#else
+#include "gnu-regex.h"
+#endif
/* The symbol which starts off the list of shared libraries. */
#define DEBUG_BASE "__rld_obj_head"
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 18:44:06
@@ -50,9 +50,13 @@
#include "monitor.h"
#include "gdbcmd.h"
#include "inferior.h"
-#include "gnu-regex.h"
#include "dcache.h"
#include "srec.h"
+#if defined __GLIBC__ && __GLIBC__ >= 2
+#include <regex.h>
+#else
+#include "gnu-regex.h"
+#endif
static char *dev_name;
static struct target_ops *targ_ops;
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 1999/11/19 23:40:52
@@ -36,10 +36,14 @@
#include "command.h"
#include "target.h"
#include "frame.h"
-#include "gnu-regex.h"
#include "inferior.h"
#include "language.h"
#include "gdbcmd.h"
+#if defined __GLIBC__ && __GLIBC__ >= 2
+#include <regex.h>
+#else
+#include "gnu-regex.h"
+#endif
#define MAX_PATH_SIZE 1024 /* FIXME: Should be dynamic */
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 21:32:29
@@ -49,11 +49,15 @@
#include "command.h"
#include "target.h"
#include "frame.h"
-#include "gnu-regex.h"
#include "inferior.h"
#include "environ.h"
#include "language.h"
#include "gdbcmd.h"
+#if defined __GLIBC__ && __GLIBC__ >= 2
+#include <regex.h>
+#else
+#include "gnu-regex.h"
+#endif
#define MAX_PATH_SIZE 512 /* FIXME: Should be dynamic */
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/02/04 21:36:33
@@ -33,11 +33,15 @@
#include "gdb_stat.h"
#include <fcntl.h>
#include "gdbcore.h"
-#include "gnu-regex.h"
#include "symfile.h"
#include "objfiles.h"
#include "annotate.h"
#include "gdbtypes.h"
+#if defined __GLIBC__ && __GLIBC__ >= 2
+#include <regex.h>
+#else
+#include "gnu-regex.h"
+#endif
#ifdef UI_OUT
#include "ui-out.h"
#endif
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 18:44:06
@@ -30,7 +30,6 @@
#include "objfiles.h"
#include "gdbcmd.h"
#include "call-cmds.h"
-#include "gnu-regex.h"
#include "expression.h"
#include "language.h"
#include "demangle.h"
@@ -43,6 +42,11 @@
#include "gdb_string.h"
#include "gdb_stat.h"
#include <ctype.h>
+#if defined __GLIBC__ && __GLIBC__ >= 2
+#include <regex.h>
+#else
+#include "gnu-regex.h"
+#endif
/* Prototype for one function in parser-defs.h,
instead of including that entire file. */
--- /dev/null Tue May 5 13:32:27 1998
+++ config/alpha/alpha-linuxlibc1.mh Tue Oct 19 09:50:12 1999
@@ -0,0 +1,10 @@
+# Host: Little-endian Alpha running Linux with the GNU C library 1.
+
+XDEPFILES=
+XM_FILE= xm-alphalinux.h
+NAT_FILE= nm-linux.h
+NATDEPFILES= infptrace.o inftarg.o corelow.o core-regset.o alpha-nat.o \
+ fork-child.o solib.o
+
+MMALLOC =
+MMALLOC_CFLAGS = -DNO_MMALLOC
--- /dev/null Tue May 5 13:32:27 1998
+++ config/i386/linuxlibc1.mh Tue Oct 19 09:50:21 1999
@@ -0,0 +1,8 @@
+# Host: Intel 386 running GNU/Linux with the Linux C library 5.
+
+XM_FILE= xm-linux.h
+XDEPFILES= ser-tcp.o
+
+NAT_FILE= nm-linux.h
+NATDEPFILES= infptrace.o solib.o inftarg.o fork-child.o corelow.o \
+ core-aout.o core-regset.o i386lnx-nat.o lnx-thread.o lnx-nat.o
--- /dev/null Tue May 5 13:32:27 1998
+++ config/powerpc/linuxlibc1.mh Tue Mar 7 13:35:15 2000
@@ -0,0 +1,10 @@
+# Host: PowerPC, running Linux with the GNU C library 1.
+
+XM_FILE= xm-linux.h
+XDEPFILES= ser-tcp.o
+XM_CLIBS=
+
+NAT_FILE= nm-linux.h
+NATDEPFILES= infptrace.o solib.o inftarg.o fork-child.o corelow.o core-aout.o core-regset.o ppc-linux-nat.o linux-thread.o
+
+GDBSERVER_DEPFILES= low-linux.o
--- /dev/null Tue May 5 13:32:27 1998
+++ config/sparc/linuxlibc1.mh Tue Oct 19 09:53:46 1999
@@ -0,0 +1,9 @@
+# Host: Sparcstation, running Linux with the Linux C library 5.
+
+XDEPFILES= ser-tcp.o
+XM_FILE= xm-linux.h
+NAT_FILE= nm-linux.h
+NATDEPFILES= fork-child.o infptrace.o inftarg.o corelow.o \
+ core-regset.o sparc-nat.o
+HOST_IPC=-DBSD_IPC
+GDBSERVER_DEPFILES= low-sparc.o
From muller@cerbere.u-strasbg.fr Sat Apr 01 00:00:00 2000
From: Pierre Muller <muller@cerbere.u-strasbg.fr>
To: Mark Kettenis <kettenis@wins.uva.nl>
Cc: gdb@sourceware.cygnus.com
Subject: RFD: New command to inspect other selectors memory.
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200003030843.JAA12246@cerbere.u-strasbg.fr>
References: <200003021432.PAA01976@cerbere.u-strasbg.fr> <200003021347.OAA01051@cerbere.u-strasbg.fr> <200003021257.NAA00259@cerbere.u-strasbg.fr>
X-SW-Source: 2000-q1/msg00515.html
Content-length: 1161
I inserted this in a reply about pascal extension, but as I got no answer,
I thought
I will send it as a separate message.
I have written for DJGPP target a relatively small patch.
It allows to read memory from another selector
this was very useful for me when I tried to debug the debugger itself and
when I added exception support fro GDB on DJGPP !
This patch consists of the addition of one command that I called "xx"
which is a simple clone of the "x" command but can take a selector
as for intance
"xx $fs:0x400"
then the next "xx 0x800" keeps using the last selector value.
I do not know if this could be interesting for other i386 targets
(maybe for win32 to be able to see the content of the $fs selector
that contains the exception chain, but I am not sure how if its
readable inside a win32 API program).
Is such kind of patch too specific to have any chance to get accepted ?
I don't know if it could be of any use for other processors or operating
system !!
Pierre Muller
Institut Charles Sadron
6,rue Boussingault
F 67083 STRASBOURG CEDEX (France)
mailto:muller@ics.u-strasbg.fr
Phone : (33)-3-88-41-40-07 Fax : (33)-3-88-41-40-99
From mirko.viviani@rccr.cremona.it Sat Apr 01 00:00:00 2000
From: mirko.viviani@rccr.cremona.it
To: gdb@sourceware.cygnus.com
Subject: gdb-cvs fails on freebsd-elf
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200003312231.AAA27172@rccr1.rccr.cremona.it>
X-SW-Source: 2000-q1/msg00846.html
Content-length: 221
Ciao!
I've noticed that gdb on cvs does not support (and does not compile w/o
some changes) on FreeBSD-elf...
Who is the FreeBSD maintainer ?
Thanks.
--
Bye,
Mirko <mirko.viviani@rccr.cremona.it> (NeXTmail, MIME)
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: A patch for gnu-regex
[not found] ` <200003081758.SAA17064@landau.wins.uva.nl>
@ 2000-04-01 0:00 ` H . J . Lu
0 siblings, 0 replies; 3+ messages in thread
From: H . J . Lu @ 2000-04-01 0:00 UTC (permalink / raw)
To: Mark Kettenis; +Cc: jtc, shebs, gdb
On Wed, Mar 08, 2000 at 06:58:18PM +0100, Mark Kettenis wrote:
>
> I can add --enable-gdb-regex if it helps.
>
> If we decide to do so, could we then try to be consistent with other
> GNU packages that already let the user choose between the regex
> implementation distributed with that package, and the implementation
> in the C library, and us --with(out)-included-regex?
>
Here is a revised patch. It overrides:
http://sourceware.cygnus.com/ml/gdb-patches/2000-q1/msg00562.html
http://sourceware.cygnus.com/ml/gdb-patches/2000-q1/msg00566.html
H.J.
---
2000-03-08 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@.
(REGEX_CFLAGS): New.
(REGEX1): Removed.
(ADD_DEPS): Use $(REGEX) instead of $(REGEX1).
(INTERNAL_WARN_CFLAGS): Add $(REGEX_CFLAGS).
* configure.in (--with-included-regex): New switch.
(REGEX): New. Subsstitue @REGEX@ in Makefile.in.
(REGEX_CFLAGS): New. Subsstitue @REGEX_CFLAGS@ in Makefile.in.
* configure: Regenerated.
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/08 23:33:09
@@ -505,6 +505,34 @@ if test x$want_mmalloc = xtrue; then
MMALLOC='../mmalloc/libmmalloc.a'
fi
+AC_ARG_WITH(included-regex,
+[ --with-included-regex Use included regex],
+[case "${withval}" in
+ yes) want_included_regex=true ;;
+ no) want_included_regex=false;;
+ *) AC_MSG_ERROR(bad value ${withval} for GDB with-included-regex option) ;;
+esac],[want_included_regex=false])dnl
+
+REGEX="gnu-regex.o"
+REGEX_CFLAGS="-DUSE_INCLUDED_REGEX"
+if test $want_included_regex = false; then
+ 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=
+ REGEX_CFLAGS=
+ fi
+fi
+AC_SUBST(REGEX)
+AC_SUBST(REGEX_CFLAGS)
# In the Cygwin environment, we need some additional flags.
AC_CACHE_CHECK([for cygwin], gdb_cv_os_cygwin,
Index: irix5-nat.c
===================================================================
RCS file: /work/cvs/gnu/gdb/gdb/irix5-nat.c,v
retrieving revision 1.1.1.3
retrieving revision 1.3
diff -u -p -r1.1.1.3 -r1.3
--- irix5-nat.c 1999/11/19 23:38:46 1.1.1.3
+++ irix5-nat.c 2000/03/08 00:36:03 1.3
@@ -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
retrieving revision 1.3
diff -u -p -r1.1.1.5 -r1.3
--- monitor.c 2000/03/07 18:42:14 1.1.1.5
+++ monitor.c 2000/03/08 00:36:03 1.3
@@ -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
retrieving revision 1.3
diff -u -p -r1.1.1.3 -r1.3
--- osfsolib.c 1999/11/19 23:38:50 1.1.1.3
+++ osfsolib.c 2000/03/08 00:36:03 1.3
@@ -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
retrieving revision 1.7
diff -u -p -r1.1.1.4 -r1.7
--- solib.c 2000/03/07 18:42:17 1.1.1.4
+++ solib.c 2000/03/08 18:36:11 1.7
@@ -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
retrieving revision 1.3
diff -u -p -r1.1.1.3 -r1.3
--- source.c 2000/02/04 20:21:58 1.1.1.3
+++ source.c 2000/03/08 00:36:03 1.3
@@ -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
retrieving revision 1.3
diff -u -p -r1.1.1.4 -r1.3
--- symtab.c 2000/03/07 18:42:17 1.1.1.4
+++ symtab.c 2000/03/08 00:36:03 1.3
@@ -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"
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/08 23:48:52
@@ -114,6 +114,11 @@ LIBIBERTY = ../libiberty/libiberty.a
MMALLOC = @MMALLOC@
MMALLOC_CFLAGS = @MMALLOC_CFLAGS@
+# We are using our own version of REGEX now to be consistent across
+# machines.
+REGEX = @REGEX@
+REGEX_CFLAGS = @REGEX_CFLAGS@
+
# Where is the BFD library? Typically in ../bfd.
BFD_DIR = ../bfd
BFD = $(BFD_DIR)/libbfd.a
@@ -271,7 +276,8 @@ INTERNAL_WARN_CFLAGS = \
$(CFLAGS) $(GLOBAL_CFLAGS) $(PROFILE_CFLAGS) \
$(GDB_CFLAGS) $(OPCODES_CFLAGS) $(READLINE_CFLAGS) \
$(BFD_CFLAGS) $(MMALLOC_CFLAGS) $(INCLUDE_CFLAGS) \
- $(INTL_CFLAGS) $(TUI_CFLAGS) $(ENABLE_CFLAGS) $(GDB_WARN_CFLAGS)
+ $(INTL_CFLAGS) $(TUI_CFLAGS) $(ENABLE_CFLAGS) \
+ $(REGEX_CFLAGS) $(GDB_WARN_CFLAGS)
INTERNAL_CFLAGS = $(INTERNAL_WARN_CFLAGS) $(GDB_WERROR_CFLAGS)
# LDFLAGS is specifically reserved for setting from the command line
@@ -283,11 +289,6 @@ INTERNAL_CFLAGS = $(INTERNAL_WARN_CFLAGS
INTERNAL_LDFLAGS = $(CFLAGS) $(GLOBAL_CFLAGS) $(PROFILE_CFLAGS) $(LDFLAGS) $(CONFIG_LDFLAGS) @HLDFLAGS@
HLDENV = @HLDENV@
-# We are using our own version of REGEX now to be consistent across
-# machines.
-REGEX = gnu-regex.o
-REGEX1 = gnu-regex.o
-
# If your system is missing alloca(), or, more likely, it's there but
# it doesn't work, then refer to libiberty.
@@ -308,7 +309,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
--- /dev/null Tue May 5 13:32:27 1998
+++ gdb_regex.h Wed Mar 8 15:40:01 2000
@@ -0,0 +1,7 @@
+#ifndef _GDB_REGEX_H
+#if !defined USE_INCLUDED_REGEX && defined __GLIBC__ && __GLIBC__ >= 2
+#include <regex.h>
+#else
+#include "gnu-regex.h"
+#endif
+#endif /* _GDB_REGEX_H */
From eliz@delorie.com Sat Apr 01 00:00:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: kettenis@wins.uva.nl
Cc: gdb@sourceware.cygnus.com, gdb-patches@sourceware.cygnus.com
Subject: Re: `long double' support for ix86 targets
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200003050805.DAA10149@indy.delorie.com>
References: <200003031531.e23FV8T00285@delius.kettenis.local>
X-SW-Source: 2000-q1/msg00542.html
Content-length: 885
> I intend to check in the following patch in a week or two, but since
> this change affects most of the ix86 targets, I'd like to give people
> the opportunity to object.
>
> Mark
>
>
> 2000-03-02 Mark Kettenis <kettenis@gnu.org>
>
> * config/i386/tm-i386.h (TARGET_LONG_DOUBLE_FORMAT): Define as
> &floatformat_i387_ext.
> (TARGET_LONG_DOUBLE_BITS): Define as 96.
> (REGISTER_VIRTUAL_TYPE): Change type for FPU registers to
> `builtin_type_long_double'.
> (REGISTER_CONVERT_TO_VIRTUAL): Simply copy over the data, and pad
> with zeroes.
> (REGISTER_CONVERT_TO_RAW): Simply copy over the significant data.
> (i387_to_double, double_to_i387): Remove prototypes.
These changes are okay for DJGPP.
Btw, shouldn't we also have identical definition for
HOST_LONG_DOUBLE_FORMAT for native debugging? Several functions ask
about the host and target format being identical.
From cgf@cygnus.com Sat Apr 01 00:00:00 2000
From: Chris Faylor <cgf@cygnus.com>
To: Brent Weech <weech@primenet.com>
Cc: gdb@sourceware.cygnus.com, cygwin@sourceware.cygnus.com
Subject: Re: GDB error 87 under Cygwin
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <20000227155217.A7612@cygnus.com>
References: <4.3.2.20000226214059.00b8f008@pop.primenet.com>
X-SW-Source: 2000-q1/msg00428.html
Content-length: 2097
On Sat, Feb 26, 2000 at 10:33:54PM -0700, Brent Weech wrote:
>Where in the world in the Errors.h file that enumerates the error codes
>coming from GDB? In particular, I am interested in error 87, as shown
>below:
That would be in the cygwin distribution. In later snapshots it's called
"winerror.h. If you grep for "ERROR_" you should be able to find the
correct file, whatever it is called.
>BLACKBOX> gdb h-hcube
>GNU gdb 4.18
>Copyright 1998 Free Software Foundation, Inc.
>GDB is free software, covered by the GNU General Public License, and you are
>welcome to change it and/or distribute copies of it under certain conditions.
>Type "show copying" to see the conditions.
>There is absolutely no warranty for GDB. Type "show warranty" for details.
>This GDB was configured as "i586-cygwin32"...(no debugging symbols found)...
>(gdb) r
>Starting program: //e/h-hcube.exe
>Error creating process //e/h-hcube.exe, (error 87)
Error 87 is "INVALID_PARAMETER". I'm not sure why this is happening,
unfortunately.
>I'm sure the answer to this question is somewhere on the Cygnus and/or
>GDB mailing archive, but for the life of me I can't figure out how to
>get the wonderfully worthless ht://Dig search engine to accept phrase
>or boolean searches with any accuracy. It has got to be one of the
>most frustrating search engine software packages I have ever used. For
>example, try the following: On the Cygwin Project archive, a search for
>"error 87" set to match all terms or a boolean search for "error and
>87" both give 5474 matches. On the same archive, a search for "error"
>gives (yes, I'm sure you can guess) the same 5474 matches! But on the
>same archive, a search for "error 193" set to match all terms only
>gives 21 hits.
Sorry. I don't know anything about the search engine. Possibly sending
email to sourcemaster@cygnus.com might help.
If you want to debug this, you could grab a precompiled version of gdb from
ftp://ftp.xraylith.wisc.edu/pub/khan/gnu-win32/cygwin/ports/
possibly, that would work better.
cgf
From cgf@cygnus.com Sat Apr 01 00:00:00 2000
From: Chris Faylor <cgf@cygnus.com>
To: David Williams <davidwilliams@ozemail.com.au>
Cc: Serge Nikulin <nikulin@actsw.amat.com>, gdb@sourceware.cygnus.com
Subject: Re: How to set RS232 speed in gdb in WinNT?
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <20000331212950.B2696@cygnus.com>
References: <003e01bf9b69$afc0c220$35758798@mis.amat.com> <38E538DF.ED6289D6@ozemail.com.au>
X-SW-Source: 2000-q1/msg00855.html
Content-length: 1359
On Sat, Apr 01, 2000 at 09:46:40AM +1000, David Williams wrote:
>Use -b command line option to change baud rate
>
>eg. gdb -b 115200
>to set baud rate 115200 baud.
>Dave.
Note that in some older versions of the Cygwin DLL (possibly in B20.1)
there was an error which caused the 115200 baud rate to be incorrectly
handled. Everything should work ok if you are using the Cygwin CD or if
you are using a later cygwin snapshot.
cgf
>Serge Nikulin wrote:
>> I use gdb for remote debugging of m68k target, compiled with MRI
>> <--host=i686-pc-cygwin32 --target=m68k-motorola-ieee>
>> Native MRI' X-Ray debugger does not support our home-made RTOS.
>> GDB works but I have few questions.
>>
>> 1) Currently ieee-695 bfd section is not connected to gdb, so I work without
>> src.
>> I've checked examples of coff and aout conections and it does not look
>> as a 1-day job for me
>> (including the fact that ieee-695 support in bfd is incomplete).
>> Does anyone have ieee + gdb experience?
>>
>> 2) In my gdb session under WinNT I use command "target remote com1"
>> In this case gdb connects to COM1 at 9600 baud. I'd like to change this
>> speed (say, to 38400) but I can't. I've changed default speed for COM1 in
>> WinNT's control panel but it did not help. It looks like I have to pass that
>> speed to cygwin.dll somehow. How can I do that?
From jason-gdb@molenda.com Sat Apr 01 00:00:00 2000
From: Jason Molenda <jason-gdb@molenda.com>
To: gdb@sourceware.cygnus.com
Subject: Re: gdb and iso-c
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <20000325110517.A15903@shell17.ba.best.com>
X-SW-Source: 2000-q1/msg00808.html
Content-length: 777
Both Tom Tromey and I have brought this up before, but I'll bring
it up again. automake includes a program (ansi2knr) which is able
to reformat ISO C code in to K&R code -- it would not be difficult
to incorporate this (without switching to automake, even; just add
it in) for targets that do not have an ISO C compiler and for which
we cannot expect the presence of the GNU tools.
I'm in favor of moving to ISO C. It's been around a very long
time, we can move forward. But the cost of supporting older systems
via an automated translation at compile-time is so low that it is
silly to not add in support for it.
Of course, I'm not volunteering to actually _add_ the support for it
myself. :-) I need to start finding more free time somewhere. :-/
My two cents,
Jason
From mark@codesourcery.com Sat Apr 01 00:00:00 2000
From: Mark Mitchell <mark@codesourcery.com>
To: Peter.Schauer@Regent.E-Technik.TU-Muenchen.DE
Cc: kingdon@redhat.com, donnte@microsoft.com, gdb@sourceware.cygnus.com
Subject: Re: Regressions problem (200 failures)
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <20000302090343I.mitchell@codesourcery.com>
References: <20000302023420H.mitchell@codesourcery.com> <200003021143.MAA14294@reisser.regent.e-technik.tu-muenchen.de>
X-SW-Source: 2000-q1/msg00511.html
Content-length: 502
>>>>> "Peter" == Peter Schauer <Peter.Schauer@Regent.E-Technik.TU-Muenchen.DE> writes:
Peter> with GCC or GDB), a breakpoint on the opening brace is not
Peter> what I want, as I will almost always have to step over it.
Peter> I'd expect a breakpoint on the first local variable that
Peter> needs initalization, or the first statement.
Yes, I think we're all agreed.
--
Mark Mitchell mark@codesourcery.com
CodeSourcery, LLC http://www.codesourcery.com
From msnyder@cygnus.com Sat Apr 01 00:00:00 2000
From: Michael Snyder <msnyder@cygnus.com>
To: Eli Zaretskii <eliz@is.elta.co.il>
Cc: hjl@lucon.org, gdb@sourceware.cygnus.com, gdb-patches@sourceware.cygnus.com
Subject: Re: Problems with hardware watchpoint on ia32.
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38D7DEE7.47D8@cygnus.com>
References: <20000307132401.A20282@valinux.com> <200003081008.FAA16481@indy.delorie.com> <20000308084304.A3150@lucon.org> <200003091211.HAA19860@indy.delorie.com>
X-SW-Source: 2000-q1/msg00763.html
Content-length: 2108
Eli Zaretskii wrote:
>
> Problem no.2: Read watchpoints break when they shouldn't.
Accepted and checked in. --michael
> Example (slightly modified test program posted by H.J. Lu):
>
> $ cat wp.c
> int a1;
> int a2;
> int a3;
> int a4;
> int a5;
> int a6;
>
> unsigned long long ulla1 = 0;
> double da2 = 0;
>
> int main (void)
> {
> a2 = 12;
> a3 = 13;
> a4 = 14;
> a5 = 15;
> a6 = 16;
> a1 = 11;
> a2 = a4;
>
> ulla1 = 0x00000000ffffffffLL;
> da2 = 12;
> ulla1 = 0xffffffff00000000LL;
>
> return 0;
> }
>
> $ gcc -g -o wp wp.c
> $ gdb wp
> (gdb) watch a5
> Hardware watchpoint 2: a5
> (gdb) rwatch a5
> Hardware read watchpoint 3: a5
> (gdb) run
> Starting program g:/gdbsnap/gdb-0222/gdb/wp
> Hardware watchpoint 2: a5
>
> Old value = 0
> New value = 15
> Hardware read watchpoint 3: a5
>
> Value = 15
> main () at wp.c: 16
> 16 a5 = 15;
> (gdb)
>
> Now, it might seem like a strange idea to put two watchpoints on the
> same variable, but it is a very useful feature when each watchpoint
> has a different condition.
>
> Here's the patch:
>
> 2000-03-08 Eli Zaretskii <eliz@is.elta.co.il>
>
> * breakpoint.c (bpstat_stop_status): Don't stop if a read
> watchpoint appears to break, but the watched value changed.
>
> --- gdb/breakpoint.c~2 Wed Mar 8 19:20:28 2000
> +++ gdb/breakpoint.c Wed Mar 8 20:02:20 2000
> @@ -2620,6 +2620,17 @@ bpstat_stop_status (pc, not_a_breakpoint
> /* Stop. */
> break;
> case WP_VALUE_CHANGED:
> + if (b->type == bp_read_watchpoint)
> + {
> + /* Don't stop: read watchpoints shouldn't fire if
> + the value has changed. This is for targets which
> + cannot set read-only watchpoints. */
> + bs->print_it = print_it_noop;
> + bs->stop = 0;
> + continue;
> + }
> + ++(b->hit_count);
> + break;
> case WP_VALUE_NOT_CHANGED:
> /* Stop. */
> ++(b->hit_count);
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Jim Blandy <jimb@cygnus.com>, gdb@sourceware.cygnus.com
Subject: Re: multi-arch notes (long); Was: Multi-arching tm_print_insn?
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38B4848F.CBF6CDE@cygnus.com>
References: <200002232238.RAA28167@zwingli.cygnus.com> <38B481C5.D10C1F52@cygnus.com>
X-SW-Source: 2000-q1/msg00393.html
Content-length: 26820
Oops,
There was a reason for changing the subject line. I've attatched some
old notes.\x18\x13
Andrew
Target specific commands.
Some *-tdep.c files define target specific commands (the mips-tdep.c
has plenty of examples). If we start adding all of those commands in
then we will get caos.
Choices are:
o delete them
o make them context sensative
(Don't mode me in.) so that they
are only applicable when the
relevant target is active
o re-do the syntax to be target
specific (vis `sim *' that exists
today).
================================================================
Shared library support and target VS host confusion.
A number of valid targets only build native:
hppa1.1-hp-hpux native somsolib.[hc] require native files
hppa1.1-hp-hpux10.20 native ditto
hppa1.1-hp-hpux10.30 native ditto
hppa1.1-hp-hpux11.00 native ditto
hppa1.1-hp-hpux9 native ditto
sparc-sun-solaris2 native Problems with procfs
sparc-sun-sunos native Problems in solib.c
In all cases the problem comes about because the shared library code
assumes that certain headers/functions are present on the build
machine. Long term this should be fixed (however, this will be very
long term).
In the case of these targets the shared library code is also hobbled
by containing certain target specific conditionals. Shared library
support as a target specific issue is complex a shared library
mechansim tends to depend on both the target architecture and the
object file format.
================================================================
Subject: Sketch of OO issues for multi-arch
Date: 21 Oct 1998 08:15:42 -0700
From: (Andrew Cagney)
Organization: Cygnus Solutions news/mail gateway
To:
Newsgroups:
[This should be sgml'd or some-such]
Background.
Part of the multi-arch support within GDB is moving the target
architecture vectors away from hardwired code to a more OO like
arrangement.
A pragmatic restriction on GDB is that it be compilable with an ISO C
compiler so much of the framework being discussed below is required as
a mechanism that works around the lack of an OO language :-)
The status quo:
[Ref: devo/gdb/config/mips/tm-*]
The MIPS tm-*.h files probably best illustrate the two very similar
(but subtly different) techniques being used to build up target-arch
descriptions in the current GDB.
The first technique is to include a fairly generic mips/tm-*.h file
which provides fairly broad mips target definitions and then refine a
subset of those definitions to match the specific mips target of
interest.
The second technique (effectively the reverse of the first) is to
define some target specific macro and then include other tm-* files
which fill in missing parts using the target specific information.
[Ref: devo/gdb/*-tdep.c]
In addition to the target definitions, a target specific *-tdep.c file
is built. Along with a number of target specific functions, this file
contains static pool of target-arch specific variables.
Finally, this file, using the __initialize* function, initialize any
complicated local objects.
Stages:
(Just a reminder)
The initial multi-arch implementation will only allow one
architectural instance at any time. Consequently the first multi-arch
work will not need to worry about parameterizing all architecture
methods with the current architecture. That will be implemented in a
later stage.
Eg:
void f (int parm);
vs void f (struct target *, int parm);
The proposals:
Overview (no surprises here):
Per the architecture document, all target specific architectural
information is moved into a struct. Macro's that were previously
hard-wired to a specific targets definition are replaced with function
calls (via the struct) to the currently selected target code.
Detail - is it in here?
Initialization - registering a target-arch
Both bfd/ and opcodes/ contain a hardwired table of known
architectures customized (using #ifdef) for the toolchain being build.
sim/common/ in a similar fashion has a hardwired table of known
devices.
GDB, on the other hand, for the target-remote modules, uses a
`registrary' approach - each target-remote remote-*.c file registers
its interface during initialization.
My experience from sim/common/ + sim/ppc/ suggests that for
target-arch the target-remote registrary approach would be best.
Each *-tdep.c target-arch would register itself as being responsible
for one or more BFD archures.
Initialization - creating target-arch structures.
Each target may have associated with it a significant number of
architectural variants (For the MIPS, I've lost count!) and each of
these variants would need a separate, different, target-arch
structure.
Several mechanisms for creating these architectures were considered:
making them static; creating them all at initialization time; creating
them on-demand.
The last is to be used. Only when a user selects a target-arch
(implicitly with `file ...', explicitly with `set architecture ..')
will the full target-arch struct be created an populated.
The registrary would also track which target-arch structures have
already been created - thus avoiding duplication.
Creation - inheritance by stealth
As noted in the intro, the existing tm-*.h mechanism uses #include
along with #ifdef and #undef#define to create static target-arch
inheritance. (tm-vr5000.h inherits tm-mips64.h inherits tm-mips.h?).
In a similar fashion, a given target-arch struct will be created by the
more specific architecture code first obtaining a target-arch struct
from a less specific architecture and then refining it to the specific
targets needs.
For instance, we would expect to see either of the initialization
sequences:
vr5000:
obj = create mips-64
refine vr5000 aspects of obj
mips-64:
obj = create mips
refine 64 bit aspects of obj
mips:
obj = create obj
refine mips aspects of obj
and:
vr5000:
obj = create mips
refine mips-64 aspects of obj
refine vr5000 aspects of obj
(`refine mips-64 aspects of obj' would be an operation common to a
number of mips targets).
[Nothing original here, sim/common/ implements this successfully. The
two alternatives roughly correspond to the techniques currently being
used by the existing tm-*.h #include maze]
Method invocation:
Some of the target-arch struct members will be function pointers vis:
struct target_arch {
..
int (*arch_op) (struct target_arch *, int parm);
..
}
The `arch_op' being invoked using the mechanism:
arch->arch_op (arch, ...);
For convenience, macro's (I could make them functions) will be
available that simplify this vis:
#define ARCH_OP(a,p) (a)->arch_op ((a), p)
Notice that I've shown ARCH_OP parameterized with the current
architecture.
During the initial phase, ARCH_OP's definition will not be fully
parameterized vis:
extern struct target_arch target_arch;
#define ARCH_OP(p) (target_arch->arch_op) (p)
For optional functions, a predicate such as ``ARCH_OP_P(a)'' will be
available:
if (ARCH_OP_P ())
ARCH_OP (arg);
Pragmatics: In the longer term, when methods are parameterized with
their object, simplistic macros such as `#define ARCH_OP
(target_arch->arch_op)' which allow tests like if(ARCH_OP) will be
broken.
[Don't stake your life on my naming schema, don't stake your life on
that parameter]
target-arch specific data:
Some target-arch methods use external data (such as the target-remote
or the register file).
Since, initially, only one target can be active at any time this isn't
an issue.
Longer term, when everything becomes parameterized, there will be a
need to pass into target-arch methods the target-vector et.al. objects
that they are to act on.
It may turn out to be easier to have a single object that contains
each of the current target-specific comonents vis:
struct target {
...
struct target_arch *arch;
struct target_remote *remote;
...
}
each target-arch method parameterized with this super object.
[Note: this is an observation of an issue and not a commitment to a
specific solution].
================================================================
Date: Tue, 27 Oct 1998 15:33:46 +1100 (WET)
From: Andrew Cagney <>
To: The Wet Fish <>
Subject: Possible multi-arch testing extension ...
Hello,
This provides an overview of an additional work item that could be added
to the multi-arch GDB project.
The current intention is to test multi-arch functionality by extending
the existing GDB testsuite with a single multi-arch test. That test
would put GDB through its paces in a very rudimentary way - simply
confirming that the same GDB was capable of talking to several different
targets.
Orthogonal to this is the suggestion that the GDB testsuite be modified
so that it can be used to run the full testsuite for all (some sub-set)
of compiled in GDB targets. It's important to note several issues this
possibility raises:
o The overall build environment isn't geared
up for this.
For instance, only a single target (or target) group
are supported by GCC.
Consequently to fully exercise a multi-arch GDB
a number of pre-installed compilers would be needed.
A typical test-run would continue to be focused
on a specific target.
o There are two ways of covering the arch-X-test matrix.
arch-X-test: for all arch ; do for all test ; do ...
and
test-X-arch: for all test; do for all arch ; do ...
Provided the testing framework allows you to limit
a test-run to a specific test or a specific target these
two alternatives are pretty much equivalent.
So.
The additional work item is to investigate ways of changing the GDB test
framework so that it allows the running of the full testsuite against a
number of targets. newlib may well prove to be a useful source of
idea's.
At the conclusion of this work, a single GDB binary could be
demonstrated running the full testsuite for two different architectures.
For the moment I'll treat this as `further work'.
================================================================
Simulators.
Only one builtin simulator target will be supported. This project is
not about supporting multiple internal simulators.
Multiple simulator targets from a single gdb will, eventually, be
supported through the use of separate simulator programs and a remote
serial protocol.
This isn't part of the initial work-plan and is left as a things to
do.
----------------------------------------------------------------
CALL_DUMMY, FIX_CALL_DUMMY, CALL_DUMMY_START_OFFSET,
CALL_DUMMY_LOCATION, PC_IN_CALL_DUMMY et.al.
GDB has two very different mechanisms for implementing inferior
function calls - the old (a bunch of macro's including CALL_DUMMY) and
the new (see blockframe.c).
Key among the differences are: saving the current context locally
instead of on the target stack; and restarting by setting the PC to
the function entry point instead of hacking up a dummy function call
somewhere in the target memory.
Multi-arch must support both - trying to rewrite the old is not within
the scope of this project.
Changes required - the new code is a `done'. The old code will
require the migration of macro's out of inferior.h into valops.c.
CALL_DUMMY_LOCATION should be changed to an enum; CALL_DUMMY needs to
be a char*; SIZEOF_CALL_DUMMY needed; ...
----------------------------------------------------------------
@item BELIEVE_PCC_PROMOTION
@item BELIEVE_PCC_PROMOTION_TYPE
Minor changes required.
coffread.c - the #if can be replaced with an if()else. defs.h - a
default value of zero should be provided. stabsread.c - the suplying
of a default value should be moved to defs.h, the #if mess should be
re-aranged to a set of if()else.
----------------------------------------------------------------
@item CPLUS_MARKER
Changes required.
Since almost all uses of CPLUS_MARKER appear as an initialization
element of static array's the first thought is to replace those static
arrays with dynamic ones. Further investigation, however, suggests
that it will be easier to just rewrite the code using those arrays to
explicitly test against the CPLUS_MARKER character.
cp-valprint.c - Need to rewrite the test in cp_is_vtbl_ptr_type() so
that it explictily tests for CPLUS_MARKER=='.'. Better might be to
use that common struct.
demangle.c - rewrite is_cplus_marker() to test for c==CPLUS_MARKER
explicitily.
Long term, since this is dynamic, there is no reason for not adding a
command to gdb so that the user can set/query it. Might even serve as
an excuse for the demangle.c tweeks that need to be made.
----------------------------------------------------------------
@item DECR_PC_AFTER_BREAK et.al.
No changes required.
In the short term this can just be another target variable. In the
longer term it would probably be a good idea to push this whole
problem into the target so that GDB never knows about post breapoint
pc decrementing.
----------------------------------------------------------------
@item EXTRA_FRAME_INFO
@item INIT_EXTRA_FRAME_INFO
@item INIT_FRAME_PC_FIRST
@item INIT_FRAME_PC
Changes required.
Per target data being stored in `struct frame_info'. In OO terms, a
target specific frame object inheriting from the generic frame_info
object.
Will need to replace that data with a reference to target specific
data. Will need functions for all those INIT_*FRAME* operations.
----------------------------------------------------------------
@item GCC_COMPILED_FLAG_SYMBOL
@item GCC2_COMPILED_FLAG_SYMBOL
Changes required.
Make these target specific pointers. symtab.h - delete the default
definitions of *_COMPILED_FLAG_SYMBOL.
----------------------------------------------------------------
@item GDB_TARGET_IS_HPPA
@item GDB_TARGET_IS_MACH386
@item GDB_TARGET_IS_SUN3
@item GDB_TARGET_IS_SUN386
@item IBM6000_TARGET
Later, much later.
These will be the first against the wall when the revolution comes.
Or, to put it another way, we'll wear these until they can be deleted
at the end of multi-arch conversion.
----------------------------------------------------------------
@item GET_LONGJMP_TARGET
Changes required.
Delete default definition of GET_LONGJMP_TARGET from infrun.c. Add a
function that returns a default value. Always implement
GET_LONGJMP_TARGET for all *-tdep.c's.
Will encounter namespace problems - get_longjmp_target() is overloaded
-> need to rename target specific versions of this function.
----------------------------------------------------------------
@item IN_SOLIB_TRAMPOLINE pc name
This is dead. It was replaced by:
@item IN_SOLIB_CALL_TRAMPOLINE
@item IN_SOLIB_RETURN_TRAMPOLINE
----------------------------------------------------------------
@item KERNEL_DEBUGGING
Later. This is for an obscure (well I think it is) target that will
hopefully allow everything to go away.
----------------------------------------------------------------
@item NO_HIF_SUPPORT
Later. This is for an obscure target.
----------------------------------------------------------------
@item PC_REGNUM
@item PS_REGNUM
@item TARGET_WRITE_PC et.al.
@item NPC_REGNUM
@item NNPC_REGNUM
@item MAX_REGISTER_RAW_SIZE
@item REGISTER_VIRTUAL_TYPE
@item NUM_REGS
@item MAX_REGISTER_VIRTUAL_SIZE
@item REGISTER_RAW_SIZE
@item REGISTER_VIRTUAL_SIZE
@item REGISTER_BYTE
@item PRINT_REGISTER_HOOK (regno)
Arrrrh. Ah, that feels better.
Date: Mon, 26 Oct 1998 16:44:25 +1100 (WET)
From: Andrew Cagney <>
To:
Subject: registers part of target-arch object
[With additional edits]
An FYI more than anything.
Most of the architecture specific code is `static' in that it doesn't
change for a given target.
Select a specific architecture and one can define a set of functions
that describe that architecture's functionality.
The quirk with this is the `register set'. At present targets describe
registers in an implementation specific way - the target-arch's assume
that GDB has some physical block of of memory that contains all
registers.
In adding multi-arch support I've two alternatives:
o stick with this existing code (at least
in the short term).
o come up with some new and exciting
register description.
My intention is to stick with the existing code. In particular:
o have each target architecture continue to describe
registers at this implementation specific way.
This limits the potential damage to all the target
config/*/tm-* that will need converting.
o bind the register data 1-1 to the target architecture
it belongs to. This limits GDB to one active instance
of a specific target. (GDB can't simultaneously to
several physical targets of the same architecture
aka unrestricted mixed-arch support).
This limits the potential damage to the generic
gdb register code (such as valops.c).
The consequences of the second point are especially important:
o It leaves GDB with the restriction of an architecture
being bound to a single physical target at any time.
(VS actively debugging several targets each with
the same architecture.)
o It doesn't stop GDB being attached to several
physical targets, each with a different architecture.
o It doesn't stop GDB being modified so that a
target architecture contains an internal mechanism
that switchs between target interfaces.
It is only that externally there appears to be a single
register interface.
o It doesn't attempt to address the issue of how the
overall GDB architecture should be should be changed
that it fully supports mixed-architectures.
That issue is beyond the scope of the current work.
The overall consequences are:
o limited collateral damage
We're not trying to rewrite the register code
at the same time as we introduce multi-arch.
o register re-design becomes feasible
Once the multi-arch framework is in place
significant cross-architecture changes such
as a new register mechanism become feasible.
o mixed-arch unhindered.
As per the revised multi-arch objectives:
``The objective is to add multi-arch support in a way
that doesn't hinder the following goals [multi-arch]''
We've made significant improvements without
commiting ourselves to a specific mixed-arch design.
================================================================
Turns out that defining TARGET_{FETCH,STORE}_PC does not oblivate the
need for PC_REGNUM. See write_register_gen.
parse.c:std_regs[]. Hmm, this should just be thrown back at the
target. For moment just disable it...
I think value_ptr should go!
GET_SAVED_REGISTER should define the function to call not just flip
the code.
enum target_signal doesn't get correctly exposed for everything to work.
================================================================
Phase two:
VARIABLES_INSIDE_BLOCK: Only sparc and convex.
SUN_FIXED_LBRAC_BUG: Only sparc/m78k.
PCC_SOL_BROKEN: Only convex
DISABLE_UNSETTABLE_BREAK: I some config/*/tm-*.h's are including
"solib.h" which is in turn defining DISABLE_UNSETTABLE_BREAK. An
example of this is tm-sunos.h. Interestingly, many config/nm-*.h's
also include "solib.h" which suggests that shared library support as a
pure target operation isn't quite there yet. :-(. In the long run, a
revamping of the shared library stuff so that it is truely based on
the selected target is needed, in the mean time, limiting shared
library to single-arch GDB's will be easier.
================================================================
Phase three:
SYMBOL_RELOADING_DEFAULT: Delete. No longer defined in current
sources.
SHIFT_INST_REGS: Only used by *old* m88k targets. Called from infrun.c
and infcmd.c. In both cases it can probably be re-vamped so that it
totally goes away.
PROLOGUE_FIRSTLINE_OVERLAP: This is only applicable to the convex
target which we don't even try to build!
BREAKPOINT, BIG_BREAKPOINT, LITTLE_BREAKPOINT: Delete this, replace
them with BREAKPOINT_FROM_PC.
REMOTE_BREAKPOINT, BIG_REMOTE_BREAKPOINT, LITTLE_REMOTE_BREAKPOINT:
Targets that use this are not supported (sh, m68k, h830).
USE_STRUCT_CONVENTION: Function of type use_struct_convention_fn.
PRINT_TYPELESS_INTEGER: Don't bother fixing this one.
OS9K_VARIABLES_INSIDE_BLOCK: I think that this is dead.
PC_LOAD_SEGMENT: Specific xcoff (rs6000). Is actually an object file
macro. Should be re-written so that all object file handlers provide
a similar module.
CORE_ADDR: This does not specify a type that exactly fits a target
address. Consequently, a 64 bit unsigned integer will be sufficient,
in the short term, as the CORE_ADDR address. Longer term we want some
sort of object.
CHILL_PRODUCER, GCC_PRODUCER, GPLUS_PRODUCER, LCC_PRODUCER: These
macro's don't have anything to do with the target. Rather they are
concerned with object file formats and and identifying characteristics
of same. Perhaphs they are better placed in BFD?
END_OF_TEXT_DEFAULT: This macro is really specific to the GOULD
architecture. It may well be possible to put this off until when it
isn't needed.
================================================================
Not documented:
MAX_REGISTER_RAW_SIZE
REGISTER_VIRTUAL_TYPE
NUM_REGS
VALUE_OF_TRAPPED_INTERNALVAR
CALL_DUMMY_START_OFFSET
FRAME_ARGS_SKIP
MAX_REGISTER_VIRTUAL_SIZE
REGISTER_RAW_SIZE
REGISTER_VIRTUAL_SIZE
REGISTER_BYTE
SET_TRAPPED_INTERNALVAR
FRAME_ARGS_ADDRESS
FRAME_LOCALS_ADDRESS
FIX_CALL_DUMMY
STORE_STRUCT_RETURN
SAVED_PC_AFTER_CALL
================================================================
Check list:
Registers
Types
Call Dummy
Registrary
A0_REGNUM
A2_REGNUM
A3_REGNUM
ADDR_BITS_REMOVE
AS_PROC_NAME_FMT
ATTACH_DETACH
BADVADDR_REGNUM
BELIEVE_PCC_PROMOTION
BIG_ENDIAN
BPT_ELEM_SZ
BREAKPOINT_FROM_PC
BROKEN_SIGINFO_H
CALL_DUMMY
CALL_DUMMY_ADDRESS
CALL_DUMMY_BREAKPOINT_OFFSET
CALL_DUMMY_LENGTH
CALL_DUMMY_LOCATION
CALL_DUMMY_START_OFFSET
CANNOT_STORE_REGISTER
CAUSE_REGNUM
CHILD_PREPARE_TO_STORE
CHILD_SPECIAL_WAITSTATUS
COERCE_FLOAT_TO_DOUBLE
CONVERT_FROM_FUNC_PTR_ADDR
CPLUS_MARKER
CR_REGNUM
CTL_PROC_NAME_FMT
CTR_REGNUM
D2_REGNUM
D3_REGNUM
DECR_PC_AFTER_BREAK
DEFAULT_LR_SAVE
DEFAULT_MIPS_TYPE
DEFAULT_PROMPT
DO_REGISTERS_INFO
DWARF_REG_TO_REGNUM
Dest_Reg
E0_REGNUM
ECOFF_REG_TO_REGNUM
ELF_MAKE_MSYMBOL_SPECIAL
ELF_OBJECT_FORMAT
EXTRACT_RETURN_VALUE
EXTRACT_STRUCT_VALUE_ADDRESS
EXTRA_FRAME_INFO
FAULTED_USE_SIGINFO
FCRCS_REGNUM
FCRIR_REGNUM
FETCH_INFERIOR_REGISTERS
FIFO_BPT_CNT
FIFO_BPT_TBL
FIRST_COP0_REG
FIRST_EMBED_REGNUM
FIRST_SP_REGNUM
FIRST_VEC_REG
FIVE_ARG_PTRACE
FIX_CALL_DUMMY
FP0_REGNUM
FPA0_REGNUM
FPLAST_REGNUM
FP_REGNUM
FRAMELESS_FUNCTION_INVOCATION
FRAME_ARGS_ADDRESS
FRAME_ARGS_SKIP
FRAME_CHAIN
FRAME_CHAIN_VALID
FRAME_CHAIN_VALID_ALTERNATE
FRAME_FIND_SAVED_REGS
FRAME_LOCALS_ADDRESS
FRAME_NUM_ARGS
FRAME_SAVED_PC
FUNCTION_START_OFFSET
GDBINIT_FILENAME
GDB_COMM_AREA
GDB_COMM_SIZE
GDB_TARGET_IS_MIPS64
GDB_TARGET_MASK_DISAS_PC
GDB_TARGET_POWERPC
GDB_TARGET_UNMASK_DISAS_PC
GET_LONGJMP_TARGET
GET_SAVED_REGISTER
GP0_REGNUM
HANDLE_SVR4_EXEC_EMULATORS
HAVE_NONSTEPPABLE_WATCHPOINT
HAVE_SIGSETMASK
HAVE_TERMIO
HAVE_TERMIOS
HI_REGNUM
HOST_BYTE_ORDER
IBM6000_TARGET
IEEE_FLOAT
IGNORE_HELPER_CALL
INIT_EXTRA_FRAME_INFO
INIT_FRAME_PC
INIT_FRAME_PC_FIRST
INNER_THAN
IN_SIGTRAMP
IN_SOLIB_CALL_TRAMPOLINE
IN_SOLIB_RETURN_TRAMPOLINE
IS_MIPS16_ADDR
JB_ELEMENT_SIZE
JB_G1
JB_NPC
JB_O0
JB_ONSSTACK
JB_PC
JB_PSR
JB_SIGMASK
JB_SP
JB_WBCNT
KERNEL_U_ADDR
KERNEL_U_SIZE
LAR_REGNUM
LAST_DEVICE
LAST_EMBED_REGNUM
LAST_SP_REGNUM
LIR_REGNUM
LO_REGNUM
LR_REGNUM
LSEEK_NOT_LINEAR
MACHINE_CPROC_FP_OFFSET
MACHINE_CPROC_PC_OFFSET
MACHINE_CPROC_SP_OFFSET
MAKE_MIPS16_ADDR
MAP_PROC_NAME_FMT
MAX_REGISTER_RAW_SIZE
MAX_REGISTER_VIRTUAL_SIZE
MDR_REGNUM
MIPS16_INSTLEN
MIPS_DEFAULT_FPU_TYPE
MIPS_EABI
MIPS_EFI_SYMBOL_NAME
MIPS_FPU_DOUBLE_REGSIZE
MIPS_FPU_SINGLE_REGSIZE
MIPS_INSTLEN
MIPS_LAST_ARG_REGNUM
MIPS_LAST_FP_ARG_REGNUM
MIPS_NUMREGS
MIPS_NUM_ARG_REGS
MIPS_REGSIZE
MQ_REGNUM
MSYMBOL_IS_SPECIAL
MSYMBOL_SIZE
NBPG
NM_NEWS_MIPS_H
NM_RS6000LYNX_H
NULL
NUM_COP0_REGS
NUM_CORE_REGS
NUM_REGS
NUM_VIF_REGS
NUM_VU_INTEGER_REGS
NUM_VU_REGS
ONE_PROCESS_WRITETEXT
OP_LDFPR
OP_LDGPR
PCB_OFFSET
PC_IN_CALL_DUMMY
PC_LOAD_SEGMENT
PC_REGNUM
POP_FRAME
PRID_REGNUM
PRINT_EXTRA_FRAME_INFO
PROCESS_LINENUMBER_HOOK
PRSVADDR_BROKEN
PSW_REGNUM
PS_REGNUM
PTRACE_ARG3_TYPE
PTRACE_ATTACH
PTRACE_DETACH
PUSH_ARGUMENTS
PUSH_DUMMY_FRAME
PUSH_RETURN_ADDRESS
R5900_128BIT_GPR_HACK
RA_REGNUM
REGISTER_BYTE
REGISTER_BYTES
REGISTER_CONVERTIBLE
REGISTER_CONVERT_FROM_TYPE
REGISTER_CONVERT_TO_RAW
REGISTER_CONVERT_TO_TYPE
REGISTER_CONVERT_TO_VIRTUAL
REGISTER_NAMES
REGISTER_NAME_ALIAS_HOOK
REGISTER_RAW_SIZE
REGISTER_SIZE
REGISTER_U_ADDR
REGISTER_VIRTUAL_SIZE
REGISTER_VIRTUAL_TYPE
REG_STRUCT_HAS_ADDR
REQUEST_QUIT
ROOTED_P
SAVED_BYTES
SAVED_FP
SAVED_PC
SAVED_PC_AFTER_CALL
SETPGRP_ARGS
SETUP_ARBITRARY_FRAME
SIGCONTEXT_PC_OFFSET
SIGFRAME_BASE
SIGFRAME_FPREGSAVE_OFF
SIGFRAME_PC_OFF
SIGFRAME_REGSAVE_OFF
SIGFRAME_REG_SIZE
SIGWINCH_HANDLER
SIGWINCH_HANDLER_BODY
SIG_FRAME_FP_OFFSET
SIG_FRAME_LR_OFFSET
SIG_FRAME_PC_OFFSET
SKIP_PROLOGUE
SKIP_TRAMPOLINE_CODE
SLASH_CHAR
SLASH_P
SLASH_STRING
SOFTWARE_SINGLE_STEP
SOFTWARE_SINGLE_STEP_P
SOFUN_ADDRESS_MAYBE_MISSING
SOLIB_ADD
SOLIB_CREATE_INFERIOR_HOOK
SP_REGNUM
SR_REGNUM
STAB_REG_TO_REGNUM
STACK_END_ADDR
START_INFERIOR_TRAPS_EXPECTED
STATIC_TRANSFORM_NAME
STATUS_PROC_NAME_FMT
STEP_SKIPS_DELAY
STEP_SKIPS_DELAY_P
STOPPED_BY_WATCHPOINT
STORE_RETURN_VALUE
STORE_STRUCT_RETURN
T9_REGNUM
TABULAR_REGISTER_OUTPUT
TARGET_BYTE_ORDER
TARGET_BYTE_ORDER_SELECTABLE
TARGET_CAN_USE_HARDWARE_WATCHPOINT
TARGET_HAS_HARDWARE_WATCHPOINTS
TARGET_KEEP_SECTION
TARGET_LONG_BIT
TARGET_LONG_LONG_BIT
TARGET_MIPS
TARGET_MN10300
TARGET_MONITOR_PROMPT
TARGET_PTR_BIT
TARGET_READ_FP
TARGET_READ_PC
TARGET_READ_SP
TARGET_REDEFINE_DEFAULT_OPS
TARGET_SYMFILE_POSTREAD
TARGET_VIRTUAL_FRAME_POINTER
TARGET_WRITE_FP
TARGET_WRITE_SP
TEXT_SEGMENT_BASE
TM_MIPS_H
TM_PPCLE_EABI_H
TM_PPCLE_SIM_H
TM_PPC_AIX_H
TM_PPC_EABI_H
TM_PPC_NW_H
TM_PPC_SIM_H
TM_PRINT_INSN_MACH
TM_RS6000LYNX_H
TM_RS6000_AIX4_H
TM_TXVU_H
TOC_REGNUM
TRACE_CLEAR
TRACE_FLAVOR
TRACE_FLAVOR_SIZE
TRACE_SET
TXVU_CPU_NUM
TXVU_SET_CPU_HELP_STRING
TXVU_VIF_BRK_MASK
TXVU_VU_BRK_MASK
UNMAKE_MIPS16_ADDR
UNUSED_REGNUM
UPAGES
USE_GENERIC_DUMMY_FRAMES
USE_O_NOCTTY
USE_PROC_FS
USE_STRUCT_CONVENTION
USG
U_REGS_OFFSET
V0_REGNUM
VIF0_PC_REGNUM
VIF1_PC_REGNUM
VU0_PC_REGNUM
VU0_RA_REGNUM
VU0_SP_REGNUM
VU1_PC_REGNUM
VU1_RA_REGNUM
VU1_SP_REGNUM
VX_NUM_REGS
XER_REGNUM
XM_RS6000LYNX_H
ZERO_REGNUM
_BSD_COMPAT
setpgrp
target_insert_watchpoint
target_remove_watchpoint
vfork
From eliz@delorie.com Sat Apr 01 00:00:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: Pierre Muller <muller@cerbere.u-strasbg.fr>
Cc: gdb@sourceware.cygnus.com, Elena Zannoni <ezannoni@cygnus.com>
Subject: Re: Buffering problems with "gdb < foo"
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200003070851.DAA14463@indy.delorie.com>
References: <200003070845.JAA27855@cerbere.u-strasbg.fr>
X-SW-Source: 2000-q1/msg00558.html
Content-length: 675
> dir needs no confirmation if not invoked from tty !
Did you actually look at the from_tty variable's value inside
dir_command? I don't have the GDB 5.0 binary here, but GDB certainly
*does* ask for confirmation if invoked with stdin and stdout
redirected, at least in the DJGPP version. Elena, is that a bug?
Anyway, the basic point is still valid, even if this particular
example is not: when stdin is redirected to a file, GDB should turn
editing off.
> I think its because y is not a valid GDB command !
Invalid commands don't cause GDB to exit, they just result in an error
message. It would be inconceivable to have GDB exit every time I
mistype a command ;-).
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: Jim Kingdon <kingdon@redhat.com>, gdb@sourceware.cygnus.com
Subject: Re: New file gdb/CONTRIBUTE guidelins for the contributor
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38A5FA15.CA467765@cygnus.com>
References: <38A3B39A.D3C7650C@cygnus.com> <38A3780F.2FE7A510@cygnus.com> <bg0v08f69.fsf@rtl.cygnus.com> <200002111929.OAA13997@mescaline.gnu.org>
X-SW-Source: 2000-q1/msg00247.html
Content-length: 719
Eli Zaretskii wrote:
>
> Andrew Cagney writes:
>
> > > So having said all that, do you still want submit.html or equivalent
> > > in the distribution? Having it both places seems like kind of a
> > > maintenance pain and seems to me that having the distribution point
> > > to the web site probably works.
> >
> > Yes, I think the GDB distribution should contain the document.
>
> Perhaps it is better to make this document part of the GDB manual.
> Then we could be sure it won't be forgotten due to changing fortunes
> of time...
In the end that could well prove to be the best place for it. I'd
prefer to have something in the top directory though so that we can
avoid the RTFM response :-)
enjoy,
Andrew
From totohero@poppy.snu.ac.kr Sat Apr 01 00:00:00 2000
From: "Lim, Sung-taek" <totohero@poppy.snu.ac.kr>
To: "crossgcc mailinglist" <crossgcc@sourceware.cygnus.com>, <gdb@sourceware.cygnus.com>
Subject: Breakpoint problem when running on gdb-4.18 arm/thumb simulator target
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <001401bf5db1$10157720$8f742e93@snu.ac.kr>
X-SW-Source: 2000-q1/msg00026.html
Content-length: 839
I built gdb-4.18 as arm (or thumb) target and tested a simple program which
was
compiled with arm-elf(or thumb-elf) target cross gcc. gdb abnormally exits
running
the program when reached any breakpoint. Internally gdb replaces instruction
at the breakpoint with another instruction which represents it's breakpoint
but
actually arm instruction simulator decoded it as undefined instruction or
undefined
kind of software interrupt. So we modified it and generated patch file which
includes
additional modification. (unfortunately I don't know much about it which was
done
by another member of our work group) Any kind of advice is welcome.
the patch can be found at:
http://poppy.snu.ac.kr/~totohero/arm-linux/gdb-4.18-dal-patch
(any other better place?)
--
Lim, Sung-taek
totohero@poppy.snu.ac.kr
http://poppy.snu.ac.kr/~totohero/
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2000-04-01 0:00 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <38C585BB.3F7B1AC7@apple.com>
[not found] ` <20000307155806.A30106@valinux.com>
[not found] ` <5mg0u2l3g0.fsf@jtc.redbacknetworks.com>
[not found] ` <20000307162127.D485@lucon.org>
[not found] ` <200003080044.e280iGB00429@delius.kettenis.local>
[not found] ` <5m4saivyew.fsf@jtc.redbacknetworks.com>
2000-04-01 0:00 ` A patch for gnu-regex Andrew Cagney
2000-04-01 0:00 ` H . J . Lu
[not found] ` <20000307211842.C1573@lucon.org>
[not found] ` <5mvh2yugpy.fsf@jtc.redbacknetworks.com>
[not found] ` <20000308091030.B3150@lucon.org>
[not found] ` <200003081758.SAA17064@landau.wins.uva.nl>
2000-04-01 0:00 ` H . J . Lu
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox