* Re: regression analysis: gdb.sum postprocessing script
[not found] <Pine.LNX.4.10.10003241103440.15236-100000@hpcll168.cup.hp.com>
@ 2000-04-01 0:00 ` Fernando Nasser
2000-04-01 0:00 ` Jimmy Guo
0 siblings, 1 reply; 2+ messages in thread
From: Fernando Nasser @ 2000-04-01 0:00 UTC (permalink / raw)
To: Jimmy Guo; +Cc: gdb-patches
Jimmy Guo wrote:
>
> Here is a Perl script I wrote to postprocess one or more gdb.sum files
> and provide a complete dejagnu test outcome summary (or diff if more
> than one gdb.sum files are given). It's most useful if you want to have
> a complete view of regression status between two source trees and/or if
> you set up your testing to run multiple passes (to see how a test point
> behaves in different passes), however you can use it just on one test
> run's gdb.sum file and play around with the options to get test outcome
> presented in a much organized and useful way than going through the flat
> gdb.sum file.
>
> I don't know if this is useful to keep around in the repository ...
>
Sure it is.
Just a question: is this being assigned and can be distributed under the GPL?
If Stan agrees, I would like to incorporate it (IP issues sorted, of course).
--
Fernando Nasser
Red Hat - Toronto E-Mail: fnasser@cygnus.com
2323 Yonge Street, Suite #300 Tel: 416-482-2661 ext. 311
Toronto, Ontario M4P 2C9 Fax: 416-482-6299
From kingdon@redhat.com Sat Apr 01 00:00:00 2000
From: Jim Kingdon <kingdon@redhat.com>
To: gdb-patches@sourceware.cygnus.com
Subject: Re: dlclose()
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <b66vh2acz.fsf@rtl.cygnus.com>
References: <200002161953.OAA07411@devserv.devel.redhat.com> <200002200521.AAA29598@devserv.devel.redhat.com> <88nurn$e4d$1@cronkite.cygnus.com> <b7lfzhkj6.fsf@rtl.cygnus.com> <88qer9$lbd$1@cronkite.cygnus.com>
X-SW-Source: 2000-q1/msg00297.html
Content-length: 1055
> We've already seen at least one recent case where a test suite run prior
> to an overly optimistic check-in would probably have saved people from
> breakage.
<blushing> Hard to argue when you put it that way :-).
Here are test results for x86 linux (Red Hat Linux 6.1) and SunOS4,
respectively. In both cases they were the same with and without the
http://sourceware.cygnus.com/ml/gdb-patches/2000-q1/msg00251.html
patch.
I think the larger issue regarding the testsuite still needs
attention/rethinking, but obviously I'm not in a very strong
negotiating position just now :-). So I won't elaborate just now (I'm
in enough trouble as it is).
Linux:
# of expected passes 6357
# of unexpected failures 12
# of expected failures 200
SunOS4:
# of expected passes 6409
# of unexpected failures 28
# of unexpected successes 1
# of expected failures 171
# of unresolved testcases 5
# of unsupported tests 1
/home/kingdon/src/gdb/testsuite/../../gdb/gdb version 20000204 -nx
From jtc@redback.com Sat Apr 01 00:00:00 2000
From: jtc@redback.com (J.T. Conklin)
To: gdb-patches@sourceware.cygnus.com
Subject: PATCH: handle NAK packets sent by remote stub.
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <5mya8zqhbg.fsf@jtc.redbacknetworks.com>
X-SW-Source: 2000-q1/msg00080.html
Content-length: 1999
This patch wasn't lost, but rather deferred for further thought just
before the 4.18 branch/release.
The putpkt_binary() function doesn't specifically handle the NAK ('-')
character after a packet has been transmitted. It's treated as a junk
character and ignored. As a result, in the case of packet corruption,
GDB waits remote_timeout seconds to re-try the packet even though the
target has told GDB that the packet needs to be retransmitted. The
enclosed patch handles Nak, so the packet is retransmitted immediately.
The one concern that I remember was the risk of spurious NAKs from the
target interfering with the proper operation remote protocol. This is
a possibility, but in my opinion it's no more so than spurious ACKs.
Without ACKs and NAKs being framed/checksummed, the remote protocol is
simply vulnerable to communication errors.
We've had this change in our local GDBs for about a year. It has
caused no problems that I'm aware of.
I submitted this patch before I started archiving my outbound mail.
So this time, the ChangeLog is new.
--jtc
2000-02-05 J.T. Conklin <jtc@redback.com>
* remote.c (putpkt_binary): Handle NAK from target stub.
Index: remote.c
===================================================================
RCS file: /home/jtc/CVSROOT/gdb/gdb/remote.c,v
retrieving revision 1.1.1.28
retrieving revision 1.19
diff -c -r1.1.1.28 -r1.19
*** remote.c 2000/02/04 21:24:02 1.1.1.28
--- remote.c 2000/02/04 23:52:40 1.19
***************
*** 3730,3735 ****
--- 3721,3727 ----
switch (ch)
{
case '+':
+ case '-':
case SERIAL_TIMEOUT:
case '$':
if (started_error_output)
***************
*** 3746,3751 ****
--- 3738,3746 ----
if (remote_debug)
fprintf_unfiltered (gdb_stdlog, "Ack\n");
return 1;
+ case '-':
+ if (remote_debug)
+ fprintf_unfiltered (gdb_stdlog, "Nak\n");
case SERIAL_TIMEOUT:
tcount++;
if (tcount > 3)
--
J.T. Conklin
RedBack Networks
From jtc@redback.com Sat Apr 01 00:00:00 2000
From: jtc@redback.com (J.T. Conklin)
To: gdb-patches@sourceware.cygnus.com
Subject: PATCH: remote stub store single register command error return value
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <5m7lgjrxfy.fsf@jtc.redbacknetworks.com>
X-SW-Source: 2000-q1/msg00078.html
Content-length: 4207
Another pending patch:
"As pointed out on the gdb list earlier today, some of the sample stubs
return "P01" when the 'store single register' command (P) fails. This
does not conform to the remote protocol spec, which states that values
of the form "ENN" are to be used for reporting errors.
GDB does not currently check return value of register store commands,
If this is fixed, it should check for "OK" instead of "ENN".
As before, ChangeLog is from original submission, the patch itself has
been regenerated relative to the 20000204 snapshot.
--jtc
1999-10-18 J.T. Conklin <jtc@redback.com>
* m32r-stub.c, sparcl-stub.c, sparclet-stub.c (handle_exception):
Return E01 instead of P01 when 'P' command fails.
Index: m32r-stub.c
===================================================================
RCS file: /home/jtc/CVSROOT/gdb/gdb/m32r-stub.c,v
retrieving revision 1.1.1.5
retrieving revision 1.7
diff -c -r1.1.1.5 -r1.7
*** m32r-stub.c 1999/10/01 08:13:13 1.1.1.5
--- m32r-stub.c 2000/02/03 19:44:48 1.7
***************
*** 425,431 ****
strcpy (remcomOutBuffer, "OK");
break;
}
! strcpy (remcomOutBuffer, "P01");
break;
}
case 'G': /* set the value of the CPU registers - return OK */
--- 425,431 ----
strcpy (remcomOutBuffer, "OK");
break;
}
! strcpy (remcomOutBuffer, "E01");
break;
}
case 'G': /* set the value of the CPU registers - return OK */
Index: sparcl-stub.c
===================================================================
RCS file: /home/jtc/CVSROOT/gdb/gdb/sparcl-stub.c,v
retrieving revision 1.1.1.4
retrieving revision 1.9
diff -c -r1.1.1.4 -r1.9
*** sparcl-stub.c 1999/09/09 19:12:15 1.1.1.4
--- sparcl-stub.c 2000/02/06 00:16:36 1.9
***************
*** 50,55 ****
--- 50,56 ----
*
* g return the value of the CPU registers hex data or ENN
* G set the value of the CPU registers OK or ENN
+ * P set the value of a single CPU register OK or ENN
*
* mAA..AA,LLLL Read LLLL bytes at address AA..AA hex data or ENN
* MAA..AA,LLLL: Write LLLL bytes at address AA.AA OK or ENN
***************
*** 831,837 ****
hex2mem (ptr, (char *)®isters[regno], 4, 0);
else
{
! strcpy (remcomOutBuffer, "P01");
break;
}
}
--- 832,838 ----
hex2mem (ptr, (char *)®isters[regno], 4, 0);
else
{
! strcpy (remcomOutBuffer, "E01");
break;
}
}
Index: sparclet-stub.c
===================================================================
RCS file: /home/jtc/CVSROOT/gdb/gdb/sparclet-stub.c,v
retrieving revision 1.1.1.4
diff -c -r1.1.1.4 sparclet-stub.c
*** sparclet-stub.c 1999/09/09 19:12:16 1.1.1.4
--- sparclet-stub.c 2000/02/06 00:15:10
***************
*** 50,56 ****
*
* g return the value of the CPU registers hex data or ENN
* G set the value of the CPU registers OK or ENN
! * P set the value of a single CPU register OK or P01 (???)
*
* mAA..AA,LLLL Read LLLL bytes at address AA..AA hex data or ENN
* MAA..AA,LLLL: Write LLLL bytes at address AA.AA OK or ENN
--- 50,56 ----
*
* g return the value of the CPU registers hex data or ENN
* G set the value of the CPU registers OK or ENN
! * P set the value of a single CPU register OK or ENN
*
* mAA..AA,LLLL Read LLLL bytes at address AA..AA hex data or ENN
* MAA..AA,LLLL: Write LLLL bytes at address AA.AA OK or ENN
***************
*** 938,944 ****
hex2mem (ptr, (char *)®isters[regno], 4, 0);
else
{
! strcpy (remcomOutBuffer, "P01");
break;
}
}
--- 938,944 ----
hex2mem (ptr, (char *)®isters[regno], 4, 0);
else
{
! strcpy (remcomOutBuffer, "E01");
break;
}
}
--
J.T. Conklin
RedBack Networks
From ezannoni@cygnus.com Sat Apr 01 00:00:00 2000
From: Elena Zannoni <ezannoni@cygnus.com>
To: gdb-patches@sourceware.cygnus.com
Subject: MI updates
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <14532.14584.823970.23945@kwikemart.cygnus.com>
X-SW-Source: 2000-q1/msg00549.html
Content-length: 1382
Hi,
I just cleaned the testsuite for MI, updated the gdbmi.texinfo file to
reflect the latest changes to the MI disasssembly command, and checked in
an implementation of the -data-write-registers-values command.
Elena
gdb/mi/ChangeLog-mi:
2000-03-06 Elena Zannoni <ezannoni@kwikemart.cygnus.com>
* mi-cmds.h: Export mi_cmd_data_write_register_values.
* mi-cmds.c (mi_cmds): Implement data-write-register-values with
mi_cmd_data_write_register_values.
* mi-main.c (mi_cmd_data_write_register_values): New
function. Write a value into a register.
2000-03-06 Elena Zannoni <ezannoni@kwikemart.cygnus.com>
* mi-cmds.h:
* gdbmi.texinfo: Update data-disassemble documentation.
gdb/testsuite/gdb.mi/ChangeLog-mi:
2000-03-06 Elena Zannoni <ezannoni@kwikemart.cygnus.com>
* mi-disassemble.exp: Don't assume numbers for the offset
values. They can be different depending on the architecture.
* mi-watch.exp (test_watchpoint_triggering): In same cases the
type can be 'hw wathcpoint' not just 'watchpoint'. Adjust for that.
* basics.c (callee4): Make the function return something,
otherwise the return value is undefined.
2000-03-06 Elena Zannoni <ezannoni@kwikemart.cygnus.com>
* mi-basics.exp: Comment out test for a still unimplemented operation.
* mi-disassemble.exp: Rewrite most of the tests to conform to new
disassemble interface.
From toddpw@windriver.com Sat Apr 01 00:00:00 2000
From: Todd Whitesel <toddpw@windriver.com>
To: ac131313@cygnus.com (Andrew Cagney)
Cc: phdm@macqel.be (Philippe De Muyter), gdb-patches@sourceware.cygnus.com (gdb-patches@sourceware.cygnus.com)
Subject: Re: PATCH/RFA: regerror link error
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200003280329.TAA16525@alabama.wrs.com>
References: <38DFFFF1.A2BD1D4E@cygnus.com>
X-SW-Source: 2000-q1/msg01075.html
Content-length: 344
> > * gnu-regex.c (regerror): Function renamed from `__regerror'.
>
> The change is fine. It's already in the official glibc.
The -exact- change??
Is 'regerror' part of the defined API? I sure hope so. (If it's not, then
removing the underscores means a new potential namespace conflict.)
--
Todd Whitesel
toddpw @ windriver.com
From msnyder@cygnus.com Sat Apr 01 00:00:00 2000
From: Michael Snyder <msnyder@cygnus.com>
To: Dmitry Sivachenko <dima@Chg.RU>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: typo in gdb.texinfo
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38CFE64A.2BBB@cygnus.com>
References: <200003151932.WAA39200@netserv1.chg.ru>
X-SW-Source: 2000-q1/msg00722.html
Content-length: 954
Dmitry Sivachenko wrote:
>
> There is no value for GDBINIT!
> Consider this fix:
>
> --dima
>
> --- gdb.texinfo.orig Wed Mar 15 22:31:16 2000
> +++ gdb.texinfo Wed Mar 15 22:31:32 2000
> @@ -10611,7 +10611,7 @@
> @cindex floating point, MIPS remote
> If your target board does not support the MIPS floating point
> coprocessor, you should use the command @samp{set mipsfpu none} (if you
> -need this, you may wish to put the command in your @value{GDBINIT}
> +need this, you may wish to put the command in your @file{.gdbinit}
> file). This tells @value{GDBN} how to find the return value of
> functions which return floating point values. It also allows
> @value{GDBN} to avoid saving the floating point registers when calling
I think the purpose of having GDBINIT be a variable is
because it has a different filename on windows/CYGWIN.
Isn't it called "gdb.ini" or something?
If the variable truly isn't defined, it probably should be.
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: GDB Patches <gdb-patches@sourceware.cygnus.com>
Subject: [patch] doc/Makefile.in - create destdir
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38DB12B5.C2DE8F11@cygnus.com>
X-SW-Source: 2000-q1/msg00979.html
Content-length: 764
FYI,
I've applied the below. Per Eli's note, the Makefile was assuming that
the directory was already there.
Andrew
Fri Mar 24 17:56:48 2000 Andrew Cagney <cagney@b1.cygnus.com>
* Makefile.in (install-info): Create $(infodir) before installing
files.
Index: Makefile.in
===================================================================
RCS file: /cvs/src/src/gdb/doc/Makefile.in,v
retrieving revision 1.2
diff -p -r1.2 Makefile.in
*** Makefile.in 2000/02/16 04:44:55 1.2
--- Makefile.in 2000/03/24 06:57:58
*************** all-doc: info dvi ps
*** 103,108 ****
--- 103,109 ----
diststuff: info
install-info: info
+ $(SHELL) $(srcdir)/../../mkinstalldirs $(infodir)
for i in *.info* ; do \
$(INSTALL_DATA) $$i $(infodir)/$$i ; \
done
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: gdb-patches@sourceware.cygnus.com
Subject: RFD: printcmd.c: Changing output width of p/a and x/a
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200003072113.WAA26267@reisser.regent.e-technik.tu-muenchen.de>
X-SW-Source: 2000-q1/msg00555.html
Content-length: 2174
Due to a recent BFD change, a CORE_ADDR is now an unsigned long long with
64 Bits on Solaris 2.7 sparc and causes a testsuite regression in
long_long.exp:
(gdb) x/a &oct
0xffbef848: 0xffffffffa72ee539
(gdb) FAIL: gdb.base/long_long.exp: x/a &oct
printcmd.c:print_scalar_formatted calls print_address with the result
from unpack_pointer. As the `examine type' passed to unpack_pointer is signed,
we get sign extension to 64 bits when printing the address value.
The solution is simple, just truncate the core address like we truncate values
around line 404 in printcmd.c
But how much truncation should be done to meet user expectations ?
I have a feeling that we should truncate to TARGET_PTR_BIT (which would
get rid of the testsuite regression without causing new ones).
On the other hand this would be inconsistent with the truncation of values,
which is done with the type length of the value.
Would you expect
(gdb) p/a (char)-1
to yield
$1 = 0xff (truncation to length of value, will cause testsuite
regressions, which have to be adressed by changing
the expect patterns)
or
$1 = 0xffffffff (truncation to size of pointer)
Here is a patch to truncate to the size of a pointer, please let me know
if you want this to be changed to truncate to the length of the value.
2000-03-07 Peter Schauer <pes@regent.e-technik.tu-muenchen.de>
* printcmd.c (print_scalar_formatted): Truncate addresses to the
size of a target pointer before passing them to print_address.
*** ./printcmd.c.orig Sun Mar 5 17:35:36 2000
--- ./printcmd.c Tue Mar 7 19:59:46 2000
***************
*** 443,449 ****
break;
case 'a':
! print_address (unpack_pointer (type, valaddr), stream);
break;
case 'c':
--- 443,455 ----
break;
case 'a':
! {
! /* Truncate address to the size of a target pointer. */
! CORE_ADDR addr = unpack_pointer (type, valaddr);
! if (TARGET_PTR_BIT < (sizeof (CORE_ADDR) * HOST_CHAR_BIT))
! addr &= ((CORE_ADDR) 1 << TARGET_PTR_BIT) - 1;
! print_address (addr, stream);
! }
break;
case 'c':
--
Peter Schauer pes@regent.e-technik.tu-muenchen.de
From jimb@zwingli.cygnus.com Sat Apr 01 00:00:00 2000
From: Jim Blandy <jimb@zwingli.cygnus.com>
To: Jim Kingdon <kingdon@redhat.com>
Cc: toddpw@windriver.com, 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: <npya7tay5p.fsf@zwingli.cygnus.com>
References: <200003080849.AAA18417@alabama.wrs.com> <200003081441.JAA02876@devserv.devel.redhat.com>
X-SW-Source: 2000-q1/msg00602.html
Content-length: 448
> > If each DSO was given its own obstack, it would be pretty easy.
>
> This is largely a solved problem (via objfiles).
> [...]
> 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.
Yes, that's right.
I've pretty much come to the same conclusion as JimK --- I think there
are ways to repartition find_solib's responsibilities that will make
this logic a lot simpler.
From jimb@zwingli.cygnus.com Sat Apr 01 00:00:00 2000
From: Jim Blandy <jimb@zwingli.cygnus.com>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: Stephane Carrez <Stephane.Carrez@worldnet.fr>, gdb-patches@sourceware.cygnus.com, Jim Blandy <jimb@cygnus.com>
Subject: Re: path for gdb/dwarf2read.c, support 16-bit targets in dwarf-2
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <npln332hbu.fsf@zwingli.cygnus.com>
References: <38B2F3D3.54CF0AF0@worldnet.fr> <38BB5463.D6E5B75C@cygnus.com> <38C0D9D9.70987863@worldnet.fr> <38C225F3.9E236A55@cygnus.com>
X-SW-Source: 2000-q1/msg01083.html
Content-length: 1629
> > elf16 is not a good idea. I think we must not mix the size of cpu
> > address with the format of ELF files. The ELF file can be larger than
> > 64K and we might need indexes larger than 16-bit.
>
> When I say ``elf16'', I was thinking of an elf object file that has 16
> bit addresses. I'm not sure what other consequences such a move would
> have.
>
> Is there any reason why s->arch_size isn't 16 in your case?
s->arch_size is not an especially meaningful field. It exists only to
indicate whether you've got an ELF32 or ELF64 format file.
I think inventing a new ELF16 file format is a bad idea. There are a
zillion things to take into account. It's much simpler to just use
ELF32, and only link things into the lower 64k, which is what
we've done with other 16-bit processors in the past.
If you want to know the actual processor address size, there's a
different BFD field whose job is to provide that information. That's
bfd_arch_bits_per_address, which Stephane suggested we use instead.
In general, the change that has dwarf2read checking the ELF backend
data has just been a pain from day one. I remember fixing related
dependency problems, people on the binutils list saying "This looks
really wrong," and so on. GDB shouldn't be using internal BFD
headers, and consulting internal ELF BFD data structures.
I also buy Jim Kingdon's argument that it shouldn't be necessary to
mask off the upper bits. The data in the ELF file should be correct.
I'm going to revert the change which introduced
address_significant_size in the first place. If this causes problems,
then we'll fix the bug correctly.
From eliz@delorie.com Sat Apr 01 00:00:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: gdb-patches@sourceware.cygnus.com
Subject: Re: [PATCH] go32-nat.o prerequisites in gdb/Makefile.in
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200003161028.FAA01889@indy.delorie.com>
X-SW-Source: 2000-q1/msg00737.html
Content-length: 1174
I committed the following (for references see the message here:
http://sourceware.cygnus.com/ml/gdb-patches/2000-q1/msg00522.html )
2000-03-04 Eli Zaretskii <eliz@is.elta.co.il>
* Makefile.in (go32-nat.o): Add prerequisites.
(ALLDEPFILES): Add go32-nat.c.
--- gdb/Makefile.i~1 Sat Mar 4 18:26:36 2000
+++ gdb/Makefile.in Sat Mar 4 19:09:54 2000
@@ -1067,7 +1067,7 @@
convex-tdep.c convex-xdep.c \
core-sol2.c core-regset.c core-aout.c corelow.c \
dcache.c delta68-nat.c dpx2-nat.c dstread.c exec.c fork-child.c \
- gould-tdep.c gould-xdep.c h8300-tdep.c h8500-tdep.c \
+ go32-nat.c gould-tdep.c gould-xdep.c h8300-tdep.c h8500-tdep.c \
hp300ux-nat.c hppa-tdep.c hppab-nat.c hppah-nat.c \
hp-psymtab-read.c hp-symtab-read.c \
i386-tdep.c i386b-nat.c i386mach-nat.c i386v-nat.c i386-linux-nat.c \
@@ -1356,6 +1356,9 @@
$(gdbtypes_h) language.h objfiles.h symfile.h $(symtab_h) target.h \
$(value_h) gdb_string.h
+go32-nat.o: go32-nat.c $(defs_h) $(inferior_h) gdb_wait.h $(gdbcore_h) \
+ $(command_h) $(floatformat_h) target.h
+
gnu-nat.o: process_reply_S.h exc_request_S.h notify_S.h msg_reply_S.h \
exc_request_U.h msg_U.h gnu-nat.h
From ezannoni@cygnus.com Sat Apr 01 00:00:00 2000
From: Elena Zannoni <ezannoni@cygnus.com>
To: "Philippe De Muyter" <phdm@macqel.be>
Cc: eliz@is.elta.co.il, ezannoni@cygnus.com, ac131313@cygnus.com, gdb-patches@sourceware.cygnus.com
Subject: Re: HAVE_POLL is not enough - RFA
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <14550.34053.54053.454075@kwikemart.cygnus.com>
References: <200003182226.RAA07052@indy.delorie.com> <200003182300.AAA32279@mail.macqel.be>
X-SW-Source: 2000-q1/msg00820.html
Content-length: 1467
Philippe, I didn't commit your suggested change below, yet. Can you
submit that as part of your patch, now that Eli's changes are in?
Thanks
Elena
Philippe De Muyter writes:
> Eli Zaretskii wrote :
> > * event-loop.c (top-level) [NO_FD_SET]: Deprecate this branch.
> > Print an error at compile time if we are to use select, but FD_SET
> > is not available.
> > (SELECT_MASK, NBBY, FD_SETSIZE, NFDBITS, MASK_SIZE): Define only
> > if HAVE_POLL is not defined and NO_FD_SET *is* defined.
> > (create_file_handler) [!HAVE_POLL]: Use FD_SET and FD_CLR.
> > (delete_file_handler) [!HAVE_POLL]: Use FD_CLR and FD_ISSET.
> > (gdb_wait_for_event) [!HAVE_POLL]: Copy fd_set sets directly
> > instead of using memcpy and memset. Use FD_ISSET.
> >
> > +#ifdef NO_FD_SET
> > +/* All this stuff below is not required if select is used as God(tm)
> > + intended, with the FD_* macros. Are there any implementations of
> > + select which don't have FD_SET and other standard FD_* macros? I
> > + don't think there are, but if I'm wrong, we need to catch them. */
> > +#error FD_SET must be defined if select function is to be used!
>
> I agree completely that your change is the right thing, but it misses
> the following sequence :
>
> #if HAVE_SYS_SELECT_H
> #include <sys/select.h>
> #endif
>
> that is needed a.o. on AIX (See e.g. the sources of bash, screen, mc, uucp,
> ncurses, inetutils, cvs or emacs)
>
> Philippe
From eliz@delorie.com Sat Apr 01 00:00:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: gdb-patches@sourceware.cygnus.com
Cc: ezannoni@cygnus.com
Subject: Re: [PATCH] GDB command-line switches and annotations docs
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200003120754.CAA24393@indy.delorie.com>
References: <14537.5048.99180.910863@kwikemart.cygnus.com> <200003101809.NAA22092@indy.delorie.com> <14537.18119.116000.442262@kwikemart.cygnus.com>
X-SW-Source: 2000-q1/msg00654.html
Content-length: 681
> I admit I haven't documented the event loop machinery at all (that
> should actually go in the internal manual). I thoroughly commented the
> code though, if that's any excuse :-).
>
> I wasn't going to document the existance of target 'async' either,
> because that's also supposed to go away, and be absorbed into a new
> and improved target 'remote'. There are still a bunch of loose ends to
> finish before that's going to happen. So I am not sure what the best
> course of action is.
If it would help, I could add a note telling that the event loop is
still not fully asynchronous, with a FIXME comment that the note
should be removed when the target side is done. Okay?
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: gdb-patches@sourceware.cygnus.com
Subject: Severe regression in corefile.exp with Solaris 2.7 sparc + hack
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200003072113.WAA26253@reisser.regent.e-technik.tu-muenchen.de>
X-SW-Source: 2000-q1/msg00554.html
Content-length: 3090
This change:
2000-02-25 Alexandre Oliva <oliva@lsd.ic.unicamp.br>
* config.bfd: Enable 64 bit support for GNU/Linux/sparc.
* config.bfd: Enable 64 bit support for Solaris7+/sparc.
causes a severe regression in corefile.exp on Solaris 2.7 sparc, which
should definitely be fixed before the 5.0 release.
Due to the BFD change, a CORE_ADDR is now an unsigned long long with 64 Bits.
When casting 32 bit pointers to a CORE_ADDR in solib.c, the sign bit of the
pointer gets extended, resulting in a very large adress. This is not a
problem when accessing the inferior via procfs (because the address gets
truncated back to 32 bits in the procfs interface), but it causes failures
when trying to retrieve the shared library info from corefile BFDs.
I have no idea how to solve this cleanly, and offer a crude hack only.
Perhaps `someone' will have a cleaner solution for this problem.
2000-03-07 Peter Schauer <pes@regent.e-technik.tu-muenchen.de>
* solib.c (solib_addr_bits_remove) New function to mask off unwanted
address bits.
(find_solib): Use it.
*** gdb/solib.c.orig Wed Nov 17 03:30:28 1999
--- gdb/solib.c Tue Mar 07 16:38:39 2000
***************
*** 974,979 ****
--- 974,991 ----
in <link.h>.
*/
+ /* FIXME: When GDB is configured for some 32-bit targets (e.g. Solaris 2.7
+ sparc), BFD is configured to handle 64-bit targets, so CORE_ADDR is
+ 64 bits. We may have to mask off sign extension bits from addresses to
+ get the right address when accessing the core file BFD via read_memory. */
+ static CORE_ADDR
+ solib_addr_bits_remove (CORE_ADDR addr)
+ {
+ if (TARGET_PTR_BIT <= 32)
+ addr &= 0xffffffff;
+ return addr;
+ }
+
static struct so_list *
find_solib (so_list_ptr)
struct so_list *so_list_ptr; /* Last lm or NULL for first one */
***************
*** 1045,1051 ****
}
so_list_next = new;
! read_memory ((CORE_ADDR) lm, (char *) &(new->lm),
sizeof (struct link_map));
/* For SVR4 versions, the first entry in the link map is for the
inferior executable, so we must ignore it. For some versions of
--- 1057,1063 ----
}
so_list_next = new;
! read_memory (solib_addr_bits_remove ((CORE_ADDR) lm), (char *) &(new->lm),
sizeof (struct link_map));
/* For SVR4 versions, the first entry in the link map is for the
inferior executable, so we must ignore it. For some versions of
***************
*** 1056,1063 ****
{
int errcode;
char *buffer;
! target_read_string ((CORE_ADDR) LM_NAME (new), &buffer,
! MAX_PATH_SIZE - 1, &errcode);
if (errcode != 0)
{
warning ("find_solib: Can't read pathname for load map: %s\n",
--- 1068,1075 ----
{
int errcode;
char *buffer;
! target_read_string (solib_addr_bits_remove ((CORE_ADDR) LM_NAME (new)),
! &buffer, MAX_PATH_SIZE - 1, &errcode);
if (errcode != 0)
{
warning ("find_solib: Can't read pathname for load map: %s\n",
--
Peter Schauer pes@regent.e-technik.tu-muenchen.de
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: GDB Patches <gdb-patches@sourceware.cygnus.com>
Subject: RFA Replace gdb/TODO with issues50
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38DAED11.C314EA48@cygnus.com>
X-SW-Source: 2000-q1/msg00975.html
Content-length: 325
Hello,
I'd like to propose that the file gdb/TODO be emptied and then refilled
with a heavily edited version of:
http://sourceware.cygnus.com/gdb/issues50.html
To the best of my knowledge large chunks of the existing TODO file are
either wrong or irrelevant. I think starting from scratch would be more
useful.
Andrew
From dan@cgsoftware.com Sat Apr 01 00:00:00 2000
From: Daniel Berlin <dan@cgsoftware.com>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: Fernando Nasser <fnasser@cygnus.com>, David Whedon <davidw@gordian.com>, gdb-patches@sourceware.cygnus.com
Subject: Re: [REPOST #2] patch: command deprecator
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <Pine.LNX.4.10.10003231512300.30962-100000@propylaea.anduin.com>
References: <38DAA407.644AA5C1@cygnus.com>
X-SW-Source: 2000-q1/msg00956.html
Content-length: 342
>
> None, sorry. This isn't a must have for GDB 5 so there isn't the
> desperate rush.
> If I lifted a page from the latest mills&boon and included in my own
> book, would I be infringing on copyright?
Depends on what your book is for.
(I asked a lawyer before i opened my mouth, to make sure i don't stick my
foot in it).
>
> Andrew
>
^ permalink raw reply [flat|nested] 2+ messages in thread