* Re: source listing change
[not found] ` <1z4m35ag.fsf@dan.resnet.rochester.edu>
@ 2000-04-03 20:44 ` Chris Faylor
0 siblings, 0 replies; 3+ messages in thread
From: Chris Faylor @ 2000-04-03 20:44 UTC (permalink / raw)
To: Daniel Berlin+list.gdb-patches; +Cc: Christopher Blizzard, gdb-patches
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 71934 bytes --]
On Mon, Apr 03, 2000 at 11:37:27PM -0400, Daniel Berlin+list.gdb-patches wrote:
>>>>>> "Christopher" == Christopher Blizzard <blizzard@mozilla.org> writes:
> Christopher> If that's the case then it's a big no-no in my
> Christopher> opinion. We could still make it an option, though.
> Christopher> I like it.
>
>It shoudln't affect either, since emacs uses a special annotation
>mode, as do the other programs (set annotate 1, and look what happens)
>Neither ever actually use list.
>If they really are that broken that they depend on the format of list
>always being the same, ...
>What i'm trying to say is make it dependent on the annotation level if
>you really are concerned, not an option to list.
>that way, the users see what is good for the users, and the programs
>see what is good for the programs.
I guess it is obvious in retrospect that anything which is using gdb as
a back-end is not going to rely on 'list'. I guess I don't remember why
this patch wasn't just added as-is sans option.
cgf
From dan@cgsoftware.com Mon Apr 03 21:01:00 2000
From: dan@cgsoftware.com (Daniel Berlin+list.gdb-patches)
To: Chris Faylor <cgf@cygnus.com>
Cc: "Daniel Berlin+list.gdb-patches" <dan@cgsoftware.com>, Christopher Blizzard <blizzard@mozilla.org>, gdb-patches@sourceware.cygnus.com
Subject: Re: source listing change
Date: Mon, 03 Apr 2000 21:01:00 -0000
Message-id: <wvme1pn6.fsf@dan.resnet.rochester.edu>
References: <38E94593.668AAF44@mozilla.org> <20000403215828.A18519@cygnus.com> <38E94D93.C8A5688C@mozilla.org> <20000403220519.A18799@cygnus.com> <38E95A9E.94161B36@mozilla.org> <1z4m35ag.fsf@dan.resnet.rochester.edu> <20000403234440.A12377@cygnus.com>
X-SW-Source: 2000-04/msg00059.html
Content-length: 1008
>>>>> "Chris" == Chris Faylor <cgf@cygnus.com> writes:
Chris> I guess it is obvious in retrospect that anything which is
Chris> using gdb as a back-end is not going to rely on 'list'. I
Chris> guess I don't remember why this patch wasn't just added
Chris> as-is sans option.
In fact, it makes even less sense the more i think about it (no
offense, i'm just thinking out in email. Parsing is a hobby of
mine. Written two full C++ parsers. shiver.).
because the format is still technically the same.
%d ><random source line>\n
vs
%d <random source line>\n
I can't imagine anyone designing a regex parsing the list output
format that this would affect.
([0-9]+)" "([^\n]+) over each line would give you the line number, and
the rest of the line (I think).
It wouldn't be affected by this change.
My point is, their is nothing i can think of that would make something
think this list format is different than a normal source file which
happened to start with > on a single line.
Chris> cgf
From ac131313@cygnus.com Mon Apr 03 21:16:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: GDB Patches <gdb-patches@sourceware.cygnus.com>
Subject: [PATCH] Avoid GCC shift overflow warning
Date: Mon, 03 Apr 2000 21:16:00 -0000
Message-id: <38E96C39.51AE3130@cygnus.com>
X-SW-Source: 2000-04/msg00060.html
Content-length: 1514
FYI,
I've committed the attatched. GCC was still convinced that the shift
would overflow.
Andrew
Tue Apr 4 12:13:19 2000 Andrew Cagney <cagney@b1.cygnus.com>
* printcmd.c (print_scalar_formatted): Use local variable ptr_bit
in shift. Stop GCC thinking it has a shift overflow.
Index: printcmd.c
===================================================================
RCS file: /cvs/src/src/gdb/printcmd.c,v
retrieving revision 1.2
diff -p -r1.2 printcmd.c
*** printcmd.c 2000/03/22 20:55:15 1.2
--- printcmd.c 2000/04/04 04:11:46
*************** print_scalar_formatted (valaddr, type, f
*** 445,454 ****
case 'a':
{
/* Truncate address to the size of a target pointer, avoiding
! shifts larger or equal than the width of a CORE_ADDR. */
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;
--- 445,457 ----
case 'a':
{
/* Truncate address to the size of a target pointer, avoiding
! shifts larger or equal than the width of a CORE_ADDR. The
! local variable PTR_BIT stops the compiler reporting a shift
! overflow when it won't occure. */
CORE_ADDR addr = unpack_pointer (type, valaddr);
! int ptr_bit = TARGET_PTR_BIT;
! if (ptr_bit < (sizeof (CORE_ADDR) * HOST_CHAR_BIT))
! addr &= ((CORE_ADDR) 1 << ptr_bit) - 1;
print_address (addr, stream);
}
break;
From ac131313@cygnus.com Mon Apr 03 21:37:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: GDB Patches <gdb-patches@sourceware.cygnus.com>
Cc: GDB Discussion <gdb@sourceware.cygnus.com>
Subject: Re: GDB five branch - tuesday GMT?
Date: Mon, 03 Apr 2000 21:37:00 -0000
Message-id: <38E97121.22529DD7@cygnus.com>
References: <38E69E5D.B67C1941@cygnus.com>
X-SW-Source: 2000-04/msg00061.html
Content-length: 415
Andrew Cagney wrote:
>
> [Reply-to: set to gdb-patches]
>
> Looking at what is still outstanding, and assuming I get back positive
> e-mails, I think it will be possible to cut the GDB 5 branch around
> Tuesday lunch GMT.
Nope :-) (Sound of drumming fingers in background).
As soon as the acks come in I'll branch though.
In the mean time, there is no reason for people to stop hacking and
committing.
Andrew
From ac131313@cygnus.com Tue Apr 04 01:09:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: BINUTILS Patches <binutils@sourceware.cygnus.com>, newlib@sourceware.cygnus.com
Cc: GDB Patches <gdb-patches@sourceware.cygnus.com>
Subject: Add md5 checksum to snapshots?
Date: Tue, 04 Apr 2000 01:09:00 -0000
Message-id: <38E9A2DF.6D29B989@cygnus.com>
X-SW-Source: 2000-04/msg00062.html
Content-length: 793
Hello,
The GDB snapshots now include an md5 checksum file (gdb-<release>/md5)
vis:
0636e73ff0215e8d672dc4c32c317bb3 COPYING
f30a9716ef3762e3467a2f62bf790f0a COPYING.LIB
a60b8cbed1f1909e5b22576752a3d06a Makefile.in
07c33a285703b40cd6f93a478e97e03b README
0636e73ff0215e8d672dc4c32c317bb3 bfd/COPYING
425357a8d33e0afc42b7b9c32508128f bfd/ChangeLog
.
.
.
The ``gdb-<version>'' prefix is omitted as it makes a mess of diffs)
Would the binutils + newlib groups be interested in having an equivalent
file included in their snapshots/releases? If so, I can update
src/Makefile.in so that it generates md5 checksums as part of the
archive process. The src/Makefile.in:taz target would be affected.
I could also always make the code conditional on ``MD5'' being defined.
enjoy,
Andrew
From eliz@delorie.com Tue Apr 04 06:28:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: nsd@cygnus.com
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: RFA: infrun.c: mourn instead of kill after TARGET_WAITKIND_SIGNALLED
Date: Tue, 04 Apr 2000 06:28:00 -0000
Message-id: <200004041328.JAA15044@indy.delorie.com>
References: <200004030500.e33504n12192@rtl.cygnus.com>
X-SW-Source: 2000-04/msg00063.html
Content-length: 878
> According to target.h, TARGET_WAITKIND_SIGNALLED does indeed mean that the
> program has terminated, and all current uses of TARGET_WAITKIND_SIGNALLED
> seem to honor that meaning. Here's where it gets used:
>
> in target.c:store_waitstatus() when inferior status is !WIFEXITED() &&
> !WIFSTOPPED()
> in gnu-nat.c:inf_task_died_status() when a task has died
> in go32_wait() #if __DJGPP_MINOR__ < 3; I assume this works around
> a lack in older djgpp implementations
The debug support routines in DJGPP versions before 2.03 had a grave
limitation: whenever the debuggee got any signal, it would die on the
spot, even if it had installed a handler for that signal. DJGPP v2.03
and later don't have this problem, so TARGET_WAITKIND_SIGNALLED is not
used anymore in the DJGPP version of GDB.
In other words, I have no problems whatsoever with this change ;-).
From eliz@delorie.com Tue Apr 04 06:29:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: ac131313@cygnus.com
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: [MAINT/PATCH] ChangeLog et.al.: Revert whitespace changes
Date: Tue, 04 Apr 2000 06:29:00 -0000
Message-id: <200004041328.JAA15047@indy.delorie.com>
References: <38DEF05E.9D2E79AC@cygnus.com> <200003312332.SAA07205@indy.delorie.com> <38E7FE76.DCCD0E1A@cygnus.com> <38E8504B.914ED34E@cygnus.com>
X-SW-Source: 2000-04/msg00064.html
Content-length: 726
> More on this. The M-q (fill-paragraph) that I use (ok its old - 19.34.1
> :-/) likes to prefix each line with:
>
> <TAB>* Makefile.in (CC_FOR_TARGET): Add new winsup directory
> <SPACE><TAB>structure stuff to -L library search.
> <TAB>(CXX_FOR_TARGET): Ditto.
>
> I suspect that another likes to indent it as:
>
> <TAB>* Makefile.in (CC_FOR_TARGET): Add new winsup directory<SPACE>
> <TAB>structure stuff to -L library search.<SPACE>
Emacs 20.5 uses the latter (which is TRT, IMHO).
And while at that: perhaps it's a good idea to upgrade to Emacs 20 to
get uniform format of the date entries in the ChangeLog's, if not for
other good reasons (speed, features, etc.). You aren't scared by the
Mule-hate, are you?
From blizzard@mozilla.org Tue Apr 04 08:12:00 2000
From: Christopher Blizzard <blizzard@mozilla.org>
To: dan@cgsoftware.com
Cc: Chris Faylor <cgf@cygnus.com>, gdb-patches@sourceware.cygnus.com
Subject: Re: source listing change
Date: Tue, 04 Apr 2000 08:12:00 -0000
Message-id: <38EA06B6.41981CCC@mozilla.org>
References: <38E94593.668AAF44@mozilla.org> <20000403215828.A18519@cygnus.com> <38E94D93.C8A5688C@mozilla.org> <20000403220519.A18799@cygnus.com> <38E95A9E.94161B36@mozilla.org> <1z4m35ag.fsf@dan.resnet.rochester.edu> <20000403234440.A12377@cygnus.com> <wvme1pn6.fsf@dan.resnet.rochester.edu>
X-SW-Source: 2000-04/msg00065.html
Content-length: 1401
"Daniel Berlin+list.gdb-patches" wrote:
>
> >>>>> "Chris" == Chris Faylor <cgf@cygnus.com> writes:
> Chris> I guess it is obvious in retrospect that anything which is
> Chris> using gdb as a back-end is not going to rely on 'list'. I
> Chris> guess I don't remember why this patch wasn't just added
> Chris> as-is sans option.
>
> In fact, it makes even less sense the more i think about it (no
> offense, i'm just thinking out in email. Parsing is a hobby of
> mine. Written two full C++ parsers. shiver.).
> because the format is still technically the same.
>
> %d ><random source line>\n
> vs
> %d <random source line>\n
>
> I can't imagine anyone designing a regex parsing the list output
> format that this would affect.
> ([0-9]+)" "([^\n]+) over each line would give you the line number, and
> the rest of the line (I think).
> It wouldn't be affected by this change.
> My point is, their is nothing i can think of that would make something
> think this list format is different than a normal source file which
> happened to start with > on a single line.
>
> Chris> cgf
So, it sounds to me like everyone seems to think that it's a good idea
and that it won't break anything.
--Chris
--
------------
Christopher Blizzard
http://people.redhat.com/blizzard/
Consider the daffodil. And while you're doing that, I'll be over
here, looking through your stuff.
------------
From msnyder@cygnus.com Tue Apr 04 09:10:00 2000
From: Michael Snyder <msnyder@cygnus.com>
To: James Ingham <jingham@cygnus.com>
Cc: gdb-patches@sourceware.cygnus.com, Christopher Blizzard <blizzard@mozilla.org>
Subject: Re: source listing change
Date: Tue, 04 Apr 2000 09:10:00 -0000
Message-id: <38EA21B7.6058@cygnus.com>
References: <38E94593.668AAF44@mozilla.org> <20000403215828.A18519@cygnus.com> <38E94D93.C8A5688C@mozilla.org> <20000403220519.A18799@cygnus.com> <14569.23290.522400.769274@leda.cygnus.com>
X-SW-Source: 2000-04/msg00066.html
Content-length: 1068
James Ingham wrote:
>
> Chris,
>
> > On Mon, Apr 03, 2000 at 10:04:03PM -0400, Christopher Blizzard wrote:
> > >Chris Faylor wrote:
> > >> Yes! Please!
> > >>
> > >> I think that this has been discussed in the past. Do we really need to
> > >> make this a separate option to list?
> > >>
> > >
> > >Honestly, I didn't do any research to see if there was any discussion.
> > >Anyone remember? I'd like to see it as the default. It's a great
> > >visual clue.
> >
> > I vaguely recall that people were concerned that changing this may cause
> > problems for things like ddd, insight, emacs or anything else which
> > interprets output from gdb.
> >
>
> This would not cause insight any problems, and I doubt that emacs or ddd get
> their file listings from running "list" over the pipe to gdb. That
> would be an inordinantly slow way to do it, given that you can get gdb
> to tell you where the file is.
But it would break a lot of GDB testsuites. Somebody would
have to go thru all the new failures and correct the expect code.
Michael
From msnyder@cygnus.com Tue Apr 04 09:19:00 2000
From: Michael Snyder <msnyder@cygnus.com>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: GDB Patches <gdb-patches@sourceware.cygnus.com>
Subject: Re: [PATCH] Avoid GCC shift overflow warning
Date: Tue, 04 Apr 2000 09:19:00 -0000
Message-id: <38EA23CB.36DA@cygnus.com>
References: <38E96C39.51AE3130@cygnus.com>
X-SW-Source: 2000-04/msg00067.html
Content-length: 1867
Andrew Cagney wrote:
>
> FYI,
>
> I've committed the attatched. GCC was still convinced that the shift
> would overflow.
Oooh, that's really weird. Have you reported this as a GCC bug?
>
> Andrew
>
> ---------------------------------------------------------------
> Tue Apr 4 12:13:19 2000 Andrew Cagney <cagney@b1.cygnus.com>
>
> * printcmd.c (print_scalar_formatted): Use local variable ptr_bit
> in shift. Stop GCC thinking it has a shift overflow.
>
> Index: printcmd.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/printcmd.c,v
> retrieving revision 1.2
> diff -p -r1.2 printcmd.c
> *** printcmd.c 2000/03/22 20:55:15 1.2
> --- printcmd.c 2000/04/04 04:11:46
> *************** print_scalar_formatted (valaddr, type, f
> *** 445,454 ****
> case 'a':
> {
> /* Truncate address to the size of a target pointer, avoiding
> ! shifts larger or equal than the width of a CORE_ADDR. */
> 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;
> --- 445,457 ----
> case 'a':
> {
> /* Truncate address to the size of a target pointer, avoiding
> ! shifts larger or equal than the width of a CORE_ADDR. The
> ! local variable PTR_BIT stops the compiler reporting a shift
> ! overflow when it won't occure. */
> CORE_ADDR addr = unpack_pointer (type, valaddr);
> ! int ptr_bit = TARGET_PTR_BIT;
> ! if (ptr_bit < (sizeof (CORE_ADDR) * HOST_CHAR_BIT))
> ! addr &= ((CORE_ADDR) 1 << ptr_bit) - 1;
> print_address (addr, stream);
> }
> break;
From fnasser@redhat.com Tue Apr 04 11:07:00 2000
From: Fernando Nasser <fnasser@redhat.com>
To: msnyder@cygnus.com
Cc: James Ingham <jingham@cygnus.com>, gdb-patches@sourceware.cygnus.com, Christopher Blizzard <blizzard@mozilla.org>
Subject: Re: source listing change
Date: Tue, 04 Apr 2000 11:07:00 -0000
Message-id: <38EA2F05.4E5E6B3C@redhat.com>
References: <38E94593.668AAF44@mozilla.org> <20000403215828.A18519@cygnus.com> <38E94D93.C8A5688C@mozilla.org> <20000403220519.A18799@cygnus.com> <14569.23290.522400.769274@leda.cygnus.com> <38EA21B7.6058@cygnus.com>
X-SW-Source: 2000-04/msg00068.html
Content-length: 522
Michael Snyder wrote:
>
> But it would break a lot of GDB testsuites. Somebody would
> have to go thru all the new failures and correct the expect code.
>
Good point. Patches that cause testsuite regressions are not
acceptable. The test fixes are supposed to be integral part of the
submitted patch.
--
Fernando Nasser
Red Hat, Inc. - Toronto E-Mail: fnasser@redhat.com
2323 Yonge Street, Suite #300 Tel: 416-482-2661 ext. 311
Toronto, Ontario M4P 2C9 Fax: 416-482-6299
From msnyder@cygnus.com Tue Apr 04 11:20:00 2000
From: Michael Snyder <msnyder@cygnus.com>
To: Fernando Nasser <fnasser@redhat.com>
Cc: James Ingham <jingham@cygnus.com>, gdb-patches@sourceware.cygnus.com, Christopher Blizzard <blizzard@mozilla.org>
Subject: Re: source listing change
Date: Tue, 04 Apr 2000 11:20:00 -0000
Message-id: <38EA320A.17D8@cygnus.com>
References: <38E94593.668AAF44@mozilla.org> <20000403215828.A18519@cygnus.com> <38E94D93.C8A5688C@mozilla.org> <20000403220519.A18799@cygnus.com> <14569.23290.522400.769274@leda.cygnus.com> <38EA21B7.6058@cygnus.com> <38EA2F05.4E5E6B3C@redhat.com>
X-SW-Source: 2000-04/msg00069.html
Content-length: 555
Fernando Nasser wrote:
>
> Michael Snyder wrote:
> >
> > But it would break a lot of GDB testsuites. Somebody would
> > have to go thru all the new failures and correct the expect code.
> >
>
> Good point. Patches that cause testsuite regressions are not
> acceptable. The test fixes are supposed to be integral part of the
> submitted patch.
Of course, we as maintainers might take it on ourselves to
verify that it causes testsuite regressions. I was only
speculating (although I'm pretty confident) that it will.
Whose area is this closest to?
From dan@cgsoftware.com Tue Apr 04 11:46:00 2000
From: dan@cgsoftware.com (Daniel Berlin+list.gdb-patches)
To: msnyder@cygnus.com
Cc: James Ingham <jingham@cygnus.com>, gdb-patches@sourceware.cygnus.com, Christopher Blizzard <blizzard@mozilla.org>
Subject: Re: source listing change
Date: Tue, 04 Apr 2000 11:46:00 -0000
Message-id: <ln2tyaa2.fsf@dan.resnet.rochester.edu>
References: <38E94593.668AAF44@mozilla.org> <20000403215828.A18519@cygnus.com> <38E94D93.C8A5688C@mozilla.org> <20000403220519.A18799@cygnus.com> <14569.23290.522400.769274@leda.cygnus.com> <38EA21B7.6058@cygnus.com>
X-SW-Source: 2000-04/msg00070.html
Content-length: 410
>>>>> "Michael" == Michael Snyder <msnyder@cygnus.com> writes:
Michael> But it would break a lot of GDB testsuites. Somebody
Michael> would have to go thru all the new failures and correct
Michael> the expect code.
No it wouldn't.
I can't see a single test it would break.
Actually, there is one test it will break.
list.exp.
I'll submit patches for it in a minute.
Michael> Michael
From msnyder@cygnus.com Tue Apr 04 14:02:00 2000
From: Michael Snyder <msnyder@cygnus.com>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: Nick Duffek <nsd@cygnus.com>, gdb-patches@sourceware.cygnus.com
Subject: Re: RFA: infrun.c: mourn instead of kill after TARGET_WAITKIND_SIGNALLED
Date: Tue, 04 Apr 2000 14:02:00 -0000
Message-id: <38EA5847.216B@cygnus.com>
References: <200004030500.e33504n12192@rtl.cygnus.com> <38E8590C.7FA92373@cygnus.com>
X-SW-Source: 2000-04/msg00071.html
Content-length: 434
Andrew Cagney wrote:
>
> Nick Duffek wrote:
> >
> > The appended patch calls target_mourn_inferior() instead of target_kill()
> > in response to TARGET_WAITKIND_SIGNALLED in handle_inferior_event().
>
> Nick, for what its worth, I have no problems with the change. I
> suspect, however that Stan and Michael S may have a better idea of the
> history.
Not me -- it predates me. ;-)
I think it looks good, though.
Michael S.
From shebs@apple.com Tue Apr 04 14:16:00 2000
From: Stan Shebs <shebs@apple.com>
To: Nick Duffek <nsd@cygnus.com>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: RFA: infrun.c: mourn instead of kill after TARGET_WAITKIND_SIGNALLED
Date: Tue, 04 Apr 2000 14:16:00 -0000
Message-id: <38EA69D4.793CE375@apple.com>
References: <200004030500.e33504n12192@rtl.cygnus.com>
X-SW-Source: 2000-04/msg00072.html
Content-length: 1479
Nick Duffek wrote:
>
> The appended patch calls target_mourn_inferior() instead of target_kill()
> in response to TARGET_WAITKIND_SIGNALLED in handle_inferior_event().
>
> This comment precedes the target_kill():
>
> /* This looks pretty bogus to me. Doesn't TARGET_WAITKIND_SIGNALLED
> mean it is already dead? This has been here since GDB 2.8, so
> perhaps it means rms didn't understand unix waitstatuses?
> For the moment I'm just kludging around this in remote.c
> rather than trying to change it here --kingdon, 5 Dec 1994. */
>
> According to target.h, TARGET_WAITKIND_SIGNALLED does indeed mean that the
> program has terminated, and all current uses of TARGET_WAITKIND_SIGNALLED
> seem to honor that meaning. Here's where it gets used:
I've always wanted to understand that bit of code, but never got a
chance to really research it, so I don't have any additional info.
Given the antiquity of this bit, it's conceivable that some mid-80s
Unix flavor had a bug where processes weren't quite dead even
though reported as such, and target_kill was just an extra bullet
in the brain, just in case (how graphic).
Let's go with this change, but add a comment to the effect that
this used to be target_kill but nobody knew why, and maybe a bit of
the commentary that you included in your message, so that a future
hacker who discovers why target_kill is necessary won't be quite as
mystified as we are about why the code works as it does.
Stan
From jimb@zwingli.cygnus.com Tue Apr 04 14:47:00 2000
From: Jim Blandy <jimb@zwingli.cygnus.com>
To: gdb-patches@sourceware.cygnus.com
Subject: RFA: document raw/virtual stuff
Date: Tue, 04 Apr 2000 14:47:00 -0000
Message-id: <200004042147.QAA27840@zwingli.cygnus.com>
X-SW-Source: 2000-04/msg00073.html
Content-length: 6856
Please check for accuracy and clarity.
2000-04-04 Jim Blandy <jimb@redhat.com>
* gdbint.texinfo (Using Different Target and Host Data
Representations): New section.
(REGISTER_CONVERTIBLE, REGISTER_RAW_SIZE, REGISTER_VIRTUAL_SIZE,
REGISTER_VIRTUAL_TYPE, REGISTER_CONVERT_TO_VIRTUAL,
REGISTER_CONVERT_TO_RAW): Document.
Index: gdbint.texinfo
===================================================================
RCS file: /cvs/src/src/gdb/doc/gdbint.texinfo,v
retrieving revision 1.4
diff -c -c -b -F'^(' -r1.4 gdbint.texinfo
*** gdbint.texinfo 2000/03/23 23:50:51 1.4
--- gdbint.texinfo 2000/04/04 21:46:54
***************
*** 1153,1158 ****
--- 1153,1256 ----
GDB can handle big-endian, little-endian, and bi-endian architectures.
+ @section Using Different Target and Host Data Representations
+
+ When cross-debugging, it is sometimes necessary for GDB to use an
+ internal representation for some values which is different from the
+ representation used on the target. For certain types, the format used
+ in a @code{struct value} object may differ from the value's format on
+ the target.
+
+ In GDB's terminology, the @dfn{raw} representation is the one used on
+ the target, and the @dfn{virtual} representation is the one used within
+ GDB @code{struct value} objects. For almost all data types on almost
+ all architectures, the virtual and raw representations are identical,
+ and no special handling is needed. However, they do occasionally
+ differ. For example:
+
+ @itemize @bullet
+
+ @item
+ The x86 architecture supports an 80-bit floating-point type. If we're
+ running GDB on a host that doesn't support 80-bit floats, we will
+ convert those values to the largest floating-point type available on the
+ host. Thus, the x86 80-bit floating-point type is the @dfn{raw}
+ representation, and the host's largest floating-point type is the
+ @dfn{virtual} representation. (This is not a great example; GDB ought
+ to emulate the target's floating-point arithmetic in software, rather
+ than performing a possibly lossy conversion to a host floating-point
+ type.)
+
+ @item
+ The D10V architecture has 16-bit addresses, and separate code and data
+ address spaces. The raw representation is thus a straight 16-bit value.
+ GDB's virtual representation for D10V pointers is actually 32 bits long,
+ and uses the upper bits to indicate whether the pointer refers to code
+ space or data space. These extra upper bits allow GDB to correctly
+ dereference pointers of either type.
+
+ @end itemize
+
+ In general, the raw representation is determined by the architecture,
+ while the virtual representation can be chosen for GDB's convenience.
+ GDB's register file, @code{registers}, holds the register contents in
+ raw format, and the GDB remote protocol transmits register values in raw
+ format.
+
+ At present, GDB can only convert between raw and virtual formats when
+ reading and writing machine registers. GDB is unable to operate on
+ values that appear in memory in raw format, when the raw format is not
+ identical to the virtual format. There's no particular reason to
+ restrict conversions to register values; it's just a quirk of history.
+
+ Your architecture may define the following macros to request raw /
+ virtual conversions:
+
+ @deftypefn {Target Macro} int REGISTER_CONVERTIBLE (int @var{reg})
+ Return non-zero if register number @var{reg}'s value needs different raw
+ and virtual formats.
+ @end deftypefn
+
+ @deftypefn {Target Macro} int REGISTER_RAW_SIZE (int @var{reg})
+ The size of register number @var{reg}'s raw value. This is the number
+ of bytes the register will occupy in @code{registers}, or in a GDB
+ remote protocol packet.
+ @end deftypefn
+
+ @deftypefn {Target Macro} int REGISTER_VIRTUAL_SIZE (int @var{reg})
+ The size of register number @var{reg}'s value, in its virtual format.
+ This is the size a @code{struct value}'s buffer will have, holding that
+ register's value.
+ @end deftypefn
+
+ @deftypefn {Target Macro} struct type *REGISTER_VIRTUAL_TYPE (int @var{reg})
+ This is the type of the virtual representation of register number
+ @var{reg}. Note that there is no need for a macro giving the register's
+ raw type; types only matter for @code{struct value} objects, so they
+ only apply to virtual representations.
+ @end deftypefn
+
+ @deftypefn {Target Macro} void REGISTER_CONVERT_TO_VIRTUAL (int @var{reg}, struct type *@var{type}, char *@var{from}, char *@var{to})
+ Convert the value of register number @var{reg} to @var{type}, which
+ should always be @code{REGISTER_VIRTUAL_TYPE (@var{reg})}. The buffer
+ at @var{from} holds the register's value in raw format; the macro should
+ convert the value to virtual format, and place it at @var{to}.
+
+ Note that REGISTER_CONVERT_TO_VIRTUAL and REGISTER_CONVERT_TO_RAW take
+ their @var{reg} and @var{type} arguments in different orders.
+ @end deftypefn
+
+ @deftypefn {Target Macro} void REGISTER_CONVERT_TO_RAW (struct type *@var{type}, int @var{reg}, char *@var{from}, char *@var{to})
+ Convert the value of register number @var{reg} to @var{type}, which
+ should always be @code{REGISTER_VIRTUAL_TYPE (@var{reg})}. The buffer
+ at @var{from} holds the register's value in raw format; the macro should
+ convert the value to virtual format, and place it at @var{to}.
+
+ Note that REGISTER_CONVERT_TO_VIRTUAL and REGISTER_CONVERT_TO_RAW take
+ their @var{reg} and @var{type} arguments in different orders.
+ @end deftypefn
+
+
@section Frame Interpretation
@section Inferior Call Setup
***************
*** 1583,1588 ****
--- 1681,1710 ----
@item NO_HIF_SUPPORT
(Specific to the a29k.)
+
+ @item REGISTER_CONVERTIBLE (@var{reg})
+ Return non-zero if @var{reg} uses different raw and virtual formats.
+ @xref{Using Different Target and Host Data Representations}.
+
+ @item REGISTER_RAW_SIZE (@var{reg})
+ Return the raw size of @var{reg}.
+ @xref{Using Different Target and Host Data Representations}.
+
+ @item REGISTER_VIRTUAL_SIZE (@var{reg})
+ Return the virtual size of @var{reg}.
+ @xref{Using Different Target and Host Data Representations}.
+
+ @item REGISTER_VIRTUAL_TYPE (@var{reg})
+ Return the virtual type of @var{reg}.
+ @xref{Using Different Target and Host Data Representations}.
+
+ @item REGISTER_CONVERT_TO_VIRTUAL(@var{reg}, @var{type}, @var{from}, @var{to})
+ Convert the value of register @var{reg} from its raw form to its virtual
+ form. @xref{Using Different Target and Host Data Representations}.
+
+ @item REGISTER_CONVERT_TO_RAW(@var{type}, @var{reg}, @var{from}, @var{to})
+ Convert the value of register @var{reg} from its virtual form to its raw
+ form. @xref{Using Different Target and Host Data Representations}.
@item SOFTWARE_SINGLE_STEP_P
Define this as 1 if the target does not have a hardware single-step
From raz@cynapps.com Tue Apr 04 14:58:00 2000
From: Robert Zimmermann <raz@cynapps.com>
To: gdb-patches@sourceware.cygnus.com
Subject: patch for gdb 4.18
Date: Tue, 04 Apr 2000 14:58:00 -0000
Message-id: <38EA3E7D.5698DA7B@cynapps.com>
X-SW-Source: 2000-04/msg00074.html
Content-length: 1759
description:
when demanging gnu internal types, the function mop_up()Â is
called. when that happens, the typevec is cleared with forget_types().Â
Following that,
the vector itself is freed. Unfortunately, the vector size is
not reset.
changelog:
 must reset typevec_size whenever typevec is free'd and
NULL'd
patch:
diff -up OLD/cplus-dem.c NEW/cplus-dem.c
--- OLD/cplus-dem.c    Tue Apr 4 15:10:22
2000
+++ NEW/cplus-dem.c    Tue Apr 4 15:09:57
2000
@@ -880,6 +880,7 @@ mop_up (work, declp, success)
    {
      free ((char *) work -> typevec);
      work -> typevec = NULL;
+Â Â Â Â Â work -> typevec_size = 0;Â Â Â Â Â Â Â
// raz
    }
  if (work->tmpl_argvec)
    {
@@ -891,6 +892,7 @@ mop_up (work, declp, success)
Â
      free ((char*) work->tmpl_argvec);
      work->tmpl_argvec = NULL;
+Â Â Â Â Â work->ntmpl_args = 0;Â Â Â
// raz
    }
  if (work->previous_argument)
    {
Â
--Â
===============================================================================
Robert A Zimmermann
Member Technical Staff
412-321-4348
raz@cynapps.com
CynApps Inc., Suite 302, Cardello Bldg., 1501 Reedsdale St., Pittsburgh, PA 15233
Â
diff -up OLD/cplus-dem.c NEW/cplus-dem.c
--- OLD/cplus-dem.c Tue Apr 4 15:10:22 2000
+++ NEW/cplus-dem.c Tue Apr 4 15:09:57 2000
@@ -880,6 +880,7 @@ mop_up (work, declp, success)
{
free ((char *) work -> typevec);
work -> typevec = NULL;
+ work -> typevec_size = 0; // raz
}
if (work->tmpl_argvec)
{
@@ -891,6 +892,7 @@ mop_up (work, declp, success)
free ((char*) work->tmpl_argvec);
work->tmpl_argvec = NULL;
+ work->ntmpl_args = 0; // raz
}
if (work->previous_argument)
{
From ac131313@cygnus.com Tue Apr 04 15:33:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Eli Zaretskii <eliz@is.elta.co.il>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: [MAINT/PATCH] ChangeLog et.al.: Revert whitespace changes
Date: Tue, 04 Apr 2000 15:33:00 -0000
Message-id: <38EA6D50.D1EEB9CB@cygnus.com>
References: <38DEF05E.9D2E79AC@cygnus.com> <200003312332.SAA07205@indy.delorie.com> <38E7FE76.DCCD0E1A@cygnus.com> <38E8504B.914ED34E@cygnus.com> <200004041328.JAA15047@indy.delorie.com>
X-SW-Source: 2000-04/msg00075.html
Content-length: 1010
Eli Zaretskii wrote:
>
> > More on this. The M-q (fill-paragraph) that I use (ok its old - 19.34.1
> > :-/) likes to prefix each line with:
> >
> > <TAB>* Makefile.in (CC_FOR_TARGET): Add new winsup directory
> > <SPACE><TAB>structure stuff to -L library search.
> > <TAB>(CXX_FOR_TARGET): Ditto.
> >
> > I suspect that another likes to indent it as:
> >
> > <TAB>* Makefile.in (CC_FOR_TARGET): Add new winsup directory<SPACE>
> > <TAB>structure stuff to -L library search.<SPACE>
>
> Emacs 20.5 uses the latter (which is TRT, IMHO).
>
> And while at that: perhaps it's a good idea to upgrade to Emacs 20 to
> get uniform format of the date entries in the ChangeLog's, if not for
> other good reasons (speed, features, etc.). You aren't scared by the
> Mule-hate, are you?
You mean run a version of emacs which has minor-version < major-version?
Scary! Besides, I like being able to search for ``Tue Apr 3 12:13:19
2000'', it works much better than 2000-04-03 ;-)
Andrew
From ac131313@cygnus.com Tue Apr 04 16:55:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: BINUTILS Patches <binutils@sourceware.cygnus.com>, GDB Patches <gdb-patches@sourceware.cygnus.com>, newlib@sourceware.cygnus.com
Subject: RFC src/configure* - "CFLAGS=-g -O" instead of "CFLAGS=... -Wall"
Date: Tue, 04 Apr 2000 16:55:00 -0000
Message-id: <38EA8086.344CD42A@cygnus.com>
X-SW-Source: 2000-04/msg00076.html
Content-length: 358
Hello,
At present the top level configure + Makefile.in force (when GCC) CFLAGS
to:
CFLAGS = -g -O -Wall
I'd like to scale that back to just:
CFLAGS = -g -O
letting each sub directory set their own -W* policy. The src/gdb and
src/sim directories try to do this now using separate WARN_CFLAGS (only
they get overuled by CFLAGS :-).
enjoy,
Andrew
From ian@zembu.com Tue Apr 04 17:04:00 2000
From: Ian Lance Taylor <ian@zembu.com>
To: ac131313@cygnus.com
Cc: binutils@sourceware.cygnus.com, gdb-patches@sourceware.cygnus.com, newlib@sourceware.cygnus.com
Subject: Re: RFC src/configure* - "CFLAGS=-g -O" instead of "CFLAGS=... -Wall"
Date: Tue, 04 Apr 2000 17:04:00 -0000
Message-id: <20000405000414.1640.qmail@daffy.airs.com>
References: <38EA8086.344CD42A@cygnus.com>
X-SW-Source: 2000-04/msg00077.html
Content-length: 669
Date: Wed, 05 Apr 2000 09:53:42 +1000
From: Andrew Cagney <ac131313@cygnus.com>
At present the top level configure + Makefile.in force (when GCC) CFLAGS
to:
CFLAGS = -g -O -Wall
I'd like to scale that back to just:
CFLAGS = -g -O
letting each sub directory set their own -W* policy. The src/gdb and
src/sim directories try to do this now using separate WARN_CFLAGS (only
they get overuled by CFLAGS :-).
That was a policy I put in for the binutils. It's OK with me to
change it provided you simultaneously change the binutils
subdirectories (binutils, bfd, libiberty, opcodes, binutils, gas, ld,
gprof) to default to -Wall.
Ian
From msnyder@cygnus.com Tue Apr 04 17:09:00 2000
From: Michael Snyder <msnyder@cygnus.com>
To: "Peter.Schauer" <Peter.Schauer@regent.e-technik.tu-muenchen.de>
Cc: gdb-patches@sourceware.cygnus.com, cagney@cygnus.com
Subject: Re: RFA: procfs.c: init_procfs_ops should set procfs_ops.to_has_[all]_memory
Date: Tue, 04 Apr 2000 17:09:00 -0000
Message-id: <38EA835E.66CE@cygnus.com>
References: <200003271538.RAA03884@reisser.regent.e-technik.tu-muenchen.de>
X-SW-Source: 2000-04/msg00078.html
Content-length: 2044
Peter.Schauer wrote:
>
> I am pretty sure that this is caused by some accidental deletion, but
> procfs.c:init_procfs_ops no longer sets procfs_ops.to_has_memory and
> procfs_ops.to_has_all_memory.
You're probably right, and the accidental deletion was probably
mine. Please commit this change.
Michael
> I noticed it when issuing an `i target' command on Solaris with a running
> executable:
>
> (gdb) i target
> Symbols from "/home2/pes/gnu/gdb/gdbnd/solx86/gdb/testsuite/gdb.base/run".
> Local exec file:
> `/home2/pes/gnu/gdb/gdbnd/solx86/gdb/testsuite/gdb.base/run',
> file type elf32-i386.
> Entry point: 0x8048a34
> 0x080480f4 - 0x08048105 is .interp
> .
> .
>
> After applying the patch below I get the more familiar:
>
> (gdb) i target
> Symbols from "/home2/pes/gnu/gdb/gdbnd/solx86/gdb/testsuite/gdb.base/run".
> Unix /proc child process:
> Using the running image of child LWP 1 via /proc.
> While running this, GDB does not access memory from...
> Local exec file:
> `/home2/pes/gnu/gdb/gdbnd/solx86/gdb/testsuite/gdb.base/run',
> file type elf32-i386.
> Entry point: 0x8048a34
> 0x080480f4 - 0x08048105 is .interp
> .
> .
>
> 2000-03-27 Peter Schauer <pes@regent.e-technik.tu-muenchen.de>
>
> * procfs.c (init_procfs_ops): Set procfs_ops.to_has_memory and
> procfs_ops.to_has_all_memory to 1.
>
> --- gdb/procfs.c.orig Wed Mar 1 21:54:05 2000
> +++ gdb/procfs.c Sun Mar 26 22:07:31 2000
> @@ -154,6 +154,8 @@ init_procfs_ops ()
> procfs_ops.to_thread_alive = procfs_thread_alive;
> procfs_ops.to_pid_to_str = procfs_pid_to_str;
>
> + procfs_ops.to_has_all_memory = 1;
> + procfs_ops.to_has_memory = 1;
> procfs_ops.to_has_execution = 1;
> procfs_ops.to_has_stack = 1;
> procfs_ops.to_has_registers = 1;
>
> --
> Peter Schauer pes@regent.e-technik.tu-muenchen.de
From geoffk@cygnus.com Tue Apr 04 17:13:00 2000
From: Geoff Keating <geoffk@cygnus.com>
To: ac131313@cygnus.com
Cc: binutils@sourceware.cygnus.com, gdb-patches@sourceware.cygnus.com, newlib@sourceware.cygnus.com
Subject: Re: RFC src/configure* - "CFLAGS=-g -O" instead of "CFLAGS=... -Wall"
Date: Tue, 04 Apr 2000 17:13:00 -0000
Message-id: <200004050013.RAA20321@localhost.cygnus.com>
References: <38EA8086.344CD42A@cygnus.com>
X-SW-Source: 2000-04/msg00079.html
Content-length: 840
> Date: Wed, 05 Apr 2000 09:53:42 +1000
> From: Andrew Cagney <ac131313@cygnus.com>
> Organization: Cygnus Solutions
> X-Accept-Language: en
>
> Hello,
>
> At present the top level configure + Makefile.in force (when GCC) CFLAGS
> to:
>
> CFLAGS = -g -O -Wall
>
> I'd like to scale that back to just:
>
> CFLAGS = -g -O
>
> letting each sub directory set their own -W* policy. The src/gdb and
> src/sim directories try to do this now using separate WARN_CFLAGS (only
> they get overuled by CFLAGS :-).
GCC has
CFLAGS = -g @stage1_warn_cflags@
WARN_CFLAGS = -W -Wall -Wtraditional
where @stage1_warn_cflags@ gets turned into $(WARN_CFLAGS), or not,
depending on whether the compiler is GCC. This also gets overruled
from the toplevel CFLAGS, which is probably why the -Wall is there.
--
- Geoffrey Keating <geoffk@cygnus.com>
From msnyder@cygnus.com Tue Apr 04 17:16:00 2000
From: Michael Snyder <msnyder@cygnus.com>
To: Geoff Keating <geoffk@cygnus.com>
Cc: ac131313@cygnus.com, binutils@sourceware.cygnus.com, gdb-patches@sourceware.cygnus.com, newlib@sourceware.cygnus.com
Subject: Re: RFC src/configure* - "CFLAGS=-g -O" instead of "CFLAGS=... -Wall"
Date: Tue, 04 Apr 2000 17:16:00 -0000
Message-id: <38EA85C6.3E5B@cygnus.com>
References: <38EA8086.344CD42A@cygnus.com> <200004050013.RAA20321@localhost.cygnus.com>
X-SW-Source: 2000-04/msg00080.html
Content-length: 1108
Geoff Keating wrote:
>
> > Date: Wed, 05 Apr 2000 09:53:42 +1000
> > From: Andrew Cagney <ac131313@cygnus.com>
> > Organization: Cygnus Solutions
> > X-Accept-Language: en
> >
> > Hello,
> >
> > At present the top level configure + Makefile.in force (when GCC) CFLAGS
> > to:
> >
> > CFLAGS = -g -O -Wall
> >
> > I'd like to scale that back to just:
> >
> > CFLAGS = -g -O
> >
> > letting each sub directory set their own -W* policy. The src/gdb and
> > src/sim directories try to do this now using separate WARN_CFLAGS (only
> > they get overuled by CFLAGS :-).
>
> GCC has
>
> CFLAGS = -g @stage1_warn_cflags@
> WARN_CFLAGS = -W -Wall -Wtraditional
>
> where @stage1_warn_cflags@ gets turned into $(WARN_CFLAGS), or not,
> depending on whether the compiler is GCC. This also gets overruled
> from the toplevel CFLAGS, which is probably why the -Wall is there.
I believe ALL the subdirectory CFLAGS are overruled by the
toplevel CFLAGS. If we make this change, then in order to
get the -Wall behavior, it will be necessary to run make
from the subdirectory, or pass CFLAGS in to make.
From kettenis@wins.uva.nl Tue Apr 04 17:26:00 2000
From: Mark Kettenis <kettenis@wins.uva.nl>
To: jimb@zwingli.cygnus.com
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: RFA: document raw/virtual stuff
Date: Tue, 04 Apr 2000 17:26:00 -0000
Message-id: <200004050026.e350QJU00431@delius.kettenis.local>
References: <200004042147.QAA27840@zwingli.cygnus.com>
X-SW-Source: 2000-04/msg00081.html
Content-length: 585
Date: Tue, 4 Apr 2000 16:47:26 -0500 (EST)
From: Jim Blandy <jimb@zwingli.cygnus.com>
Please check for accuracy and clarity.
2000-04-04 Jim Blandy <jimb@redhat.com>
* gdbint.texinfo (Using Different Target and Host Data
Representations): New section.
(REGISTER_CONVERTIBLE, REGISTER_RAW_SIZE, REGISTER_VIRTUAL_SIZE,
REGISTER_VIRTUAL_TYPE, REGISTER_CONVERT_TO_VIRTUAL,
REGISTER_CONVERT_TO_RAW): Document.
I think this isn't right for the reasons mentioned in my other mail.
Different target and host data representions aren't the issue here.
Mark
From ac131313@cygnus.com Tue Apr 04 17:45:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Ian Lance Taylor <ian@zembu.com>
Cc: binutils@sourceware.cygnus.com, gdb-patches@sourceware.cygnus.com, newlib@sourceware.cygnus.com
Subject: Re: RFC src/configure* - "CFLAGS=-g -O" instead of "CFLAGS=... -Wall"
Date: Tue, 04 Apr 2000 17:45:00 -0000
Message-id: <38EA8C15.386D9C40@cygnus.com>
References: <38EA8086.344CD42A@cygnus.com> <20000405000414.1640.qmail@daffy.airs.com>
X-SW-Source: 2000-04/msg00082.html
Content-length: 933
Ian Lance Taylor wrote:
>
> Date: Wed, 05 Apr 2000 09:53:42 +1000
> From: Andrew Cagney <ac131313@cygnus.com>
>
> At present the top level configure + Makefile.in force (when GCC) CFLAGS
> to:
>
> CFLAGS = -g -O -Wall
>
> I'd like to scale that back to just:
>
> CFLAGS = -g -O
>
> letting each sub directory set their own -W* policy. The src/gdb and
> src/sim directories try to do this now using separate WARN_CFLAGS (only
> they get overuled by CFLAGS :-).
>
> That was a policy I put in for the binutils. It's OK with me to
> change it provided you simultaneously change the binutils
> subdirectories (binutils, bfd, libiberty, opcodes, binutils, gas, ld,
> gprof) to default to -Wall.
How exactly do you want this done? If I add:
CFLAGS=-g -O -Wall
to the sub directory makefiles, that will just get overridden by the top
level (just like GDB suffers today).
Andrew
From nsd@cygnus.com Tue Apr 04 17:56:00 2000
From: Nick Duffek <nsd@cygnus.com>
To: gdb-patches@sourceware.cygnus.com
Subject: accumulated Solaris/x86 patch
Date: Tue, 04 Apr 2000 17:56:00 -0000
Message-id: <200004050059.e350xXg13592@rtl.cygnus.com>
X-SW-Source: 2000-04/msg00083.html
Content-length: 11852
This patch is an accumulation of Solaris/x86 fixes by Michael Snyder, plus
a fix by me to allow compilation on Solaris 7.
No regressions are evident on i386-pc-solaris2.7, sparc-sun-solaris2.6, or
sparc-sun-solaris2.5.1.
Comments welcome,
Nick Duffek
nsd@cygnus.com
[patch follows, excluding regenerated configure script]
Index: configure.in
===================================================================
RCS file: /cvs/src/src/gdb/configure.in,v
retrieving revision 1.15
diff -u -r1.15 configure.in
--- configure.in 2000/04/04 02:08:52 1.15
+++ configure.in 2000/04/04 02:16:53
@@ -88,6 +88,14 @@
AC_HEADER_STDC
+dnl Solaris 7 needs _MSE_INT_H defined to avoid a clash between <widec.h>
+dnl and <wchar.h> that causes AC_CHECK_HEADERS to think <curses.h> doesn't
+dnl exist.
+
+case $host_os in solaris2.7) case "$GCC" in yes)
+ AC_DEFINE(_MSE_INT_H)
+esac; esac
+
AC_CHECK_HEADERS(ctype.h curses.h endian.h link.h thread_db.h proc_service.h \
memory.h objlist.h ptrace.h sgtty.h stddef.h stdlib.h \
string.h sys/procfs.h sys/ptrace.h sys/reg.h stdint.h \
@@ -176,10 +184,7 @@
*-*-unixware* | *-*-sysv4.2* | *-*-sysv5*)
AC_DEFINE(NEW_PROC_API)
;;
- # FIXME: we would like to define NEW_PROC_API for all versions of
- # Solaris from 2.6 on... but it isn't quite working yet. Seems
- # to work on sparc 2.6, so let's try it out there.
- sparc-sun-solaris2.6)
+ *-*-solaris2.[678])
AC_DEFINE(NEW_PROC_API)
;;
esac
Index: acconfig.h
===================================================================
RCS file: /cvs/src/src/gdb/acconfig.h,v
retrieving revision 1.3
diff -u -r1.3 acconfig.h
--- acconfig.h 2000/03/28 00:03:57 1.3
+++ acconfig.h 2000/04/04 02:16:53
@@ -1,3 +1,6 @@
+/* Define if compiling on Solaris 7. */
+#undef _MSE_INT_H
+
/* Define if pstatus_t type is available */
#undef HAVE_PSTATUS_T
Index: config.in
===================================================================
RCS file: /cvs/src/src/gdb/config.in,v
retrieving revision 1.5
diff -u -r1.5 config.in
--- config.in 2000/03/28 00:03:57 1.5
+++ config.in 2000/04/04 02:16:53
@@ -59,6 +59,9 @@
/* Define if you have the ANSI C header files. */
#undef STDC_HEADERS
+/* Define if compiling on Solaris 7. */
+#undef _MSE_INT_H
+
/* Define if you want to use new multi-fd /proc interface
(replaces HAVE_MULTIPLE_PROC_FDS as well as other macros). */
#undef NEW_PROC_API
Index: procfs.c
===================================================================
RCS file: /cvs/src/src/gdb/procfs.c,v
retrieving revision 1.4
diff -u -r1.4 procfs.c
--- procfs.c 2000/03/28 19:02:47 1.4
+++ procfs.c 2000/04/04 02:16:59
@@ -5254,3 +5254,20 @@
else
return -1;
}
+
+int
+procfs_get_pid_fd (pid)
+ int pid;
+{
+ procinfo *pi;
+
+ if (pid == -1 && inferior_pid != 0)
+ pi = find_procinfo (PIDGET (inferior_pid), 0);
+ else
+ pi = find_procinfo (PIDGET (pid), 0);
+
+ if (pi)
+ return pi->ctl_fd;
+ else
+ return -1;
+}
Index: sol-thread.c
===================================================================
RCS file: /cvs/src/src/gdb/sol-thread.c,v
retrieving revision 1.3
diff -u -r1.3 sol-thread.c
--- sol-thread.c 2000/03/23 21:44:50 1.3
+++ sol-thread.c 2000/04/04 02:17:01
@@ -122,14 +122,26 @@
/* Default definitions: These must be defined in tm.h
if they are to be shared with a process module such as procfs. */
-#define THREAD_FLAG 0x80000000
-#define is_thread(ARG) (((ARG) & THREAD_FLAG) != 0)
-#define is_lwp(ARG) (((ARG) & THREAD_FLAG) == 0)
-#define GET_LWP(PID) TIDGET (PID)
-#define GET_THREAD(PID) (((PID) >> 16) & 0x7fff)
-#define BUILD_LWP(TID, PID) ((TID) << 16 | (PID))
+#ifndef PIDGET
+#define PIDGET(PID) (((PID) & 0xffff))
+#endif
+
+#ifndef TIDGET
+#define TIDGET(PID) (((PID) & 0x7fffffff) >> 16)
+#endif
+
+#ifndef MERGEPID
+#define MERGEPID(PID, TID) (((PID) & 0xffff) | ((TID) << 16))
+#endif
+
+#define THREAD_FLAG 0x80000000
+#define is_thread(ARG) (((ARG) & THREAD_FLAG) != 0)
+#define is_lwp(ARG) (((ARG) & THREAD_FLAG) == 0)
+#define GET_LWP(PID) TIDGET (PID)
+#define GET_THREAD(PID) TIDGET (PID)
+#define BUILD_LWP(TID, PID) MERGEPID (PID, TID)
-#define BUILD_THREAD(THREAD_ID, PID) (THREAD_FLAG | BUILD_LWP (THREAD_ID, PID))
+#define BUILD_THREAD(TID, PID) (MERGEPID (PID, TID) | THREAD_FLAG)
/* Pointers to routines from lithread_db resolved by dlopen() */
@@ -1327,6 +1339,12 @@
/* NOTE: only used on Solaris, therefore OK to refer to procfs.c */
extern struct ssd *procfs_find_LDT_entry (int);
struct ssd *ret;
+
+ /* FIXME: can't I get the process ID from the prochandle or something?
+ */
+
+ if (inferior_pid <= 0 || lwpid <= 0)
+ return PS_BADLID;
ret = procfs_find_LDT_entry (BUILD_LWP (lwpid, PIDGET (inferior_pid)));
if (ret)
Index: config/i386/nm-i386sol2.h
===================================================================
RCS file: /cvs/src/src/gdb/config/i386/nm-i386sol2.h,v
retrieving revision 1.1.1.5
diff -u -r1.1.1.5 nm-i386sol2.h
--- nm-i386sol2.h 1999/11/09 01:23:11 1.1.1.5
+++ nm-i386sol2.h 2000/04/04 02:17:01
@@ -20,3 +20,31 @@
#include "nm-sysv4.h"
+#ifdef NEW_PROC_API /* Solaris 6 and above can do HW watchpoints */
+
+#define TARGET_HAS_HARDWARE_WATCHPOINTS
+
+/* The man page for proc4 on solaris 6 and 7 says that the system
+ can support "thousands" of hardware watchpoints, but gives no
+ method for finding out how many. So just tell GDB 'yes'. */
+#define TARGET_CAN_USE_HARDWARE_WATCHPOINT(TYPE, CNT, OT) 1
+
+/* When a hardware watchpoint fires off the PC will be left at the
+ instruction following the one which caused the watchpoint.
+ It will *NOT* be necessary for GDB to step over the watchpoint. */
+#define HAVE_CONTINUABLE_WATCHPOINT
+
+extern int procfs_stopped_by_watchpoint PARAMS ((int));
+#define STOPPED_BY_WATCHPOINT(W) \
+ procfs_stopped_by_watchpoint(inferior_pid)
+
+/* Use these macros for watchpoint insertion/deletion. */
+/* type can be 0: write watch, 1: read watch, 2: access watch (read/write) */
+
+extern int procfs_set_watchpoint PARAMS ((int, CORE_ADDR, int, int, int));
+#define target_insert_watchpoint(ADDR, LEN, TYPE) \
+ procfs_set_watchpoint (inferior_pid, ADDR, LEN, TYPE, 1)
+#define target_remove_watchpoint(ADDR, LEN, TYPE) \
+ procfs_set_watchpoint (inferior_pid, ADDR, 0, 0, 0)
+
+#endif /* NEW_PROC_API */
Index: config/i386/tm-i386sol2.h
===================================================================
RCS file: /cvs/src/src/gdb/config/i386/tm-i386sol2.h,v
retrieving revision 1.2
diff -u -r1.2 tm-i386sol2.h
--- tm-i386sol2.h 2000/02/29 13:38:55 1.2
+++ tm-i386sol2.h 2000/04/04 02:17:01
@@ -42,9 +42,11 @@
#define FAULTED_USE_SIGINFO
-/* Macros to extract process id and thread id from a composite pid/tid */
-#define PIDGET(pid) ((pid) & 0xffff)
-#define TIDGET(pid) (((pid) >> 16) & 0xffff)
-#define MERGEPID(pid, tid) (((tid) << 16) | (pid))
+/* Macros to extract process id and thread id from a composite pid/tid.
+ Allocate lower 19 bits for process id, next 12 bits for thread id, and
+ one bit for a flag to indicate a user thread vs. a kernel thread. */
+#define PIDGET(PID) (((PID) & 0x3ffff))
+#define TIDGET(PID) (((PID) & 0x7fffffff) >> 18)
+#define MERGEPID(PID, TID) (((PID) & 0x3ffff) | ((TID) << 18))
#endif /* ifndef TM_I386SOL2_H */
Index: config/sparc/nm-sun4sol2.h
===================================================================
RCS file: /cvs/src/src/gdb/config/sparc/nm-sun4sol2.h,v
retrieving revision 1.1.1.5
diff -u -r1.1.1.5 nm-sun4sol2.h
--- nm-sun4sol2.h 1999/11/09 01:23:12 1.1.1.5
+++ nm-sun4sol2.h 2000/04/04 02:17:01
@@ -30,3 +30,31 @@
#define PRSVADDR_BROKEN
+#ifdef NEW_PROC_API /* Solaris 6 and above can do HW watchpoints */
+
+#define TARGET_HAS_HARDWARE_WATCHPOINTS
+
+/* The man page for proc4 on solaris 6 and 7 says that the system
+ can support "thousands" of hardware watchpoints, but gives no
+ method for finding out how many. So just tell GDB 'yes'. */
+#define TARGET_CAN_USE_HARDWARE_WATCHPOINT(TYPE, CNT, OT) 1
+
+/* When a hardware watchpoint fires off the PC will be left at the
+ instruction following the one which caused the watchpoint.
+ It will *NOT* be necessary for GDB to step over the watchpoint. */
+#define HAVE_CONTINUABLE_WATCHPOINT
+
+extern int procfs_stopped_by_watchpoint PARAMS ((int));
+#define STOPPED_BY_WATCHPOINT(W) \
+ procfs_stopped_by_watchpoint(inferior_pid)
+
+/* Use these macros for watchpoint insertion/deletion. */
+/* type can be 0: write watch, 1: read watch, 2: access watch (read/write) */
+
+extern int procfs_set_watchpoint PARAMS ((int, CORE_ADDR, int, int, int));
+#define target_insert_watchpoint(ADDR, LEN, TYPE) \
+ procfs_set_watchpoint (inferior_pid, ADDR, LEN, TYPE, 1)
+#define target_remove_watchpoint(ADDR, LEN, TYPE) \
+ procfs_set_watchpoint (inferior_pid, ADDR, 0, 0, 0)
+
+#endif /* NEW_PROC_API */
Index: config/sparc/tm-sun4sol2.h
===================================================================
RCS file: /cvs/src/src/gdb/config/sparc/tm-sun4sol2.h,v
retrieving revision 1.1.1.5
diff -u -r1.1.1.5 tm-sun4sol2.h
--- tm-sun4sol2.h 2000/01/18 00:54:35 1.1.1.5
+++ tm-sun4sol2.h 2000/04/04 02:17:01
@@ -22,6 +22,11 @@
#include "sparc/tm-sparc.h"
#include "tm-sysv4.h"
+/* With Sol2 it is no longer necessary to enable software single-step,
+ since the /proc interface can take care of it for us in hardware. */
+#undef SOFTWARE_SINGLE_STEP
+#undef SOFTWARE_SINGLE_STEP_P
+
/* There are two different signal handler trampolines in Solaris2. */
#define IN_SIGTRAMP(pc, name) \
((name) \
@@ -33,7 +38,7 @@
ucbsigvechandler. */
#define SIGCONTEXT_PC_OFFSET 44
-#if 0 /* FIXME Setjmp/longjmp are not as well doc'd in SunOS 5.x yet */
+#if 0 /* FIXME Setjmp/longjmp are not as well doc'd in SunOS 5.x yet */
/* Offsets into jmp_buf. Not defined by Sun, but at least documented in a
comment in <machine/setjmp.h>! */
@@ -76,6 +81,6 @@
#define HANDLE_SVR4_EXEC_EMULATORS
/* Macros to extract process id and thread id from a composite pid/tid */
-#define PIDGET(pid) ((pid) & 0xffff)
-#define TIDGET(pid) (((pid) >> 16) & 0xffff)
-#define MERGEPID(pid, tid) (((tid) << 16) | (pid))
+#define PIDGET(PID) (((PID) & 0x3ffff))
+#define TIDGET(PID) (((PID) & 0x7fffffff) >> 18)
+#define MERGEPID(PID, TID) (((PID) & 0x3ffff) | ((TID) << 18))
Index: testsuite/gdb.threads/pthreads.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.threads/pthreads.exp,v
retrieving revision 1.1.1.2
diff -u -r1.1.1.2 pthreads.exp
--- pthreads.exp 2000/01/11 03:07:37 1.1.1.2
+++ pthreads.exp 2000/04/04 02:17:01
@@ -113,7 +113,7 @@
# been called 15 times. This should be plenty of time to allow
# every thread to run at least once, since each thread sleeps for
# one second between calls to common_routine.
- gdb_test "tbreak common_routine if hits == 15" ""
+ gdb_test "tbreak common_routine if hits >= 15" ""
# Start all the threads running again and wait for the inferior
# to stop. Since no other breakpoints are set at this time
@@ -135,9 +135,16 @@
# Check that we stopped when we actually expected to stop, by
# verifying that there have been 15 previous hits.
+ # NOTE: Because of synchronization behavior, it is possible for
+ # more than one thread to increment "hits" between one breakpoint
+ # trap and the next. So stopping after 16 or 17 hits should be
+ # considered acceptable.
+
send_gdb "p common_routine::hits\n"
gdb_expect {
-re ".*= 15\r\n$gdb_prompt $" {}
+ -re ".*= 16\r\n$gdb_prompt $" {}
+ -re ".*= 17\r\n$gdb_prompt $" {}
default {
fail "stopped before calling common_routine 15 times"
return 0
From msnyder@cygnus.com Tue Apr 04 18:02:00 2000
From: Michael Snyder <msnyder@cygnus.com>
To: Nick Duffek <nsd@cygnus.com>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: accumulated Solaris/x86 patch
Date: Tue, 04 Apr 2000 18:02:00 -0000
Message-id: <38EA908C.2973@cygnus.com>
References: <200004050059.e350xXg13592@rtl.cygnus.com>
X-SW-Source: 2000-04/msg00084.html
Content-length: 13219
Nick Duffek wrote:
>
> This patch is an accumulation of Solaris/x86 fixes by Michael Snyder, plus
> a fix by me to allow compilation on Solaris 7.
>
> No regressions are evident on i386-pc-solaris2.7, sparc-sun-solaris2.6, or
> sparc-sun-solaris2.5.1.
>
> Comments welcome,
Nick, thanks for doing these.
One comment, I think I later found that using 18 bits for the
process ID and 13 for the thread ID caused problems with
multi-threaded core files. Probably need to add a testsuite.
But go ahead and check it in this way (modulo comments from
others), and if we verify that problem we'll back out that
part of the change.
Michael
> Nick Duffek
> nsd@cygnus.com
>
> [patch follows, excluding regenerated configure script]
>
> Index: configure.in
> ===================================================================
> RCS file: /cvs/src/src/gdb/configure.in,v
> retrieving revision 1.15
> diff -u -r1.15 configure.in
> --- configure.in 2000/04/04 02:08:52 1.15
> +++ configure.in 2000/04/04 02:16:53
> @@ -88,6 +88,14 @@
>
> AC_HEADER_STDC
>
> +dnl Solaris 7 needs _MSE_INT_H defined to avoid a clash between <widec.h>
> +dnl and <wchar.h> that causes AC_CHECK_HEADERS to think <curses.h> doesn't
> +dnl exist.
> +
> +case $host_os in solaris2.7) case "$GCC" in yes)
> + AC_DEFINE(_MSE_INT_H)
> +esac; esac
> +
> AC_CHECK_HEADERS(ctype.h curses.h endian.h link.h thread_db.h proc_service.h \
> memory.h objlist.h ptrace.h sgtty.h stddef.h stdlib.h \
> string.h sys/procfs.h sys/ptrace.h sys/reg.h stdint.h \
> @@ -176,10 +184,7 @@
> *-*-unixware* | *-*-sysv4.2* | *-*-sysv5*)
> AC_DEFINE(NEW_PROC_API)
> ;;
> - # FIXME: we would like to define NEW_PROC_API for all versions of
> - # Solaris from 2.6 on... but it isn't quite working yet. Seems
> - # to work on sparc 2.6, so let's try it out there.
> - sparc-sun-solaris2.6)
> + *-*-solaris2.[678])
> AC_DEFINE(NEW_PROC_API)
> ;;
> esac
> Index: acconfig.h
> ===================================================================
> RCS file: /cvs/src/src/gdb/acconfig.h,v
> retrieving revision 1.3
> diff -u -r1.3 acconfig.h
> --- acconfig.h 2000/03/28 00:03:57 1.3
> +++ acconfig.h 2000/04/04 02:16:53
> @@ -1,3 +1,6 @@
> +/* Define if compiling on Solaris 7. */
> +#undef _MSE_INT_H
> +
> /* Define if pstatus_t type is available */
> #undef HAVE_PSTATUS_T
>
> Index: config.in
> ===================================================================
> RCS file: /cvs/src/src/gdb/config.in,v
> retrieving revision 1.5
> diff -u -r1.5 config.in
> --- config.in 2000/03/28 00:03:57 1.5
> +++ config.in 2000/04/04 02:16:53
> @@ -59,6 +59,9 @@
> /* Define if you have the ANSI C header files. */
> #undef STDC_HEADERS
>
> +/* Define if compiling on Solaris 7. */
> +#undef _MSE_INT_H
> +
> /* Define if you want to use new multi-fd /proc interface
> (replaces HAVE_MULTIPLE_PROC_FDS as well as other macros). */
> #undef NEW_PROC_API
> Index: procfs.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/procfs.c,v
> retrieving revision 1.4
> diff -u -r1.4 procfs.c
> --- procfs.c 2000/03/28 19:02:47 1.4
> +++ procfs.c 2000/04/04 02:16:59
> @@ -5254,3 +5254,20 @@
> else
> return -1;
> }
> +
> +int
> +procfs_get_pid_fd (pid)
> + int pid;
> +{
> + procinfo *pi;
> +
> + if (pid == -1 && inferior_pid != 0)
> + pi = find_procinfo (PIDGET (inferior_pid), 0);
> + else
> + pi = find_procinfo (PIDGET (pid), 0);
> +
> + if (pi)
> + return pi->ctl_fd;
> + else
> + return -1;
> +}
> Index: sol-thread.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/sol-thread.c,v
> retrieving revision 1.3
> diff -u -r1.3 sol-thread.c
> --- sol-thread.c 2000/03/23 21:44:50 1.3
> +++ sol-thread.c 2000/04/04 02:17:01
> @@ -122,14 +122,26 @@
> /* Default definitions: These must be defined in tm.h
> if they are to be shared with a process module such as procfs. */
>
> -#define THREAD_FLAG 0x80000000
> -#define is_thread(ARG) (((ARG) & THREAD_FLAG) != 0)
> -#define is_lwp(ARG) (((ARG) & THREAD_FLAG) == 0)
> -#define GET_LWP(PID) TIDGET (PID)
> -#define GET_THREAD(PID) (((PID) >> 16) & 0x7fff)
> -#define BUILD_LWP(TID, PID) ((TID) << 16 | (PID))
> +#ifndef PIDGET
> +#define PIDGET(PID) (((PID) & 0xffff))
> +#endif
> +
> +#ifndef TIDGET
> +#define TIDGET(PID) (((PID) & 0x7fffffff) >> 16)
> +#endif
> +
> +#ifndef MERGEPID
> +#define MERGEPID(PID, TID) (((PID) & 0xffff) | ((TID) << 16))
> +#endif
> +
> +#define THREAD_FLAG 0x80000000
> +#define is_thread(ARG) (((ARG) & THREAD_FLAG) != 0)
> +#define is_lwp(ARG) (((ARG) & THREAD_FLAG) == 0)
> +#define GET_LWP(PID) TIDGET (PID)
> +#define GET_THREAD(PID) TIDGET (PID)
> +#define BUILD_LWP(TID, PID) MERGEPID (PID, TID)
>
> -#define BUILD_THREAD(THREAD_ID, PID) (THREAD_FLAG | BUILD_LWP (THREAD_ID, PID))
> +#define BUILD_THREAD(TID, PID) (MERGEPID (PID, TID) | THREAD_FLAG)
>
> /* Pointers to routines from lithread_db resolved by dlopen() */
>
> @@ -1327,6 +1339,12 @@
> /* NOTE: only used on Solaris, therefore OK to refer to procfs.c */
> extern struct ssd *procfs_find_LDT_entry (int);
> struct ssd *ret;
> +
> + /* FIXME: can't I get the process ID from the prochandle or something?
> + */
> +
> + if (inferior_pid <= 0 || lwpid <= 0)
> + return PS_BADLID;
>
> ret = procfs_find_LDT_entry (BUILD_LWP (lwpid, PIDGET (inferior_pid)));
> if (ret)
> Index: config/i386/nm-i386sol2.h
> ===================================================================
> RCS file: /cvs/src/src/gdb/config/i386/nm-i386sol2.h,v
> retrieving revision 1.1.1.5
> diff -u -r1.1.1.5 nm-i386sol2.h
> --- nm-i386sol2.h 1999/11/09 01:23:11 1.1.1.5
> +++ nm-i386sol2.h 2000/04/04 02:17:01
> @@ -20,3 +20,31 @@
>
> #include "nm-sysv4.h"
>
> +#ifdef NEW_PROC_API /* Solaris 6 and above can do HW watchpoints */
> +
> +#define TARGET_HAS_HARDWARE_WATCHPOINTS
> +
> +/* The man page for proc4 on solaris 6 and 7 says that the system
> + can support "thousands" of hardware watchpoints, but gives no
> + method for finding out how many. So just tell GDB 'yes'. */
> +#define TARGET_CAN_USE_HARDWARE_WATCHPOINT(TYPE, CNT, OT) 1
> +
> +/* When a hardware watchpoint fires off the PC will be left at the
> + instruction following the one which caused the watchpoint.
> + It will *NOT* be necessary for GDB to step over the watchpoint. */
> +#define HAVE_CONTINUABLE_WATCHPOINT
> +
> +extern int procfs_stopped_by_watchpoint PARAMS ((int));
> +#define STOPPED_BY_WATCHPOINT(W) \
> + procfs_stopped_by_watchpoint(inferior_pid)
> +
> +/* Use these macros for watchpoint insertion/deletion. */
> +/* type can be 0: write watch, 1: read watch, 2: access watch (read/write) */
> +
> +extern int procfs_set_watchpoint PARAMS ((int, CORE_ADDR, int, int, int));
> +#define target_insert_watchpoint(ADDR, LEN, TYPE) \
> + procfs_set_watchpoint (inferior_pid, ADDR, LEN, TYPE, 1)
> +#define target_remove_watchpoint(ADDR, LEN, TYPE) \
> + procfs_set_watchpoint (inferior_pid, ADDR, 0, 0, 0)
> +
> +#endif /* NEW_PROC_API */
> Index: config/i386/tm-i386sol2.h
> ===================================================================
> RCS file: /cvs/src/src/gdb/config/i386/tm-i386sol2.h,v
> retrieving revision 1.2
> diff -u -r1.2 tm-i386sol2.h
> --- tm-i386sol2.h 2000/02/29 13:38:55 1.2
> +++ tm-i386sol2.h 2000/04/04 02:17:01
> @@ -42,9 +42,11 @@
>
> #define FAULTED_USE_SIGINFO
>
> -/* Macros to extract process id and thread id from a composite pid/tid */
> -#define PIDGET(pid) ((pid) & 0xffff)
> -#define TIDGET(pid) (((pid) >> 16) & 0xffff)
> -#define MERGEPID(pid, tid) (((tid) << 16) | (pid))
> +/* Macros to extract process id and thread id from a composite pid/tid.
> + Allocate lower 19 bits for process id, next 12 bits for thread id, and
> + one bit for a flag to indicate a user thread vs. a kernel thread. */
> +#define PIDGET(PID) (((PID) & 0x3ffff))
> +#define TIDGET(PID) (((PID) & 0x7fffffff) >> 18)
> +#define MERGEPID(PID, TID) (((PID) & 0x3ffff) | ((TID) << 18))
>
> #endif /* ifndef TM_I386SOL2_H */
> Index: config/sparc/nm-sun4sol2.h
> ===================================================================
> RCS file: /cvs/src/src/gdb/config/sparc/nm-sun4sol2.h,v
> retrieving revision 1.1.1.5
> diff -u -r1.1.1.5 nm-sun4sol2.h
> --- nm-sun4sol2.h 1999/11/09 01:23:12 1.1.1.5
> +++ nm-sun4sol2.h 2000/04/04 02:17:01
> @@ -30,3 +30,31 @@
>
> #define PRSVADDR_BROKEN
>
> +#ifdef NEW_PROC_API /* Solaris 6 and above can do HW watchpoints */
> +
> +#define TARGET_HAS_HARDWARE_WATCHPOINTS
> +
> +/* The man page for proc4 on solaris 6 and 7 says that the system
> + can support "thousands" of hardware watchpoints, but gives no
> + method for finding out how many. So just tell GDB 'yes'. */
> +#define TARGET_CAN_USE_HARDWARE_WATCHPOINT(TYPE, CNT, OT) 1
> +
> +/* When a hardware watchpoint fires off the PC will be left at the
> + instruction following the one which caused the watchpoint.
> + It will *NOT* be necessary for GDB to step over the watchpoint. */
> +#define HAVE_CONTINUABLE_WATCHPOINT
> +
> +extern int procfs_stopped_by_watchpoint PARAMS ((int));
> +#define STOPPED_BY_WATCHPOINT(W) \
> + procfs_stopped_by_watchpoint(inferior_pid)
> +
> +/* Use these macros for watchpoint insertion/deletion. */
> +/* type can be 0: write watch, 1: read watch, 2: access watch (read/write) */
> +
> +extern int procfs_set_watchpoint PARAMS ((int, CORE_ADDR, int, int, int));
> +#define target_insert_watchpoint(ADDR, LEN, TYPE) \
> + procfs_set_watchpoint (inferior_pid, ADDR, LEN, TYPE, 1)
> +#define target_remove_watchpoint(ADDR, LEN, TYPE) \
> + procfs_set_watchpoint (inferior_pid, ADDR, 0, 0, 0)
> +
> +#endif /* NEW_PROC_API */
> Index: config/sparc/tm-sun4sol2.h
> ===================================================================
> RCS file: /cvs/src/src/gdb/config/sparc/tm-sun4sol2.h,v
> retrieving revision 1.1.1.5
> diff -u -r1.1.1.5 tm-sun4sol2.h
> --- tm-sun4sol2.h 2000/01/18 00:54:35 1.1.1.5
> +++ tm-sun4sol2.h 2000/04/04 02:17:01
> @@ -22,6 +22,11 @@
> #include "sparc/tm-sparc.h"
> #include "tm-sysv4.h"
>
> +/* With Sol2 it is no longer necessary to enable software single-step,
> + since the /proc interface can take care of it for us in hardware. */
> +#undef SOFTWARE_SINGLE_STEP
> +#undef SOFTWARE_SINGLE_STEP_P
> +
> /* There are two different signal handler trampolines in Solaris2. */
> #define IN_SIGTRAMP(pc, name) \
> ((name) \
> @@ -33,7 +38,7 @@
> ucbsigvechandler. */
> #define SIGCONTEXT_PC_OFFSET 44
>
> -#if 0 /* FIXME Setjmp/longjmp are not as well doc'd in SunOS 5.x yet */
> +#if 0 /* FIXME Setjmp/longjmp are not as well doc'd in SunOS 5.x yet */
>
> /* Offsets into jmp_buf. Not defined by Sun, but at least documented in a
> comment in <machine/setjmp.h>! */
> @@ -76,6 +81,6 @@
> #define HANDLE_SVR4_EXEC_EMULATORS
>
> /* Macros to extract process id and thread id from a composite pid/tid */
> -#define PIDGET(pid) ((pid) & 0xffff)
> -#define TIDGET(pid) (((pid) >> 16) & 0xffff)
> -#define MERGEPID(pid, tid) (((tid) << 16) | (pid))
> +#define PIDGET(PID) (((PID) & 0x3ffff))
> +#define TIDGET(PID) (((PID) & 0x7fffffff) >> 18)
> +#define MERGEPID(PID, TID) (((PID) & 0x3ffff) | ((TID) << 18))
> Index: testsuite/gdb.threads/pthreads.exp
> ===================================================================
> RCS file: /cvs/src/src/gdb/testsuite/gdb.threads/pthreads.exp,v
> retrieving revision 1.1.1.2
> diff -u -r1.1.1.2 pthreads.exp
> --- pthreads.exp 2000/01/11 03:07:37 1.1.1.2
> +++ pthreads.exp 2000/04/04 02:17:01
> @@ -113,7 +113,7 @@
> # been called 15 times. This should be plenty of time to allow
> # every thread to run at least once, since each thread sleeps for
> # one second between calls to common_routine.
> - gdb_test "tbreak common_routine if hits == 15" ""
> + gdb_test "tbreak common_routine if hits >= 15" ""
>
> # Start all the threads running again and wait for the inferior
> # to stop. Since no other breakpoints are set at this time
> @@ -135,9 +135,16 @@
> # Check that we stopped when we actually expected to stop, by
> # verifying that there have been 15 previous hits.
>
> + # NOTE: Because of synchronization behavior, it is possible for
> + # more than one thread to increment "hits" between one breakpoint
> + # trap and the next. So stopping after 16 or 17 hits should be
> + # considered acceptable.
> +
> send_gdb "p common_routine::hits\n"
> gdb_expect {
> -re ".*= 15\r\n$gdb_prompt $" {}
> + -re ".*= 16\r\n$gdb_prompt $" {}
> + -re ".*= 17\r\n$gdb_prompt $" {}
> default {
> fail "stopped before calling common_routine 15 times"
> return 0
From meissner@cygnus.com Tue Apr 04 18:03:00 2000
From: Michael Meissner <meissner@cygnus.com>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: BINUTILS Patches <binutils@sourceware.cygnus.com>, GDB Patches <gdb-patches@sourceware.cygnus.com>, newlib@sourceware.cygnus.com
Subject: Re: RFC src/configure* - "CFLAGS=-g -O" instead of "CFLAGS=... -Wall"
Date: Tue, 04 Apr 2000 18:03:00 -0000
Message-id: <20000404210315.45278@cse.cygnus.com>
References: <38EA8086.344CD42A@cygnus.com>
X-SW-Source: 2000-04/msg00085.html
Content-length: 726
On Wed, Apr 05, 2000 at 09:53:42AM +1000, Andrew Cagney wrote:
> Hello,
>
> At present the top level configure + Makefile.in force (when GCC) CFLAGS
> to:
>
> CFLAGS = -g -O -Wall
>
> I'd like to scale that back to just:
>
> CFLAGS = -g -O
>
> letting each sub directory set their own -W* policy. The src/gdb and
> src/sim directories try to do this now using separate WARN_CFLAGS (only
> they get overuled by CFLAGS :-).
Umm, the optimization level by default is -O2, not -O.
--
Michael Meissner, Cygnus Solutions, a Red Hat company.
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work: meissner@redhat.com phone: +1 978-486-9304
Non-work: meissner@spectacle-pond.org fax: +1 978-692-4482
From ian@zembu.com Tue Apr 04 18:06:00 2000
From: Ian Lance Taylor <ian@zembu.com>
To: ac131313@cygnus.com
Cc: binutils@sourceware.cygnus.com, gdb-patches@sourceware.cygnus.com, newlib@sourceware.cygnus.com
Subject: Re: RFC src/configure* - "CFLAGS=-g -O" instead of "CFLAGS=... -Wall"
Date: Tue, 04 Apr 2000 18:06:00 -0000
Message-id: <20000405010550.997.qmail@daffy.airs.com>
References: <38EA8086.344CD42A@cygnus.com> <20000405000414.1640.qmail@daffy.airs.com> <38EA8C15.386D9C40@cygnus.com>
X-SW-Source: 2000-04/msg00086.html
Content-length: 831
Date: Wed, 05 Apr 2000 10:43:01 +1000
From: Andrew Cagney <ac131313@cygnus.com>
> That was a policy I put in for the binutils. It's OK with me to
> change it provided you simultaneously change the binutils
> subdirectories (binutils, bfd, libiberty, opcodes, binutils, gas, ld,
> gprof) to default to -Wall.
How exactly do you want this done? If I add:
CFLAGS=-g -O -Wall
to the sub directory makefiles, that will just get overridden by the top
level (just like GDB suffers today).
I don't particularly care. I just know that I don't want to lose the
default behaviour for the binutils.
What behaviour do you want for gdb?
One way to make this work would be to define WARN_CFLAGS, or something
like that, in the top level Makefile.in, and use it in some
subdirectories but not others.
Ian
From alan@linuxcare.com.au Tue Apr 04 18:32:00 2000
From: Alan Modra <alan@linuxcare.com.au>
To: Ian Lance Taylor <ian@zembu.com>
Cc: ac131313@cygnus.com, binutils@sourceware.cygnus.com, gdb-patches@sourceware.cygnus.com, newlib@sourceware.cygnus.com
Subject: Re: RFC src/configure* - "CFLAGS=-g -O" instead of "CFLAGS=... -Wall"
Date: Tue, 04 Apr 2000 18:32:00 -0000
Message-id: <Pine.LNX.4.21.0004051120170.15948-100000@front.linuxcare.com.au>
References: <20000405010550.997.qmail@daffy.airs.com>
X-SW-Source: 2000-04/msg00087.html
Content-length: 630
On 4 Apr 2000, Ian Lance Taylor wrote:
> One way to make this work would be to define WARN_CFLAGS, or something
> like that, in the top level Makefile.in, and use it in some
> subdirectories but not others.
While you're at it Andrew, it would be nice if WARN_CFLAGS included
-Wno-format when compiling with nls enabled (but not with nls
disabled). With --enable-nls, real warnings are hidden amongst reams of
"warning: format not a string literal, argument types not checked" if you
are using a recent gcc.
I've been meaning for ages to add a little configure magic to do this...
--
Linuxcare. Support for the Revolution.
^ permalink raw reply [flat|nested] 3+ messages in thread