* Re: Running the inferior from breakpoint commands
[not found] ` <200003182228.RAA07061@indy.delorie.com>
@ 2000-04-01 0:00 ` Mark Kettenis
0 siblings, 0 replies; only message in thread
From: Mark Kettenis @ 2000-04-01 0:00 UTC (permalink / raw)
To: eliz; +Cc: gdb
Date: Sat, 18 Mar 2000 17:28:26 -0500 (EST)
From: Eli Zaretskii <eliz@delorie.com>
Perhaps you could apply the patch I sent and see if this test now
works on these platforms.
I'll do that eventually, but probably not in the next week.
Mark
From fche@cygnus.com Sat Apr 01 00:00:00 2000
From: fche@cygnus.com (Frank Ch. Eigler)
To: gdb@sourceware.cygnus.com
Cc: Stephane.Bihan@arccores.com
Subject: Re: how to integrate an ISS target in the gdb tree
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <o5d7opqr6x.fsf@toenail.to.cygnus.com>
References: <OF44E75EE3.DD68FAE0-ON802568A8.0056F26A@risccores.com>
X-SW-Source: 2000-q1/msg00747.html
Content-length: 769
> [...]
> I only need to integrate the simulator I guess. All the sources are in
> sim/arc.
Take a look at src/sim/README-HACKING. It has some bits and pieces on
the subject. The main other things to watch for are:
* sim/configure.in - to map target triples to sim/<processor> subdirs
Add a clause for your target.
* sim/<processor>/Makefile.in and configure.in - source tree build skeleton
If you're using sim/common, copy these files from anther port such as d30v,
mips, fr30.
* populate sim/<processor> and get things running.
* Send a pack of patches. We can tidy up the build system here, if needed.
I believe we will need an FSF copyright assignment, so you may want to get
started on that paperwork in parallel.
- FChE
From eliz@delorie.com Sat Apr 01 00:00:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: Fernando Nasser <fnasser@cygnus.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: 14 chars limit [Was: Re: Moving Linux-specific stuff out of
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200003091238.HAA19879@indy.delorie.com>
References: <38C6D2DC.44C3FC6@cygnus.com> <200003082121.e28LLRu05681@delius.kettenis.local>
X-SW-Source: 2000-q1/msg00639.html
Content-length: 212
> There are several files now with 14+ chars. I am just about to add
> one (with 16).
>
> Is this still relevant?
I would ask to make the files unique when truncated to 8.3 limits, if
that's possible. Thanks!
From kettenis@wins.uva.nl Sat Apr 01 00:00:00 2000
From: Mark Kettenis <kettenis@wins.uva.nl>
To: gdb@sourceware.cygnus.com
Subject: Restructuring i386_extract_return_value
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200003092241.e29Mfow00303@delius.kettenis.local>
X-SW-Source: 2000-q1/msg00660.html
Content-length: 7725
Hi,
Here are some other changes that I'm planning to make to the generic
ix86 code. Since this affect several of the i386 targets I'd like to
give the people involved with those targets the opportunity to object
:-). The benefits are clear: support for `long long' return values on
all targets that use this, and support for all floating-point types
(including `long double') on all targets where GDB can access the FPU.
Looking at the GCC sources and the Intel documentation, I believe that
the attached patch is the right thing to do. Please refer to the
detailed description below.
I have verified that all targets that use i386_extract_return_value
share the same register layout for the %eax and %edx registers.
In addition to the attached patch some cleanup of the various tm-*.h
files will be needed (remove definitions of {LOW,HIGH}_RETURN_REGNUM,
get rid of the I386_*_TARGET defines where possible), I also think
that the redefinition of EXTRACT_RETURN_VALUE in tm-i386v.h can go.
Comments are welcome!
Mark
Return values
-------------
There are three issues related to function return values: (1)
floating-point return values, (2) 64-bit integer return values and (3)
`struct' return values.
1. The majority of i386 targets in GCC return floating-point values by
default on the FPU stack. In fact the only exception is NeXT.
There is a switch `-mno-fp-ret-in-387' to force GCC to return
floating-point values in the ordinary CPU registers. I don't think
this can be determined from the debugging information. Is it worth
adding a i386 target specific option to enable people to debug
this code? Propably not.
It seems reasonable to make i386-tdep.c:i386_extract_return_value()
look for floating-point return values on the FPU stack if
NUM_FREGS > 0, and issue a warning otherwise.
Targets that return floating-point values in the CPU registers
should provide their own function to extract return values, and
override EXTRACT_RETURN_VALUE. Since NeXT isn't supported by GDB
this isn't an issue right now.
2. As far as I can tell, all i386 targets return `long long' values in
eax (low word) and edx (high word). This makes sense since this is
the convention used by the machine instructions themselves. The
relevant GCC code suggests that in addition to eax and edx, ecx
might also be used for 12-byte values (then edx is the "middle"
word, and ecx the high word). But since GCC doesn't have a 12-byte
integer type (would that make sense?) this should never occur.
However, the full 12-byte range is used for returning extended
floating-point numbers (`long double'). Right now this is only
implemented for AIX, Linux and DJGPP, but this should be made more
general.
3. GCC can return `struct' and `union' values in registers when their
size and alignment match some integer type. This is the default on
several platforms where GCC is the only compiler (*BSD), and
specified by the Win32 ABI (which is also used by Cygwin).
Platforms that use the System V ABI (such as Linux) do not do this
by default. Again there are switches (`-fpcc-struct-return' and
`-freg-struct-return') that override the default. The behaviour is
governed by USE_STRUCT_CONVENTION, and the default seems to be not
to expect "small" structs to be returned in the registers unless
GCC 1.x was used. This seems to be wrong for systems where
-freg-struct-return is the default.
2000-03-09 Mark Kettenis <kettenis@gnu.org>
* i386-tdep.c (LOW_RETURN_REGNUM, HIGH_RETURN_REGNUM): New defines.
(i386_extract_return_value): Rewritten. Correctly support all
floating-point types and large integer types on targets that use
the standard i386 GDB register layout and return floating-point
values in the FPU.
Index: i386-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/i386-tdep.c,v
retrieving revision 1.6
diff -u -p -r1.6 i386-tdep.c
--- i386-tdep.c 2000/03/08 22:34:18 1.6
+++ i386-tdep.c 2000/03/09 22:03:54
@@ -698,56 +698,66 @@ get_longjmp_target (pc)
#endif /* GET_LONGJMP_TARGET */
+/* These registers are used for returning integers (and on some
+ targets also for returning `struct' and `union' values when their
+ size and alignment match an integer type. */
+#define LOW_RETURN_REGNUM 0 /* %eax */
+#define HIGH_RETURN_REGNUM 2 /* %edx */
+
+/* Extract from an array REGBUF containing the (raw) register state, a
+ function return value of TYPE, and copy that, in virtual format,
+ into VALBUF. */
+
void
-i386_extract_return_value (type, regbuf, valbuf)
- struct type *type;
- char regbuf[REGISTER_BYTES];
- char *valbuf;
+i386_extract_return_value (struct type *type, char *regbuf, char *valbuf)
{
- /* On AIX, i386 GNU/Linux and DJGPP, floating point values are
- returned in floating point registers. */
- /* FIXME: cagney/2000-02-29: This function needs to be rewritten
- using multi-arch. Please don't keep adding to this #ifdef
- spaghetti. */
-#if defined(I386_AIX_TARGET) || defined(I386_GNULINUX_TARGET) || defined(I386_DJGPP_TARGET)
+ int len = TYPE_LENGTH (type);
+
if (TYPE_CODE_FLT == TYPE_CODE (type))
{
- double d;
- /* 387 %st(0), gcc uses this */
- floatformat_to_double (&floatformat_i387_ext,
-#if defined(FPDATA_REGNUM)
- ®buf[REGISTER_BYTE (FPDATA_REGNUM)],
-#else /* !FPDATA_REGNUM */
- ®buf[REGISTER_BYTE (FP0_REGNUM)],
-#endif /* FPDATA_REGNUM */
+ if (NUM_FREGS == 0)
+ {
+ warning ("Cannot find floating-point return value.");
+ memset (valbuf, 0, len);
+ }
- &d);
- store_floating (valbuf, TYPE_LENGTH (type), d);
+ /* Floating-point return values can be found in %st(0). */
+ if (len == TARGET_LONG_DOUBLE_BIT / TARGET_CHAR_BIT
+ && TARGET_LONG_DOUBLE_FORMAT == &floatformat_i387_ext)
+ {
+ /* Copy straight over, but take care of the padding. */
+ memcpy (valbuf, ®buf[REGISTER_BYTE (FP0_REGNUM)],
+ FPU_REG_RAW_SIZE);
+ memset (valbuf + FPU_REG_RAW_SIZE, 0, len - FPU_REG_RAW_SIZE);
+ }
+ else
+ {
+ /* Convert the extended floating-point number found in
+ %st(0) to the desired type. This is probably not exactly
+ how it would happen on the target itself, but it is the
+ best we can do. */
+ DOUBLEST val;
+ floatformat_to_doublest (&floatformat_i387_ext,
+ ®buf[REGISTER_BYTE (FP0_REGNUM)], &val);
+ store_floating (valbuf, TYPE_LENGTH (type), val);
+ }
}
else
-#endif /* I386_AIX_TARGET || I386_GNULINUX_TARGET || I386_DJGPP_TARGET */
{
-#if defined(LOW_RETURN_REGNUM)
- int len = TYPE_LENGTH (type);
int low_size = REGISTER_RAW_SIZE (LOW_RETURN_REGNUM);
int high_size = REGISTER_RAW_SIZE (HIGH_RETURN_REGNUM);
if (len <= low_size)
- memcpy (valbuf, regbuf + REGISTER_BYTE (LOW_RETURN_REGNUM), len);
+ memcpy (valbuf, ®buf[REGISTER_BYTE (LOW_RETURN_REGNUM)], len);
else if (len <= (low_size + high_size))
{
memcpy (valbuf,
- regbuf + REGISTER_BYTE (LOW_RETURN_REGNUM),
- low_size);
+ ®buf[REGISTER_BYTE (LOW_RETURN_REGNUM)], low_size);
memcpy (valbuf + low_size,
- regbuf + REGISTER_BYTE (HIGH_RETURN_REGNUM),
- len - low_size);
+ ®buf[REGISTER_BYTE (HIGH_RETURN_REGNUM)], len - low_size);
}
else
- error ("GDB bug: i386-tdep.c (i386_extract_return_value): Don't know how to find a return value %d bytes long", len);
-#else /* !LOW_RETURN_REGNUM */
- memcpy (valbuf, regbuf, TYPE_LENGTH (type));
-#endif /* LOW_RETURN_REGNUM */
+ internal_error ("Cannot extract return value of %d bytes long.", len);
}
}
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: INSTALL set incorrectly in gdb/doc/Makefile
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38BCDC1C.2917C1D6@cygnus.com>
References: <200002270838.DAA25037@indy.delorie.com>
X-SW-Source: 2000-q1/msg00467.html
Content-length: 937
Eli Zaretskii wrote:
>
> Does anyone else see problems with the value of INSTALL in
> gdb/doc/Makefile?
>
> In my case, it gets set to "../". I did a bit of digging, and it
> seems that the reason is that gdb/configure uses ac_given_INSTALL
> right before it recurses into gdb/doc, but ac_given_INSTALL is not set
> anywhere except config.status, which runs in a separate shell.
>
> I initially thought it was specific to DJGPP, but the above seems
> quite general...
Trying a configure on a bsd system I see:
$ grep '^INSTALL' gdb/doc/Makefile
INSTALL = /usr/bin/install -c
INSTALL_PROGRAM = ${INSTALL}
INSTALL_DATA = ${INSTALL} -m 644
> Am I missing something?
I'm not sure.
A guess is that your system doesn't have a real install program so
configure is trying to set things up for src/install-sh
(../../install-sh) Some how the ``install-sh'' (../install-sh) is
getting lost. Look for ac_install_sh in configure.
Andrew
From kingdon@redhat.com Sat Apr 01 00:00:00 2000
From: Jim Kingdon <kingdon@redhat.com>
To: gdb@sourceware.cygnus.com
Subject: Re: help all?
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <bk8kfw9ip.fsf@rtl.cygnus.com>
References: <38A09F77.592FF0A5@cygnus.com>
X-SW-Source: 2000-q1/msg00179.html
Content-length: 420
> The list of all commands is really too big for being the default, but
> a "help all" would not hurt anyone and make others happy.
Not sure I have a strong reaction one way or the other (it sort of
feels like a creeping feature which few people would notice/use but
then again it seems harmless enough). One thing I did notice in the
process of investigating is that "help help" is not nearly detailed
enough.
From ezannoni@cygnus.com Sat Apr 01 00:00:00 2000
From: Elena Zannoni <ezannoni@cygnus.com>
To: gdb@sourceware.cygnus.com
Subject: arguments to add-symbol-file
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <14554.41686.732151.870885@kwikemart.cygnus.com>
X-SW-Source: 2000-q1/msg00781.html
Content-length: 1022
Why when we use
add-symbol-file <file> 0x1000 0x2000 0x3000
gdb ends up with the following addrs structure, which includes explicit
entries for .text, .data, and .bss section, plus the same 3 entries
repeated in the 'other' array?
Would it make sense to have only the 'other' part, or not include
those three in 'other'?
(top-gdb) p/x *addrs
$35 = {text_addr = 0x1000, data_addr = 0x2000, bss_addr = 0x3000, other = {{
addr = 0x1000, name = 0x388510, sectindex = 0x0}, {addr = 0x2000,
name = 0x388500, sectindex = 0x2}, {addr = 0x3000, name = 0x3884f0,
sectindex = 0x3}, {addr = 0x0, name = 0x0,
sectindex = 0x0} <repeats 37 times>}}
(top-gdb) p *addrs
$36 = {text_addr = 4096, data_addr = 8192, bss_addr = 12288, other = {{
addr = 4096, name = 0x388510 ".text", sectindex = 0}, {addr = 8192,
name = 0x388500 ".data", sectindex = 2}, {addr = 12288,
name = 0x3884f0 ".bss", sectindex = 3}, {addr = 0, name = 0x0,
sectindex = 0} <repeats 37 times>}}
Thanks
Elena
From Peter.Schauer@regent.e-technik.tu-muenchen.de Sat Apr 01 00:00:00 2000
From: "Peter.Schauer" <Peter.Schauer@regent.e-technik.tu-muenchen.de>
To: jimb@zwingli.cygnus.com (Jim Blandy)
Cc: gdb@sourceware.cygnus.com
Subject: Re: unloading shared objects
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200003131759.SAA07581@reisser.regent.e-technik.tu-muenchen.de>
References: <np7lf6bwp4.fsf@zwingli.cygnus.com>
X-SW-Source: 2000-q1/msg00688.html
Content-length: 1587
> > There are at least two more subcases for this case (which should perhaps
> > be mentioned in a FIXME), where _something_ needs to happen:
> >
> > - The DSO might have changed in the meantime, in which case we will
> > have to reread it. Comparing timestamps between GDB's view
> > of the DSO and the current DSO will detect this case.
> > - The shared object is now loaded to another address, requiring
> > relocation of the DSO in GDB's symbol tables etc.
> > This might happen if another DSO increased in size since the
> > last run, causing a relocation for the current DSO.
> > Handling this requires comparison between the current objfile
> > offsets and the computed offsets for the DSO in the inferior.
>
> The shared object list should be emptied each time the inferior is
> started, exactly because the address at which a given shared object is
> loaded may vary from run to run. Within a particular process, shared
> objects never change address. We re-read each shared object's symbols
> every time it is loaded. So I think these are handled trivially.
Sorry for the confusion, I noticed this change in semantics a little a
while after I sent the message.
In older versions of GDB this was deemed unacceptable, as it was slowing down
GDB to a crawl on every rerun if you had many shared libraries.
With faster machines and auto-solib-add 0 we might get away with this
approach (although using the old way and a smarter solib algorithm
might have been beneficial for mozilla debugging :-).
--
Peter Schauer pes@regent.e-technik.tu-muenchen.de
From dan@debian.org Sat Apr 01 00:00:00 2000
From: Daniel Jacobowitz <dan@debian.org>
To: 54734@bugs.debian.org
Cc: gcc-bugs@gcc.gnu.org, gdb@sourceware.cygnus.com
Subject: problems with line numbering
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <20000111004219.A8110@drow.res.cmu.edu>
X-SW-Source: 2000-q1/msg00016.html
Content-length: 4994
[Background included for the lists]
Platform is ia32, Debian GNU/Linux; gcc is version 2.95.2; gdb is
the snapshots from 19990928 and 20000110.
When trying to debug apache, I ran into the obnoxious problem that
breakpoints in functions were being put too far into the function.
For example:
(gdb) p invoke_cmd
$1 = {char *(command_rec *, cmd_parms *, void *, char *)} 0x8054330 <invoke_cmd>
(gdb) break invoke_cmd
Breakpoint 1 at 0x8054347: file http_config.c, line 810.
A look at the beginning of invoke_cmd shows me:
(gdb) x/20i invoke_cmd
0x8054330 <invoke_cmd>: push %ebp
0x8054331 <invoke_cmd+1>: mov %esp,%ebp
0x8054333 <invoke_cmd+3>: sub $0xc,%esp
0x8054336 <invoke_cmd+6>: push %edi
0x8054337 <invoke_cmd+7>: push %esi
0x8054338 <invoke_cmd+8>: push %ebx
0x8054339 <invoke_cmd+9>: mov 0xc(%ebp),%edx
0x805433c <invoke_cmd+12>: mov 0x4(%edx),%eax
0x805433f <invoke_cmd+15>: mov 0x8(%ebp),%edx
0x8054342 <invoke_cmd+18>: and 0xc(%edx),%eax
0x8054345 <invoke_cmd+21>: jne 0x8054360 <invoke_cmd+48>
0x8054347 <invoke_cmd+23>: push $0x0
Which corresponds to:
static const char *invoke_cmd(const command_rec *cmd, cmd_parms *parms,
void *mconfig, const char *args)
{
char *w, *w2, *w3;
const char *errmsg;
if ((parms->override & cmd->req_override) == 0)
return ap_pstrcat(parms->pool, cmd->name, " not allowed here", NULL);
In other words - that breakpoint is on the inside of the if statement. Thus
it is not hit in any of the cases I was trying to debug.
[End background]
----
OK, I see where the problem is.
Again, the source chunk with a problem, line numbers added:
803 static const char *invoke_cmd(const command_rec *cmd, cmd_parms *parms,
804 void *mconfig, const char *args)
805 {
806 char *w, *w2, *w3;
807 const char *errmsg;
808
809 if ((parms->override & cmd->req_override) == 0)
810 return ap_pstrcat(parms->pool, cmd->name, " not allowed here", NULL);
811
812 parms->info = cmd->cmd_data;
And the matching assembly:
00000ad0 <invoke_cmd>:
ad0: 55 push %ebp
ad1: 89 e5 mov %esp,%ebp
ad3: 83 ec 0c sub $0xc,%esp
ad6: 57 push %edi
ad7: 56 push %esi
ad8: 53 push %ebx
ad9: 8b 55 0c mov 0xc(%ebp),%edx
adc: 8b 42 04 mov 0x4(%edx),%eax
adf: 8b 55 08 mov 0x8(%ebp),%edx
ae2: 23 42 0c and 0xc(%edx),%eax
ae5: 75 19 jne b00 <invoke_cmd+0x30>
ae7: 6a 00 push $0x0
ae9: 68 63 02 00 00 push $0x263
aee: ff 32 pushl (%edx)
af0: 8b 45 0c mov 0xc(%ebp),%eax
af3: ff 70 10 pushl 0x10(%eax)
af6: e9 28 06 00 00 jmp 1123 <invoke_cmd+0x653>
objdump -g shows something interesting:
{ /* 0xad0 */
register char *errmsg /* 0x0 */;
register char *w3 /* 0x2 */;
register char *w2 /* 0x6 */;
register char *w /* 0x7 */;
/* file /usr/src/debug/apache/apache-1.3.9/build-tree/apache_1.3.9/src/main/http_config.c line 805 addr 0xad0 */
/* file /usr/src/debug/apache/apache-1.3.9/build-tree/apache_1.3.9/src/main/http_config.c line 806 addr 0xad0 */
/* file /usr/src/debug/apache/apache-1.3.9/build-tree/apache_1.3.9/src/main/http_config.c line 809 addr 0xad0 */
/* file /usr/src/debug/apache/apache-1.3.9/build-tree/apache_1.3.9/src/main/http_config.c line 810 addr 0xae7 */
/* file /usr/src/debug/apache/apache-1.3.9/build-tree/apache_1.3.9/src/main/http_config.c line 812 addr 0xb00 */
Note that line 809, the if, is incorrectly listed as starting at 0xad0;
it really starts at ad9. i386_skip_prologue() in gdb correctly figures
this out, and then calls find_pc_sect_line on it, which says that the
line goes from +ad0 to +ae7; because PROLOGUE_FIRSTLINE_OVERLAP is not
defined, find_function_start_sal() skips ahead to the next line and
breakpoints inside the if.
I'd say this was both a gdb bug and a gcc bug. The debugging info for
line 809 is definitely wrong, but gdb should be able to cope, IMO.
I can see why PROLOGUE_FIRSTLINE_OVERLAP causes problems, but it
definitely fixes this one.
I'll send the .ii to gcc-bugs in a separate message, it's not relevant
to the gdb list.
Dan
/--------------------------------\ /--------------------------------\
| Daniel Jacobowitz |__| SCS Class of 2002 |
| Debian GNU/Linux Developer __ Carnegie Mellon University |
| dan@debian.org | | dmj+@andrew.cmu.edu |
\--------------------------------/ \--------------------------------/
From agold@bga.com Sat Apr 01 00:00:00 2000
From: "Arthur H. Gold" <agold@bga.com>
To: gdb@sourceware.cygnus.com
Subject: gdb does not `break' when using LD_PRELOAD
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <388F30C2.B6795E21@bga.com>
X-SW-Source: 2000-q1/msg00059.html
Content-length: 721
gdb list:
Since upgrading to glibc-2.1.2, I've been having a problem with gdb--
specifically in regard to its use with LD_PRELOAD. The problem is that
when running with a preloaded library (either from the shell or set
within gdb) gdb fails to respect any breakpoints I set (though the
breakpoints themselves seem to be set successfully).
I understand there are problems with 4.18; I have, however, started
to run 4.17-14 (HJ Lu's patched version)--but to no avail.
Any input would be more than welcome
TIA,
--ag
--
Artie Gold, Austin, TX (finger the cs.utexas.edu account for more info)
mailto:agold@bga.com or mailto:agold@cs.utexas.edu
--
A: Look for a lawyer who speaks Aramaic...about trademark infringement.
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Michael Snyder <msnyder@cygnus.com>
Cc: dan@cgsoftware.com, Mark Kettenis <kettenis@wins.uva.nl>, gdb@sourceware.cygnus.com
Subject: Re: lin-thread cannot handle thread exit
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38CDEDC5.4107034@cygnus.com>
References: <200003031635.e23GZwi00372@delius.kettenis.local> <38C59074.2D7C@cygnus.com> <u2ihhvav.fsf@dan.resnet.rochester.edu> <38C7EDFB.7457@cygnus.com>
X-SW-Source: 2000-q1/msg00694.html
Content-length: 1037
Michael Snyder wrote:
>
> > All i ever debug on BeOS is multi-threaded apps.
> > Almost anything you do involves threads.
> > Open a window, you've started at least 2 threads.
> > File selection boxes fill in a seperate thread, etc.
> > So i constantly have threads coming and going, and doing things.
> > The hardest part of the whole port of gdb is telling gdb what
> > happened, and making gdb do the right thing.
> > On BeOS, we don't even have processes, just teams and threads.
> > Everything on BeOS works, except typing run and have it start (you
> > have to run and continue) :P.
> > I looked at thread_db over the weekend, in hopes of being able to redo
> > the port and get it into GDB (it's badly needing a rewrite anyway),
> > but it still looks like it has too many problems.
>
> What problems are you referring to?
> Right now the only one I'm aware of is that it doesn't
> detect thread exit.
Michael,
Did you get any further with this? Did the problem exist in the old
thread implementation for instance?
Andrew
From eliz@delorie.com Sat Apr 01 00:00:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: hjl@lucon.org
Cc: gdb@sourceware.cygnus.com
Subject: Re: Problems with hardware watchpoint on ia32.
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200003091209.HAA19852@indy.delorie.com>
References: <20000307132401.A20282@valinux.com> <200003081008.FAA16481@indy.delorie.com> <20000308084304.A3150@lucon.org>
X-SW-Source: 2000-q1/msg00634.html
Content-length: 2571
> I said it crushed because I spent 5 hours in gdb and were very close
> to the problem, all of a sudden, I couldn't continue to debug in gdb
> no matter what I did. To me, it has the same effect as crush.
Understood. My problem was that I couldn't reproduce this particular
problem: namely, if I use your test program, define 5 watchpoints,
just like you did, run the debuggee, and after GDB complains, remove
one of the watchpoints, I can then run the program without any
problems. So I'm led to believe that this particular problem is
specific to the Linux implementation of watchpoints. Perhaps the
removal of the watchpoints doesn't work well in the case where
insertion of watchpoints fails. I remember I had quite a few problems
with getting it right in go32-nat.c.
> > > Even worse, after deleted one hardware watchpoint, gdb still refused
> > > to work.
> >
> > It works for me, but I have patches to do that, which I'm trying for 6
> > months to get accepted :-(.
>
> Should we at least review it?
I posted them more than once in the past. Since a lot of water went
under GDB's bridge since then, I now retrofitted the ones which are
still relevant into the current snapshot, and I'm posting them in this
thread in separate messages.
> > Those patches also correct numerous other problems with watchpoints on
> > x86, which you didn't mention. For example, try setting several
> > watchpoints (of different types) on the same variable, and see the
> > mess. Another problem which I corrected is that you cannot watch
> > struct members, array elements, and bit fields with hardware-assisted
> > watchpoints.
>
> I believe it is fixed in the currnt gdb.
Problems with struct members and array elements are fixed, but bit
fields are not. See my message about this, with a suggested patch.
The problems with awatch and rwatch also aren't fixed; see my other
message.
> > > gdb won't set hardware watchpoints on long long nor double.
> >
> > You could look at go32-nat.c, it supports watching any region up to 16
> > bytes large. (I'm at a loss how come DJGPP needed to invent this: I'd
> > expect any x86 platform to have this already, since watchpoints are
> > such an indispensable tool in some circumstances.)
> >
>
> Maybe we should have an i386hw-nat.c used by all ia32 platforms.
I agree. If the implementation in go32-nat.c is close enough to what
all platforms should do, I can volunteer to create i386hw-nat.c. (My
primary lack of knowledge in this context is about ptrace-related
limitations on using hardware debug registers.)
From kingdon@redhat.com Sat Apr 01 00:00:00 2000
From: Jim Kingdon <kingdon@redhat.com>
To: toddpw@windriver.com
Cc: hjl@lucon.org, kettenis@wins.uva.nl, gdb-patches@sourceware.cygnus.com, gdb@sourceware.cygnus.com
Subject: Re: A revised patch for dlclose
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200003081441.JAA02876@devserv.devel.redhat.com>
References: <200003080849.AAA18417@alabama.wrs.com>
X-SW-Source: 2000-q1/msg00603.html
Content-length: 460
> If each DSO was given its own obstack, it would be pretty easy.
This is largely a solved problem (via objfiles).
See my dlclose() patch:
http://sourceware.cygnus.com/ml/gdb-patches/2000-q1/msg00454.html
especially the call to free_objfile.
Or for another example look at clear_solib which works one struct
so_list at a time.
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.
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: jtc@redback.com
Cc: GDB <gdb@sourceware.cygnus.com>
Subject: Re: breakpoint insert API (was: A patch for ia32 hardware watchpoint.)
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38C834AD.3379D1F2@cygnus.com>
References: <200003080845.AAA18410@alabama.wrs.com> <5mitywc5ac.fsf@jtc.redbacknetworks.com>
X-SW-Source: 2000-q1/msg00663.html
Content-length: 1524
"J.T. Conklin" wrote:
>
> >>>>> "Todd" == Todd Whitesel <toddpw@windriver.com> writes:
> jtc> I was planning to propose that the breakpoint pointer itself be passed
> jtc> to the target_{insert,remove}_{break,watch}point() functions, so this
> jtc> is as good of time as any.
>
> Todd> I say Just Do It. I am sitting on some local code here that tracks
> Todd> breakpoints added to the target by a third party, and I ended up needing
> Todd> the breakpoint shadow field to be available to those functions.
>
> I spent some time yesterday investigating what would be necessary to
> change the target_{insert,remove}_breakpoint() API to pass a pointer
> to struct breakpoint.
>
> What I have so far is change the API from:
> int foo_insert_breakpoint (CORE_ADDR addr, char *shadow_contents);
> to:
> int foo_insert_breakpoint (struct breakpoint *bp, CORE_ADDR addr);
J.T.,
One aspect of this gives me cold feet and sweety palms. You're giving
the target code access to the entire bp struct. While I don't have any
problems with handing the code a breakpoint handle, I have strong
reservations towards any moves that give the target unfettered access to
the entire ``struct breakpoint''. We'll be spending the next 10 years
trying to get control back again :-)
I'd prefer to see something that tightens rather than loosens access to
``struct breakpoint''. Perhaphs something along the lines of multi-arch
where the target is notified of breakpoint create, insert, remove,
delete operations.
Andrew
From tgl@sss.pgh.pa.us Sat Apr 01 00:00:00 2000
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Daniel Berlin <dan@cgsoftware.com>
Cc: gdb-testers@sourceware.cygnus.com, gdb@sourceware.cygnus.com
Subject: Re: Preparing for the GDB 5.0 / GDB 2000 / GDB2k release
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <27617.949979286@sss.pgh.pa.us>
References: <Pine.LNX.4.10.10002071633590.9778-100000@propylaea.anduin.com>
X-SW-Source: 2000-q1/msg00152.html
Content-length: 610
Daniel Berlin <dan@cgsoftware.com> writes:
>> Debugging shared libraries works most of time with gdb 4.17.0.14.
>> If it doesn't work with 5.0, does that count for serious losses of
>> functionality?
> You mean for your particular architecture.
I don't know what architecture H.J. is using, but I can tell you that
shared lib debugging is completely nonfunctional on HPPA (HPUX 10.20).
Can't even get a backtrace when execution is stopped in a shlib...
kind of puts a crimp in the usefulness of gdb, at least for me.
(If this has been fixed since the 20000117 snapshot then nevermind)
regards, tom lane
From swarthou@ibmoto.com Sat Apr 01 00:00:00 2000
From: Edward Swarthout <swarthou@ibmoto.com>
To: gdb@sourceware.cygnus.com
Subject: State of native LinuxPPC patches
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200001182057.OAA26264@kuttanna.somerset.sps.mot.com>
References: <http://sourceware.cygnus.com/ml/gdb/1999-q4/msg00102.html>
X-SW-Source: 2000-q1/msg00043.html
Content-length: 1237
> Date: Thu, 21 Oct 1999 11:18:55 -0700
> From: Kevin Buettner <kevinb@cygnus.com>
>
> I got my patches working with the head of the development tree several
> weeks ago. (Actually, Gary Thomas deserves a lot of the credit.)
> However there are a great many similarities between rs6000-tdep.c and
> the ppclinux-tdep.c. I would really like to make the common parts
> truly common as well as revamp it so that it uses the gdbarch
> machinery, but this'll take more time than I have at the moment. So
> it might be better for me to commit what I have so that linux/ppc is
> supported in the Cygnus tree. Also, the longer I let my stuff sit,
> the more likely it is that certain global changes will break what I
> have working already. (Because these global changes won't have
> happened to the linux/ppc stuff.)
>
Are these patches available in a sandbox somewhere?
(Since there isn't native support yet, are they harmless enough to be
released in cvs before being tested?)
I have a LinuxPPC debug project I need to work on and I wanted to
switch to the latest gdb snapshot before I did much gdb work.
Thanks,
Ed
--------------------------------------
Ed.Swarthout@motorola.com
Motorola Somerset Design Center
Austin, TX
^ permalink raw reply [flat|nested] only message in thread