* Re: annotate.texi
2000-04-01 0:00 ` annotate.texi Stan Shebs
@ 2000-03-08 2:03 ` Eli Zaretskii
2000-04-01 0:00 ` annotate.texi Eli Zaretskii
` (2 more replies)
0 siblings, 3 replies; 5+ messages in thread
From: Eli Zaretskii @ 2000-03-08 2:03 UTC (permalink / raw)
To: shebs; +Cc: gdb
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 14848 bytes --]
> > Is there any reason why annotate.texi shouldn't be @include'd by
> > gdb.texinfo and be part of the manual? Right now, "set annotate" is
> > not documented at all, and annotate.texi seems to be just what the
> > doctor ordered...
>
> This is on my long-term wish list for the manual, along with agentexpr
> info.
So, will it be okay to submit a change to gdb.texinfo to include
annotate.texi (and add the appropriate menu items to gdb.texinfo)?
IMHO, no matter how incomplete annotate.texi might be, it is still
MUCH better than not telling anything about this feature.
> > And while at that, NEWS seems to be in the need of some work, it
> > doesn't mention many of the new features that already are in the CVS
> > tree. I would like at least to mention the improvements in the DJGPP
> > version.
>
> Yes please.
Will do.
> But seriously, everybody doing a checkin should ask themselves: will
> users want to know about this change? Usually the answer will be
> yes; users complain about lack of information far more often than
> about overloaded...
The manual is also in dire need of more indexing. I find myself using
(the inefficient) search command too much, instead of (the superb)
index-search. Simple search is painful in a large manual.
I'm trying to add some indexing whenever I can. But I suggest that
every manual patch be scrutinized for appropriate index entries, and
that this policy be published in the guidelines.
From eliz@delorie.com Wed Mar 08 02:09:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: hjl@valinux.com
Cc: gdb@sourceware.cygnus.com
Subject: Re: Problems with hardware watchpoint on ia32.
Date: Wed, 08 Mar 2000 02:09:00 -0000
Message-id: <200003081008.FAA16481@indy.delorie.com>
References: <20000307132401.A20282@valinux.com>
X-SW-Source: 2000-03/msg00130.html
Content-length: 1624
> Starting program: /home/hjl/bugs/gdb/hw/y
> warning: Could not insert hardware watchpoint 1.
> warning: Could not insert hardware watchpoint 3.
> ptrace: Unknown error 4294967295.
> Cannot insert breakpoints.
> The same program may be running in another process.
> (gdb)
>
> ia32 only has 4 hardware debug registers. But gdb shouldn't crash.
I don't see any crashes in the above script. GDB simply didn't start
the process. It is arguable whether it should instead proceed after
inserting only those watchpoints it can, but I agree that it should at
least be a user option.
> Even worse, after deleted one hardware watchpoint, gdb still refused
> to work.
It works for me, but I have patches to do that, which I'm trying for 6
months to get accepted :-(.
Those patches also correct numerous other problems with watchpoints on
x86, which you didn't mention. For example, try setting several
watchpoints (of different types) on the same variable, and see the
mess. Another problem which I corrected is that you cannot watch
struct members, array elements, and bit fields with hardware-assisted
watchpoints.
> (gdb) watch a1
> Watchpoint 1: a1
> (gdb) watch a2
> Watchpoint 2: a2
> (gdb)
>
> gdb won't set hardware watchpoints on long long nor double.
You could look at go32-nat.c, it supports watching any region up to 16
bytes large. (I'm at a loss how come DJGPP needed to invent this: I'd
expect any x86 platform to have this already, since watchpoints are
such an indispensable tool in some circumstances.)
> I will send in a patch in another email.
Please see my response with objections to your patch.
From eliz@delorie.com Wed Mar 08 02:14:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: hjl@valinux.com
Cc: gdb-patches@sourceware.cygnus.com, gdb@sourceware.cygnus.com
Subject: Re: A patch for ia32 hardware watchpoint.
Date: Wed, 08 Mar 2000 02:14:00 -0000
Message-id: <200003081012.FAA16486@indy.delorie.com>
References: <20000307132613.B20282@valinux.com>
X-SW-Source: 2000-03/msg00131.html
Content-length: 3231
> This is a patch for
>
> http://sourceware.cygnus.com/ml/gdb/2000-q1/msg00564.html
I have problems with this patch. See below.
> I only did it for Linux since it is not a perfect solution.
No, you also changed nm-go32.h, which is not related to Linux (AFAIK),
and changed the global definition of two macros on breakpoint.c.
> +#ifdef NEED_WATCHPOINT_NUMBER
> + val = target_insert_watchpoint (b->number, addr,
> + len, type);
> +#else
Please explain why is this needed. The DJGPP version works well
without knowing the breakpoint number, but if there's a good reason
for passing b->number, it should be done on all x86 platforms. So
let's discuss this.
> + /* Don't return an error if we fail to insert
> + a hardware watchpoint due to the limited number
> + of hardware watchpoints availabel. */
> + val = (errno == EBUSY) ? 0 : -1;
> + }
Why is this a good idea? The result of this is that GDB will not know
that it cannot insert a watchpoint until it actually resumes the
debuggee, which is too late in many cases; and the user gets confusing
error messages. x86 doesn't have a good way of checking whether the
debug registers are enough to cover the requests, but whenever it
does, why not use it?
> @@ -5500,13 +5513,13 @@ watch_command_1 (arg, accessflag, from_t
> in hardware return zero. */
>
> #if !defined(TARGET_REGION_SIZE_OK_FOR_HW_WATCHPOINT)
> -#define TARGET_REGION_SIZE_OK_FOR_HW_WATCHPOINT(BYTE_SIZE) \
> - ((BYTE_SIZE) <= (REGISTER_SIZE))
> +#define TARGET_REGION_SIZE_OK_FOR_HW_WATCHPOINT(VAL) \
> + (TYPE_LENGTH (VALUE_TYPE (VAL)) <= (REGISTER_SIZE))
> #endif
>
> #if !defined(TARGET_REGION_OK_FOR_HW_WATCHPOINT)
> -#define TARGET_REGION_OK_FOR_HW_WATCHPOINT(ADDR,LEN) \
> - TARGET_REGION_SIZE_OK_FOR_HW_WATCHPOINT(LEN)
> +#define TARGET_REGION_OK_FOR_HW_WATCHPOINT(VAL) \
> + TARGET_REGION_SIZE_OK_FOR_HW_WATCHPOINT(VAL)
> #endif
These are IMHO wrong: the number of debug registers required for a
particular region is a function of the address, not only size (e.g., a
single x86 debug register cannot watch a 32-bit region that isn't
aligned on 4-byte boundary). If Linux, for some reason, doesn't need
the address (although I cannot see how could this be right, at least
for native debugging), please define a platform-specific macro instead
of overwriting system-wide defaults.
The DJGPP version actually *uses* the ADDR part of the above
definition, since it knows how to cover a region with several
watchpoints.
> --- config/i386/nm-go32.h 2000/03/07 18:42:21 1.1.1.2
> +++ config/i386/nm-go32.h 2000/03/07 18:53:48
> @@ -44,10 +44,10 @@
> #define TARGET_CAN_USE_HARDWARE_WATCHPOINT(type, cnt, ot) 1
>
> /* Returns non-zero if we can use hardware watchpoints to watch a region
> - whose address is ADDR and whose length is LEN. */
> + which represents VAL. */
>
> -#define TARGET_REGION_OK_FOR_HW_WATCHPOINT(addr,len) \
> - go32_region_ok_for_watchpoint(addr,len)
> +#define TARGET_REGION_OK_FOR_HW_WATCHPOINT(val) \
> + go32_region_ok_for_watchpoint((VALUE_ADDRESS (val) + VALUE_OFFSET (val)),TYPE_LENGTH (VALUE_TYPE (val)))
Please do not commit this one, it disables a valuable feature in the
DJGPP version.
From eliz@delorie.com Wed Mar 08 03:32:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: hjl@valinux.com
Cc: gdb-patches@sourceware.cygnus.com, gdb@sourceware.cygnus.com
Subject: Re: A patch for ia32 hardware watchpoint.
Date: Wed, 08 Mar 2000 03:32:00 -0000
Message-id: <200003081132.GAA16847@indy.delorie.com>
References: <20000307132613.B20282@valinux.com>
X-SW-Source: 2000-03/msg00132.html
Content-length: 1455
> > @@ -5500,13 +5513,13 @@ watch_command_1 (arg, accessflag, from_t
> > in hardware return zero. */
> >
> > #if !defined(TARGET_REGION_SIZE_OK_FOR_HW_WATCHPOINT)
> > -#define TARGET_REGION_SIZE_OK_FOR_HW_WATCHPOINT(BYTE_SIZE) \
> > - ((BYTE_SIZE) <= (REGISTER_SIZE))
> > +#define TARGET_REGION_SIZE_OK_FOR_HW_WATCHPOINT(VAL) \
> > + (TYPE_LENGTH (VALUE_TYPE (VAL)) <= (REGISTER_SIZE))
> > #endif
> >
> > #if !defined(TARGET_REGION_OK_FOR_HW_WATCHPOINT)
> > -#define TARGET_REGION_OK_FOR_HW_WATCHPOINT(ADDR,LEN) \
> > - TARGET_REGION_SIZE_OK_FOR_HW_WATCHPOINT(LEN)
> > +#define TARGET_REGION_OK_FOR_HW_WATCHPOINT(VAL) \
> > + TARGET_REGION_SIZE_OK_FOR_HW_WATCHPOINT(VAL)
> > #endif
>
> These are IMHO wrong: the number of debug registers required for a
> particular region is a function of the address, not only size (e.g., a
> single x86 debug register cannot watch a 32-bit region that isn't
> aligned on 4-byte boundary). If Linux, for some reason, doesn't need
> the address (although I cannot see how could this be right, at least
> for native debugging), please define a platform-specific macro instead
> of overwriting system-wide defaults.
Sorry, I talked too soon. These changes supply all the required info,
since they pass the entire struct value to the macro. So they are
okay with me.
I'm terribly sorry for jumping the gun for no reason.
The rest of my comments about these patches are still valid, though.
From sharathibm@theglobe.com Wed Mar 08 05:38:00 2000
From: "Sharath Kumar" <sharathibm@theglobe.com>
To: gdb@sourceware.cygnus.com
Subject: target_read_memory for breakpoints
Date: Wed, 08 Mar 2000 05:38:00 -0000
Message-id: <GAMLDEKNADAJKAAA@theglobe.com>
X-SW-Source: 2000-03/msg00133.html
Content-length: 552
Hi
I was just trying to find how breakpoints are set/hit..and i came across this function - 'target_read_memory' which calls
'target_xfer_memory' which inturn calls - "current_target.to_xfer_memory".
I am not able to proceed after this.. I actually want to know the implementation of "hitting of the breakpoint" and then
"continuing after the breakpoint". (for intel pentium arch.)
Do you have any suggesstions?
regards,
Sharath.
theglobe.com
Your friendly full-service integrated online community.
http://www.theglobe.com
From johan.rydberg@netinsight.se Wed Mar 08 05:59:00 2000
From: Johan Rydberg <johan.rydberg@netinsight.se>
To: gdb@sourceware.cygnus.com
Subject: problem with register display
Date: Wed, 08 Mar 2000 05:59:00 -0000
Message-id: <38C6691D.C3F05223@netinsight.se>
X-SW-Source: 2000-03/msg00134.html
Content-length: 665
Hi!
I'm developing a "gdb-simulator" for a CPU, and it seems to
work pretty good. But I have some questions. When I try to
display the registers it says everyone except the link register
is unavailable. Why this? It also fetches the PC register, but
it also says it's unavailable.
And, how do I from gdb call the `sim_info´ function? Right
now I have implemented a "sim info" command, but since it's
defined in the simulator interface I guess that there's a
better way to do this.
--
Johan Rydberg johan.rydberg@netinsight.net
Net Insight AB, Sweden direct: +46-8-685 04 17
http://www.netinsight.net phone: +46-8-685 04 00
fax: +46-8-685 04 20
From kingdon@redhat.com Wed Mar 08 06:04:00 2000
From: Jim Kingdon <kingdon@redhat.com>
To: gdb@sourceware.cygnus.com
Subject: Re: A patch for ia32 hardware watchpoint.
Date: Wed, 08 Mar 2000 06:04:00 -0000
Message-id: <bsny1fths.fsf@rtl.cygnus.com>
References: <200003080845.AAA18410@alabama.wrs.com>
X-SW-Source: 2000-03/msg00135.html
Content-length: 1547
> Yeah. This is about as bad as crunching target events through unix
> signals, something that only ever made sense on ptrace() targets
> which couldn't do any better. "But the code lives on"
Always amusing to hear people talking about my designs :-) (also see
comment in target.h at enum target_signal).
The deep question is whether you want GDB to canonicalize things. I
do see some value in getting (for example) a SEGV when you access
memory which is not mapped by the MMU (if you have one) across all
targets. Both for users and for scripts.
If you answer pro-canonical, then the right solution is to add
additional fields (most native platforms have arch-dependent signal
codes, for example, and GDB could be taught to pass them along or
generate them for stubs and such). I think that ptrace() targets
could get at the signal codes but not necessarily in a clean way
(wait4 and friends don't seem to return them).
If you answer anti-canonical, then you want functions in the target
vector to do things like report stop status to the user.
The two approaches aren't mutually exclusive, actually, we probably
want both a canonicalized status and a way to get more specific
information in a free-form way.
The situation might be analogous for errno, although errno is such a
poor fit for things which happen to targets (e.g. "address out of
range" maps to EIO. Bletch), that I kind of doubt it is worth the
bother to do the canonicalization thing. Unless perhaps if we wanted
to come up with a GDB-specific canonical set of errors.
From kingdon@redhat.com Wed Mar 08 06:12:00 2000
From: Jim Kingdon <kingdon@redhat.com>
To: Eli Zaretskii <eliz@is.elta.co.il>
Cc: gdb@sourceware.cygnus.com
Subject: Re: annotate.texi
Date: Wed, 08 Mar 2000 06:12:00 -0000
Message-id: <br9dlft4v.fsf@rtl.cygnus.com>
References: <200003070832.DAA14451@indy.delorie.com> <38C55BEE.D8E6F7BE@apple.com> <200003081003.FAA16478@indy.delorie.com>
X-SW-Source: 2000-03/msg00136.html
Content-length: 488
> I'm trying to add some indexing whenever I can. But I suggest that
> every manual patch be scrutinized for appropriate index entries
Sounds like the voice of someone volunteering to do some scrutinization ;-).
Believe me, "people sending in lots of manual patches which never get
merged" just hasn't been a problem on any free software project I've
worked on. Having Stan as the documentation maintainer is a good
thing too, because we are willing to hurt him if he slacks off :-).
From eliz@delorie.com Wed Mar 08 06:23:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: Jim Kingdon <kingdon@redhat.com>
Cc: gdb@sourceware.cygnus.com, shebs@apple.com
Subject: Re: annotate.texi
Date: Wed, 08 Mar 2000 06:23:00 -0000
Message-id: <200003081422.JAA17698@indy.delorie.com>
References: <br9dlft4v.fsf@rtl.cygnus.com> <200003070832.DAA14451@indy.delorie.com> <38C55BEE.D8E6F7BE@apple.com> <200003081003.FAA16478@indy.delorie.com>
X-SW-Source: 2000-03/msg00137.html
Content-length: 677
Jim Kingdon writes:
> > I'm trying to add some indexing whenever I can. But I suggest that
> > every manual patch be scrutinized for appropriate index entries
>
> Sounds like the voice of someone volunteering to do some scrutinization ;-).
If that's what it takes to make this happen, then yes, I do volunteer.
But I do request that this be declared as an official policy, so that
individual contributors could be requested to add the index entries,
if the manual changes are large.
Adding an index entry to a typical manual patch is really a small
nuisance. It's only when you need to add them all at once to a large
manual, only then the job becomes too large to bear.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: annotate.texi
2000-03-08 2:03 ` annotate.texi Eli Zaretskii
@ 2000-04-01 0:00 ` Eli Zaretskii
2000-04-01 0:00 ` annotate.texi Jim Kingdon
2000-04-01 0:00 ` annotate.texi Eli Zaretskii
2 siblings, 0 replies; 5+ messages in thread
From: Eli Zaretskii @ 2000-04-01 0:00 UTC (permalink / raw)
To: shebs; +Cc: gdb
> > Is there any reason why annotate.texi shouldn't be @include'd by
> > gdb.texinfo and be part of the manual? Right now, "set annotate" is
> > not documented at all, and annotate.texi seems to be just what the
> > doctor ordered...
>
> This is on my long-term wish list for the manual, along with agentexpr
> info.
So, will it be okay to submit a change to gdb.texinfo to include
annotate.texi (and add the appropriate menu items to gdb.texinfo)?
IMHO, no matter how incomplete annotate.texi might be, it is still
MUCH better than not telling anything about this feature.
> > And while at that, NEWS seems to be in the need of some work, it
> > doesn't mention many of the new features that already are in the CVS
> > tree. I would like at least to mention the improvements in the DJGPP
> > version.
>
> Yes please.
Will do.
> But seriously, everybody doing a checkin should ask themselves: will
> users want to know about this change? Usually the answer will be
> yes; users complain about lack of information far more often than
> about overloaded...
The manual is also in dire need of more indexing. I find myself using
(the inefficient) search command too much, instead of (the superb)
index-search. Simple search is painful in a large manual.
I'm trying to add some indexing whenever I can. But I suggest that
every manual patch be scrutinized for appropriate index entries, and
that this policy be published in the guidelines.
From dan@cgsoftware.com Sat Apr 01 00:00:00 2000
From: dan@cgsoftware.com (Daniel Berlin+list.gdb-patches)
To: Jimmy Guo <guo@cup.hp.com>
Cc: "Daniel Berlin+list.gdb-patches" <dan@cgsoftware.com>, gdb@sourceware.cygnus.com, gcc@gcc.gnu.org
Subject: Re: C++ Overload testsuite fixes, need someone to verify
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <r9d1570b.fsf@dan.resnet.rochester.edu>
References: <Pine.LNX.4.10.10003232107500.12214-100000@hpcll168.cup.hp.com>
X-SW-Source: 2000-q1/msg00790.html
Content-length: 3446
Jimmy Guo <guo@cup.hp.com> writes:
It is a debug info problem.
GNU gdb 20000204
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-unknown-freebsdelf4.0".
(gdb) file testsuite/gdb.c++/ovldbreak
Reading symbols from testsuite/gdb.c++/ovldbreak...done.
(gdb) b main
Breakpoint 1 at 0x804882f: file ./gdb.c++/ovldbreak.cc, line 48.
(gdb) bash-2.03#
bash-2.03# g++ -v
Using builtin specs.
gcc version 2.95.2 19991024 (release)
That's with STABS (or dwarf1, i forget the default, might be dwarf1).
bash-2.03# ./gdb -nw a.out
GNU gdb 20000204
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-unknown-freebsdelf4.0"...
Setting up the environment for debugging gdb.
.gdbinit:5: Error in sourced command file:
Function "internal_error" not defined.
(gdb) b main
During symbol reading, type qualifier 'const' ignored.
Breakpoint 1 at 0x804883c: file testsuite/gdb.c++/ovldbreak.cc, line 49.
(gdb)
That's with DWARF2.
Can someone please grant me the sage wisdom about what to do about
this?
Modify the regexp to accept 48/49, or just pout in the corner and
live with the testsuite failures for now?
--Dan
> Might be. I just checked sourceware 3/21's gdb built for
> hppa1.1-hp-hpux10.20, with ovldbreak.cc compiled by GNUPro g++, and it
> reports breakpoint on main at line 49. This seem to point to the
> compiler rather than the debugger that you are using.
>
> - Jimmy Guo, guo@cup.hp.com
>
> >Jimmy Guo <guo@cup.hp.com> writes:
> >
> >the "{" is on line 48, the first line of the code ("char arg1") is at
> >49.
> >I smell a debugging info issue, where your compiler says it starts at
> >49, and mine says 48.
> >I think the real solution is to accept 48 and 49, but say anything
> >else is wrong.
> >Or fix gcc, if it's broken.
> >Something is telling me i remember seeing something about this problem
> >in gcc recently, something about where it's saying the first line of a
> >functions starts.
> >Can any of the GCC guys tell me if i'm making this up in my head (I
> >believe it was related to where it put the note about the function
> >start or something like that)?
> >--Dan
> >> >Can someone verify, that i am correct in thinking you get unexpected
> >> >failures in gdb.c++/ovldbreak.exp due to "breakpoint info" failures?
> >> >I have a patch, i just want to make sure it's not me.
> >> >It appears the source line the test suite expects main to appear on
> >> >in that file is 49, and main really appears at 48, so the regex to
> >> >match doesn't work. I diffed the ovldbreak.cc file, and i get no
> >> >differences.
> >>
> >> I think it should report 49, not 48. Line 49 is the first executable
> >> statement of main. I'm using the HP WDB source, in case you cannot see
> >> such behavior with sourceware's (in that case I will spend some time
> >> digging up the fix to submit as a patch).
> >>
> >> - Jimmy Guo
From muller@cerbere.u-strasbg.fr Sat Apr 01 00:00:00 2000
From: Pierre Muller <muller@cerbere.u-strasbg.fr>
To: Mark Kettenis <kettenis@wins.uva.nl>
Cc: gdb@sourceware.cygnus.com
Subject: Re: Pascal language support patch preparation
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200003021613.RAA03663@cerbere.u-strasbg.fr>
References: <200003021432.PAA01976@cerbere.u-strasbg.fr> <200003021347.OAA01051@cerbere.u-strasbg.fr> <200003021257.NAA00259@cerbere.u-strasbg.fr>
X-SW-Source: 2000-q1/msg00509.html
Content-length: 3955
At 16:02 02/03/00 +0100, you wrote:
> Date: Thu, 02 Mar 2000 15:16:19 +0100
> From: Pierre Muller <muller@cerbere.u-strasbg.fr>
>
> >Patches to create those new p-* files cannot be broken up of course,
> >but your patch also touches a lot of the other GDB files. Breaking
> >those patches up in smaller though functionally related chunks makes
> >reviewing and applying the patches a lot easier.
> >
> >I'd advise you to do the following:
> >
> >1. If you need some tweaks in GDB that do not depend on the Pascal
> > support itself, start submitting these ASAP.
>
> I don't think I really have such code !
>
>Are you sure? The patch I downloaded last fall includes changes to
>breakpoint.c, findvar.c, i387-tdep.c, infcmd.c and source.c that seem
>to be pretty independent of Pascal at first glance.
Most are obsolete now !
> >2. Then send the new p-* as one single patch.
>
> Alone ? tihs would just leave them unused first !
>
>That's not a problem. The point is that these changes cannot break
>anything, so they don't need a lot of attention.
>
> >3. Then send a patch that adds the code to hook in the GDB support.
>
> OK, here a would have the biggest part of the problems probably
> because some of the change are not trivial but I agree that I can probably
> splitt those.
>
>That would indeed be best, since that lets the maintainer of that
>particular part of GDB deal with problems one at a time, which in
>general gets the changes integrated much quicker.
>
This reminds me that I have one other patch which is quite smaller but
that is limited to DJGPP target for now.
It allows to read memory from another selector
this was very usefull for me when I tried to debug the debugger itself and
when I added exception support fro GDB on DJGPP !
This patch consists of the addition of one command that I called "xx"
which is a simple clone of the "x" command but can take a selector
as for intance
"xx $fs:0x400"
then the next "xx 0x800" keeps using the last selector value.
I do not know if this could be interesting for other i386 targets
(maybe for win32 to be able to see the content of the $fs selector
that contains the exception chain, but I am not sure how if its
readable inside a win32 API program).
Is such kind of patch too specific to have any chance to get accepted ?
I don't know if it could be of any use for other processors!!
> For instance a big problem on which I spent a lot of time is to
> get GDB to accept the fact the pascal is case insensitive
> this required changes in gnu-regex code !!
>
>I'm sorry to hear that you spent a lot of time on it. Modifying the
>regex code is something that we should only do as a last resort since
>it is shared with a lot of other GNU packages. Maybe GDB should use
>the POSIX functions instead of the BSD functions such that REG_ICASE
>can be used when the default language is Pascal.
I would also prefer a simpler approach because that code
is quite ugly in my opinion!
>On the bright side: Case insensitivity would be convenient, but should
>not be essential for basic Pascal support in GDB. We should be able
>to address this as a seperate issue. I'll see what I can do. For now
>it is probably better to leave out this bit when you send your new
>patches.
Anyhow I agree that this can and should be done later.
> >Yes it is, but it isn't the version that was used for reformatting the
> >GDB sources. See:
> >
> > http://sourceware.cygnus.com/ml/gdb/1999-q3/msg00014.html
>
> This not really very informative on the method that was used to do it !
>
>Pardon me? It clearly states that: ``[Stan] used indent 1.9.1 (with
>no arguments)''.
Sorry, I didn't read the message carefully enough it seems :(
Pierre Muller
Institut Charles Sadron
6,rue Boussingault
F 67083 STRASBOURG CEDEX (France)
mailto:muller@ics.u-strasbg.fr
Phone : (33)-3-88-41-40-07 Fax : (33)-3-88-41-40-99
From dan@cgsoftware.com Sat Apr 01 00:00:00 2000
From: Daniel Berlin <dan@cgsoftware.com>
To: khendricks@ivey.uwo.ca
Cc: dan@cgsoftware.com, gdb@sourceware.cygnus.com
Subject: Re: Preparing for the GDB 5.0 / GDB 2000 / GDB2k release
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <ya8vapt7.fsf@dan.resnet.rochester.edu>
References: <950048577_PM_BeOS.dan@cgsoftware.com> <00020823060800.00592@localhost.localdomain>
X-SW-Source: 2000-q1/msg00187.html
Content-length: 4592
Kevin Hendricks <khendricks@ivey.uwo.ca> writes:
> Hi,
>
> > What you are really saying is that it's better to put hacks and crap in
> > the tree, and hope someone comes along and does it right, removing the
> > hack, while making it even more a living hell for everyone else to
> > understand.
>
> Why is eveything "not perfect" considered a hack or crap? I for one don't
> think Kevin Buettner's patch is a hack or crap at all. Please stop equating
> what we want to see added with crap.
We must have our wires crossed.
I wasn't referring to Kevin's patch when i said crap. Sorry for the
misunderstanding.
>
> > See, here is your fatal mistake.
> > You are making the assumption that users will clean it up, make it work,
> > and improve it.
> > While this may be true in other projects, it's not really true in GDB's
> > case.
>
> I think your attitude here is just wrong (and frankly part of the whole gdb
> problem). You obviously think you have cornered the market on some unique
> programming skill.
No, I've just had the unfortunate experience of seeming to be the only
one who hacks on gdb for my platform (notice i said nothing about
using, there are plenty of users), among with many other experiences,
and most of the people i know share these experiences (with their own
particular projects, mainly driver authors).
> This is simply not true. Users can and will help. I would
> help (I was part of Blackdown's jdk porting team until recent events forced me
> to move on), Franz would help (he is *the* gcc person for ppc and without his
> work with them we (ppc) would still be in the dark ages, Gary Thomas would help
> (he is really the father of the whole linux ppc movement and is single handedly
> responsible for much of the code that ppc uses), etc. We just need something
> to start playing with. As it stands, we can't even submit official bug
> reports.
>
> Please stop thinking that gdb is so complex that only a maintainer can help
> (seen the inside of many multi-threaded virtual machines latesly?).
Strangely enough, I have, having done the original port of kaffe (No
WAT) to BeOS before the person who did it now. Not as hairy as sun's,
i would imagine (I've never looked at their code).
It seems only the maintainers want to help (ppc-linux people like you
excluded, sorry if i put you in the wrong platform group, it's late :P)
> Sure we
> won't be as good as you, we won't be as productive as you, but we (and others)
> really can help. I think we are proof of that. Unfortunately when I submitted
> the original ppc patch (based on Kevin Buettner work) back around 4.16 or
> earlier, I just never dreamed it would take this long to get anything there
> done with it.
>
> Perhaps cygnus plays too large a role in tool development. Perhaps open source
> tools should not be tied so closely to any one company. Too many conflicts of
> interest? Too many paying customers versus the rest of us? I just don't know.
>
> But whatever the outcome, please stop assuming that all "users" are
idiots.
Never said that, never would.
Believe me, i'd be more than happy to be proven wrong, and to have
tons of users submit patches for all areas of GDB.
I'm just not holding my breath waiting for it to happen, no matter
what we do.
Yet I'm always hoping users will help.
But i guess i've just been involved in projects lately where they
don't. Fer instance, I've recently turned over maintenance of two drivers i wrote (both for
sound cards on BeOS.) because i simply don't have the time, and the
only reports i get are "this doesn't work on my computer", and when i
try to follow up, get nothing. It's not for lack of users, either. The
download stats show when i release a new version, it gets downloaded
~5000 times (Goes up a little with each release, new users i assume).
None were willing to help in any way, shape or form.
Well, you get the idea, no point in me rambling on.
> This is simply not the case and results in much of the bad or negative
> "mindset" I have seen in the gdb lists and tried to point out to Stan.
Like i said, unfortunately, my viewpoint comes from too many
experiences lately telling me it's true. I'd be glad to be wrong about
this.
>
> Thanks for responding to my post.
And thank you for responding to mine.
> I am not sure we will ever agree on how
> things should be done but we are talking about it which is more than has been
> done of late.
Right.
Hopefully this email won't get too screwed by my new mailer (And
hopefully i have all my gnus settings right)
>
> Take care,
>
> Kevin
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: annotate.texi
[not found] <200003070832.DAA14451@indy.delorie.com>
@ 2000-04-01 0:00 ` Stan Shebs
2000-03-08 2:03 ` annotate.texi Eli Zaretskii
0 siblings, 1 reply; 5+ messages in thread
From: Stan Shebs @ 2000-04-01 0:00 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: gdb
Eli Zaretskii wrote:
>
> Is there any reason why annotate.texi shouldn't be @include'd by
> gdb.texinfo and be part of the manual? Right now, "set annotate" is
> not documented at all, and annotate.texi seems to be just what the
> doctor ordered...
This is on my long-term wish list for the manual, along with agentexpr
info. My guiding principle is that the manual should document
everything that a user can do with GDB, so it should include information
about builtin protocols, such as annotation, remote debug, and MI.
Conversely, the internals manual is for anything that involves looking
at GDB's source code.
> And while at that, NEWS seems to be in the need of some work, it
> doesn't mention many of the new features that already are in the CVS
> tree. I would like at least to mention the improvements in the DJGPP
> version.
Yes please. To paraphrase the esteemed Dr Wirtiglieben, when speaking
of the Doomsday Device:
VUT GOOD IS IT IF NOBODY KNOWS ABOUT IT!!??
:-)
But seriously, everybody doing a checkin should ask themselves: will
users want to know about this change? Usually the answer will be
yes; users complain about lack of information far more often than
about overloaded...
Stan
From kettenis@wins.uva.nl Sat Apr 01 00:00:00 2000
From: Mark Kettenis <kettenis@wins.uva.nl>
To: ac131313@cygnus.com
Cc: agold@bga.com, gdb@sourceware.cygnus.com
Subject: Re: gdb does not `break' when using LD_PRELOAD
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200002171430.e1HEUt801735@delius.kettenis.local>
References: <388F30C2.B6795E21@bga.com> <38ABB665.CFA09B56@cygnus.com>
X-SW-Source: 2000-q1/msg00328.html
Content-length: 1006
Date: Thu, 17 Feb 2000 19:50:45 +1100
From: Andrew Cagney <ac131313@cygnus.com>
"Arthur H. Gold" wrote:
>
> gdb list:
>
> Since upgrading to glibc-2.1.2, I've been having a problem with gdb--
> specifically in regard to its use with LD_PRELOAD. The problem is that
> when running with a preloaded library (either from the shell or set
> within gdb) gdb fails to respect any breakpoints I set (though the
> breakpoints themselves seem to be set successfully).
>
> I understand there are problems with 4.18; I have, however, started
> to run 4.17-14 (HJ Lu's patched version)--but to no avail.
>
> Any input would be more than welcome
Has anyone looked at this, or got any suggestions/comments?
AFAICT setting breakpoints in preloaded libraries seems to work fine
on i586-pc-linux-gnu with a glibc-2.1.3 snapshot. Setting breakpoints
works and they are properly triggered.
Arthur, can you provide a small test-case, that shows your problems?
Mark
From jsm@cygnus.com Sat Apr 01 00:00:00 2000
From: Jason Molenda <jsm@cygnus.com>
To: Jimmy Guo <guo@cup.hp.com>
Cc: gdb@sourceware.cygnus.com, gdb-testers@sourceware.cygnus.com
Subject: Re: Problems with the new GDB repository source
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <20000207195157.C28795@cygnus.com>
References: <20000206224315.A25084@cygnus.com> <Pine.LNX.4.10.10002071726160.12722-100000@hpcll168.cup.hp.com> <20000207194817.A28795@cygnus.com>
X-SW-Source: 2000-q1/msg00155.html
Content-length: 635
On Mon, Feb 07, 2000 at 07:48:17PM -0800, Jason Molenda wrote:
> At some point in the future (I have no idea when), someone will merge the
> sourceware binutils repo with the Cygnus binutils repo and the changes
> that had been happening within Cygnus will get out there.
Incidentally, I should add that few changes are actually done to libiberty
on the internal Cygnus repo any more. My guess is that these changes
were in GCC (I think GCC is defined as the master set of sources for
libiberty?), were merged from the GCC repo into the Cygnus internal repo,
but haven't yet been merged in to the binutils sourceware repo.
Jason
From toddpw@windriver.com Sat Apr 01 00:00:00 2000
From: Todd Whitesel <toddpw@windriver.com>
To: gdb@sourceware.cygnus.com (GDB Developers)
Subject: symfile.c:symfile_bfd_open()
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200003241351.FAA06850@alabama.wrs.com>
X-SW-Source: 2000-q1/msg00795.html
Content-length: 819
While merging up to 4.18 (as a stepping stone to devo), I noticed
something that we're doing locally here which seems generally useful
for cross developing folks.
symfile.c:symfile_bfd_open() opens objects/executables using BFD.
It tells openp() to search the $PATH, which is obviously handy for
native, but seems to make no sense whatsoever for cross development.
Our local patch is to add a second argument to symfile_bfd_open,
"use_source_path", which ends up being set to 1 nearly all of the
time, since with our targets we are always cross developing. In
that case, we have openp() search source_path instead of getenv("PATH").
Does the multi-arch stuff provide a clean test for native vs. cross?
That'd be a better decision-maker than the "use_source_path" argument.
--
Todd Whitesel
toddpw @ windriver.com
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Kevin Buettner <kevinb@cygnus.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: Patches for GNU/Linux PPC native now in CVS
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38B1FF0B.F9F0A939@cygnus.com>
References: <1000222025201.ZM9805@ocotillo.lan>
X-SW-Source: 2000-q1/msg00366.html
Content-length: 134
Kevin Buettner wrote:
> [....]
Kevin,
I'd suggest also putting a brief announcement on gdb-announce at
sourceware.
(Cool!).
Andrew
From jimb@zwingli.cygnus.com Sat Apr 01 00:00:00 2000
From: Jim Blandy <jimb@zwingli.cygnus.com>
To: Eli Zaretskii <eliz@is.elta.co.il>
Cc: Jim Blandy <jimb@cygnus.com>, hjl@lucon.org, gdb@sourceware.cygnus.com, gdb-patches@sourceware.cygnus.com
Subject: Re: Problems with hardware watchpoint on ia32.
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <npbt4040t3.fsf@zwingli.cygnus.com>
References: <20000307132401.A20282@valinux.com> <200003081008.FAA16481@indy.delorie.com> <20000308084304.A3150@lucon.org> <200003091210.HAA19857@indy.delorie.com> <npya7c6zn7.fsf@zwingli.cygnus.com> <200003221806.NAA14225@indy.delorie.com>
X-SW-Source: 2000-q1/msg00819.html
Content-length: 608
> I seem to be unable to reproduce the problem, at least in a C program:
> whenever I say "watch foo == bar" (where foo and bar are structs), GDB
> curses thusly:
>
> Structure has no component named operator==.
>
> Am I missing something?
As Michael points out, structure comparison is broken. But that
doesn't change my original point --- that it's perfectly legitimate to
have `struct value' objects representing structures, which should be
watched in their entirety.
The type of a value is irrelevant --- we're trying to track the memory
references made in the course of evaluating the expression.
From kingdon@redhat.com Sat Apr 01 00:00:00 2000
From: Jim Kingdon <kingdon@redhat.com>
To: gdb@sourceware.cygnus.com
Subject: Re: gdbstubs library posted at sourceforge
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200001291645.LAA19052@devserv.devel.redhat.com>
References: <200001271910.OAA04242@devserv.devel.redhat.com>
X-SW-Source: 2000-q1/msg00073.html
Content-length: 1956
> * I don't want someone turning gdbstubs itself into a closed source
> product
Well, my own personal perspective is that the #1 thing which prevents
this is an active community which is developing the open product. If
someone can avoid all the engineering costs of doing their own closed
fork, and get a much better result, they often will. If the open
version has stagnated, then they are kind of stuck with doing their
own version.
So I think putting it on sourceforge is the key thing which will
encourage people to contribute to gdbstubs, not the license (in the
past, noone had a suitable process for accepting submissions to the
stubs).
> (particularly the tracepoint stuff, when it arrives)
Ah, I see, scars from the proprietary tracepoint stubs. The story
here is that Red Hat is committed to open source and much of the code
which was closed source pre-merger will be opened. However, I have no
idea how that applies to tracepoint stubs (there are a lot of
programs/products to sort through and look at both business and
technical sides, and I wouldn't be surprised if tracepoints are a pawn
in a larger game and/or lost in the shuffle :-)).
You could argue that Cygnus's past actions disprove this, but I'd
argue that there just isn't much economic value in proprietary stubs,
and thus little risk/likelihood that we'll see a lot of proprietary
stubs. When Red Hat files their financials for the first quarter
combined with Cygnus (late March) you'll see actual numbers (at least,
I think so, I guess I don't know for sure exactly how they will break
it down).
> Maybe CEPL is a closer fit for what I'm after, because it accomplishes
> everything the LGPL does *and* eliminates the need for .o's? I could
> go there.
I would think CEPL/Mozilla works better than LGPL, yes (the CEPL is
basically the same license as the Mozilla license for those who don't
know - see http://sourceware.cygnus.com/ecos/ and
http://www.mozilla.org/ ).
From tromey@cygnus.com Sat Apr 01 00:00:00 2000
From: Tom Tromey <tromey@cygnus.com>
To: gdb@sourceware.cygnus.com
Subject: Re: Patch: Remove 'Dave' error message.
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <874sba1arg.fsf@cygnus.com>
References: <200002150059.QAA02943@elmo.cygnus.com> <20000214171818.A15790@cygnus.com>
X-SW-Source: 2000-q1/msg00300.html
Content-length: 359
Jason> I think his patch was quietly ignored because it reduces the
Jason> humor value of gdb. gdb is a boring program and we need all
Jason> the humor I can get.
Jason> I agree that it is not very helpful for foreigners to have
Jason> things like this in there, sigh.
If gdb used GNU gettext we could replace it with a locale-specific joke.
Tom
From blizzard@redhat.com Sat Apr 01 00:00:00 2000
From: Chris Blizzard <blizzard@redhat.com>
To: gdb@sourceware.cygnus.com
Subject: Re: problems with gdb
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38AB2DC4.FA9A3C71@redhat.com>
References: <38A47E89.3F4674B3@mozilla.org> <npael3tqk6.fsf@zwingli.cygnus.com>
X-SW-Source: 2000-q1/msg00313.html
Content-length: 1986
So, one of the problems that I've been having is that some large .so libraries
take forever to load. One of the libraries is about 28 meg with debugging
symbols in it. I've let it run for about 10 mins and it's never finished
loading. Here's what gprof says for loading a reasonable sized library ( 5
meg or so ):
Flat profile:
Each sample counts as 0.01 seconds.
% cumulative self self total
time seconds seconds calls ms/call ms/call name
70.98 19.47 19.47 11954 1.63 2.25 lookup_minimal_symbol
27.12 26.91 7.44 33240213 0.00 0.00 strcmp_iw
0.33 27.00 0.09 3 30.00 9038.95 read_dbx_symtab
0.15 27.04 0.04 44554 0.00 0.00 hash
0.11 27.07 0.03 337915 0.00 0.00 bfd_getl32
0.11 27.10 0.03 44554 0.00 0.00 bcache
0.11 27.13 0.03 150 0.20 0.20 end_psymtab
Uhh...that's 33 _million_ calls. That looks like this chunk of code:
for (objfile = object_files;
objfile != NULL && found_symbol == NULL;
objfile = objfile->next)
{
if (objf == NULL || objf == objfile)
{
for (msymbol = objfile->msymbols;
msymbol != NULL && SYMBOL_NAME (msymbol) != NULL &&
found_symbol == NULL;
msymbol++)
{
if (SYMBOL_MATCHES_NAME (msymbol, name))
{
switch (MSYMBOL_TYPE (msymbol))
{
case mst_file_text:
I'm sorry, is that looking over a linked list? SYMBOL_MATCHES_NAME() is a
macro that does some mangling magic so we can't use a standard hash lookup
table but there has to be something we can do to speed that up.
--Chris
--
------------
Christopher Blizzard
http://people.redhat.com/blizzard/
A few years back, I saw a young child stuck in a tree. Nowadays,
when I find myself in a troubling situation, I look back and wonder
if that kid saw me take that chocolate bar from his backpack on
the ground.
------------
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Mark Kettenis <kettenis@wins.uva.nl>
Cc: aj@suse.de, gdb@sourceware.cygnus.com
Subject: Re: core dump from GNU/Linux <sys/procfs.h>; Was: Build failure on Linux/i686
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38A7DA9C.F82221C9@cygnus.com>
References: <u8d7q4j4df.fsf@gromit.rhein-neckar.de> <200002101919.UAA23595@landau.wins.uva.nl> <38A353C3.DDD9A240@cygnus.com> <200002110736.e1B7afa00398@delius.kettenis.local>
X-SW-Source: 2000-q1/msg00261.html
Content-length: 1284
Mark Kettenis wrote:
>
> Date: Fri, 11 Feb 2000 11:11:47 +1100
> From: Andrew Cagney <ac131313@cygnus.com>
>
> Mark Kettenis wrote:
>
> > This is the solution I proposed:
> >
> > http://sourceware.cygnus.com/ml/gdb-patches/2000-q1/msg00103.html
> >
> > Note that you'll need to patch <sys/procfs.h> too, otherwise GDB will
> > segfault when you try to debug a multithreaded app!
>
> Um, can you expand on this a little? (You may have already).
>
> The first version of glibc that includes the threads debugging library
> (libthread.so) will be 2.1.3, which has not been officially released
> yet. Since both Andreas and I are glibc developers we were among the
> first to test a GDB that makes use of that functionality apart from
> the people who actually implemented it. It looks as if Ulrich Drepper
> (the glibc maintainer) and Michael have let things go slighty out of
> sync. So without patches to both GDB and the glibc prereleases it
> won't work.
>
> If there is a header file found in a standard GNU/Linux distribution
> that can cause GDB to dump core we're going to need some sort of evasive
> action. Sigh.
>
> That's what I'm trying to prevent :-)
Ok. That sounds like the best that can be done. Thanks!
Andrew
From france@crl.dec.com Sat Apr 01 00:00:00 2000
From: George France <france@crl.dec.com>
To: "'Xavier Bestel'" <xbestel@aplio.fr>, gdb@sourceware.cygnus.com
Subject: RE: single-step
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <D1674834F25BD3118B3208002BB90CD424AAC9@yen.crl.dec.com>
X-SW-Source: 2000-q1/msg00448.html
Content-type: multipart/mixed; boundary="----------=_1583534244-23286-7"
This is a multi-part message in MIME format...
------------=_1583534244-23286-7
Content-length: 1102
Hello Xavier;
Which ARM dev board do you have?? I have attached a patch for ptrace.c for
Linux 2.2.14 that will allow you to single step on the armv4l architecture.
The patch implements PTRACE_GETREGS, PTRACE_SETREGS, PTRACE_GETFPREGS &
PTRACE_SETREGS, with PTRACE_SET_BPT etc....
Best Regards,
--George
George France, france@crl.dec.com
Cambridge Research Laboratory, Compaq Computer Corporation
One Kendall Square, Building 700 MS: CRL
Cambridge, MA 02139 USA
-----Original Message-----
From: Xavier Bestel [ mailto:xbestel@aplio.fr ]
Sent: Monday, February 28, 2000 9:44 AM
To: gdb@sourceware.cygnus.com
Subject: single-step
Hi !
I have and ARM dev board hooked to a Jeeni, controlled via ethernet. It
doesn't singl-step, it only stops at breakpoints. When I issue a "info
target", gdb replies that "Target can't single-step".
However I would greatly appreciate it to single step to debug my apps ...
So do you know how to fix it ? Is it a hardware non-feature or a simple
software misconfiguration ? Can gdb emulate singlestepping transparently
using breakpoints ?
Xav
------------=_1583534244-23286-7
Content-Type: text/x-diff; charset=us-ascii; name="ptrace-for-2.2.14-patch"
Content-Disposition: inline; filename="ptrace-for-2.2.14-patch"
Content-Transfer-Encoding: base64
Content-Length: 18780
LS0tIC9za2lmZi9qYW1leS9saW51eC0yLjIuMTQtcm1rMy1jcmwxL2luY2x1
ZGUvYXNtLWFybS9wdHJhY2UuaAlUdWUgSmFuIDE4IDE4OjEzOjA5IDIwMDAK
KysrIC91c3Ivc3JjL2xpbnV4L2luY2x1ZGUvYXNtLWFybS9wdHJhY2UuaAlX
ZWQgSmFuIDI2IDAxOjIxOjM3IDIwMDAKQEAgLTMsNiArMywxMyBAQAogCiAj
aW5jbHVkZSA8YXNtL3Byb2MvcHRyYWNlLmg+CiAKKworI2RlZmluZSBQVFJB
Q0VfR0VUUkVHUwkJMTIKKyNkZWZpbmUgUFRSQUNFX1NFVFJFR1MJCTEzCisj
ZGVmaW5lIFBUUkFDRV9HRVRGUFJFR1MJMTQKKyNkZWZpbmUgUFRSQUNFX1NF
VEZQUkVHUwkxNQorCisKICNpZmRlZiBfX0tFUk5FTF9fCiBleHRlcm4gdm9p
ZCBzaG93X3JlZ3Moc3RydWN0IHB0X3JlZ3MgKik7CiAjZW5kaWYKLS0tIC9z
a2lmZi9qYW1leS9saW51eC0yLjIuMTQtcm1rMy1jcmwxL2luY2x1ZGUvYXNt
LWFybS9wcm9jZXNzb3IuaAlUdWUgSmFuIDE4IDE4OjEzOjA5IDIwMDAKKysr
IC91c3Ivc3JjL2xpbnV4L2luY2x1ZGUvYXNtLWFybS9wcm9jZXNzb3IuaAlX
ZWQgSmFuIDI2IDAxOjIxOjUxIDIwMDAKQEAgLTMyLDEyICszMiwyMCBAQAog
I2luY2x1ZGUgPGFzbS9hcmNoL3Byb2Nlc3Nvci5oPgogI2luY2x1ZGUgPGFz
bS9wcm9jL3Byb2Nlc3Nvci5oPgogCitzdHJ1Y3QgZGVidWdfaW5mbyB7CisJ
aW50CQkJCW5zYXZlZDsKKwlzdHJ1Y3QgeworCQl1bnNpZ25lZCBsb25nCQlh
ZGRyZXNzOworCQl1bnNpZ25lZCBsb25nCQlpbnNuOworCX0gYnBbMl07Cit9
OworCiBzdHJ1Y3QgdGhyZWFkX3N0cnVjdCB7CiAJdW5zaWduZWQgbG9uZwkJ
CWFkZHJlc3M7CSAgLyogQWRkcmVzcyBvZiBmYXVsdAkqLwogCXVuc2lnbmVk
IGxvbmcJCQl0cmFwX25vOwkgIC8qIFRyYXAgbnVtYmVyCSovCiAJdW5zaWdu
ZWQgbG9uZwkJCWVycm9yX2NvZGU7CSAgLyogRXJyb3IgY29kZSBvZiB0cmFw
CSovCiAJdW5pb24gZnBfc3RhdGUJCQlmcHN0YXRlOwkgIC8qIEZQRSBzYXZl
IHN0YXRlCSovCi0JdW5zaWduZWQgbG9uZwkJCWRlYnVnW05SX0RFQlVHU107
IC8qIERlYnVnL3B0cmFjZQkqLworCXN0cnVjdCBkZWJ1Z19pbmZvCQlkZWJ1
ZzsgICAgICAgICAgICAvKiBEZWJ1Zy9wdHJhY2UJKi8KIAlzdHJ1Y3QgY29u
dGV4dF9zYXZlX3N0cnVjdAkqc2F2ZTsJCSAgLyogY29udGV4dCBzYXZlCSov
CiAJdW5zaWduZWQgbG9uZwkJCW1lbW1hcDsJCSAgLyogcGFnZSB0YWJsZXMJ
Ki8KIAlFWFRSQV9USFJFQURfU1RSVUNUCi0tLSAvc2tpZmYvamFtZXkvbGlu
dXgtMi4yLjE0LXJtazMtY3JsMS9hcmNoL2FybS9rZXJuZWwvcHRyYWNlLmMJ
VHVlIEphbiAxOCAxODowNjoxMyAyMDAwCisrKyAvdXNyL3NyYy9saW51eC9h
cmNoL2FybS9rZXJuZWwvcHRyYWNlLmMJV2VkIEphbiAyNiAwMToyMTozOCAy
MDAwCkBAIC0xMiwxMCArMTIsMTMgQEAKICNpbmNsdWRlIDxsaW51eC9wdHJh
Y2UuaD4KICNpbmNsdWRlIDxsaW51eC91c2VyLmg+CiAKKwogI2luY2x1ZGUg
PGFzbS91YWNjZXNzLmg+CiAjaW5jbHVkZSA8YXNtL3BndGFibGUuaD4KICNp
bmNsdWRlIDxhc20vc3lzdGVtLmg+CiAKKworCiAvKgogICogZG9lcyBub3Qg
eWV0IGNhdGNoIHNpZ25hbHMgc2VudCB3aGVuIHRoZSBjaGlsZCBkaWVzLgog
ICogaW4gZXhpdC5jIG9yIGluIHNpZ25hbC5jLgpAQCAtMjYsMzcgKzI5LDkg
QEAKICAqLwogI2RlZmluZSBCUkVBS0lOU1QJMHhlZjlmMDAwMQogCi0vKgot
ICogdGhpcyByb3V0aW5lIHdpbGwgZ2V0IGEgd29yZCBvZmYgb2YgdGhlIHBy
b2Nlc3NlcyBwcml2aWxlZ2VkIHN0YWNrLgotICogdGhlIG9mZnNldCBpcyBo
b3cgZmFyIGZyb20gdGhlIGJhc2UgYWRkciBhcyBzdG9yZWQgaW4gdGhlIFRT
Uy4KLSAqIHRoaXMgcm91dGluZSBhc3N1bWVzIHRoYXQgYWxsIHRoZSBwcml2
aWxlZ2VkIHN0YWNrcyBhcmUgaW4gb3VyCi0gKiBkYXRhIHNwYWNlLgotICov
Ci1zdGF0aWMgaW5saW5lIGxvbmcgZ2V0X3N0YWNrX2xvbmcoc3RydWN0IHRh
c2tfc3RydWN0ICp0YXNrLCBpbnQgb2Zmc2V0KQotewotCXVuc2lnbmVkIGNo
YXIgKnN0YWNrOwogCi0Jc3RhY2sgPSAodW5zaWduZWQgY2hhciAqKSgodW5z
aWduZWQgbG9uZyl0YXNrICsgODE5MiAtIHNpemVvZihzdHJ1Y3QgcHRfcmVn
cykpOwotCXN0YWNrICs9IG9mZnNldCA8PCAyOwotCXJldHVybiAqKHVuc2ln
bmVkIGxvbmcgKilzdGFjazsKLX0KIAotLyoKLSAqIHRoaXMgcm91dGluZSB3
aWxsIHB1dCBhIHdvcmQgb24gdGhlIHByb2Nlc3NlcyBwcml2aWxlZ2VkIHN0
YWNrLgotICogdGhlIG9mZnNldCBpcyBob3cgZmFyIGZyb20gdGhlIGJhc2Ug
YWRkciBhcyBzdG9yZWQgaW4gdGhlIFRTUy4KLSAqIHRoaXMgcm91dGluZSBh
c3N1bWVzIHRoYXQgYWxsIHRoZSBwcml2aWxlZ2VkIHN0YWNrcyBhcmUgaW4g
b3VyCi0gKiBkYXRhIHNwYWNlLgotICovCi1zdGF0aWMgaW5saW5lIGxvbmcg
cHV0X3N0YWNrX2xvbmcoc3RydWN0IHRhc2tfc3RydWN0ICp0YXNrLCBpbnQg
b2Zmc2V0LAotCXVuc2lnbmVkIGxvbmcgZGF0YSkKLXsKLQl1bnNpZ25lZCBj
aGFyICpzdGFjazsKIAotCXN0YWNrID0gKHVuc2lnbmVkIGNoYXIgKikoKHVu
c2lnbmVkIGxvbmcpdGFzayArIDgxOTIgLSBzaXplb2Yoc3RydWN0IHB0X3Jl
Z3MpKTsKLQlzdGFjayArPSBvZmZzZXQgPDwgMjsKLQkqKHVuc2lnbmVkIGxv
bmcgKikgc3RhY2sgPSBkYXRhOwotCXJldHVybiAwOwotfQogCiAvKgogICog
VGhpcyByb3V0aW5lIGdldHMgYSBsb25nIGZyb20gYW55IHByb2Nlc3Mgc3Bh
Y2UgYnkgZm9sbG93aW5nIHRoZSBwYWdlCkBAIC0xNzMsNiArMTQ4LDcgQEAK
IAkJZm9yY2Vfc2lnKFNJR0tJTEwsIHRzayk7CiB9CiAKKwogc3RhdGljIHN0
cnVjdCB2bV9hcmVhX3N0cnVjdCAqIGZpbmRfZXh0ZW5kX3ZtYShzdHJ1Y3Qg
dGFza19zdHJ1Y3QgKiB0c2ssIHVuc2lnbmVkIGxvbmcgYWRkcikKIHsKIAlz
dHJ1Y3Qgdm1fYXJlYV9zdHJ1Y3QgKiB2bWE7CkBAIC0xOTIsNiArMTY4LDQy
IEBACiAJcmV0dXJuIHZtYTsKIH0KIAorCisKKy8qCisgKiB0aGlzIHJvdXRp
bmUgd2lsbCBnZXQgYSB3b3JkIG9mZiBvZiB0aGUgcHJvY2Vzc2VzIHByaXZp
bGVnZWQgc3RhY2suCisgKiB0aGUgb2Zmc2V0IGlzIGhvdyBmYXIgZnJvbSB0
aGUgYmFzZSBhZGRyIGFzIHN0b3JlZCBpbiB0aGUgVEhSRUFELgorICogdGhp
cyByb3V0aW5lIGFzc3VtZXMgdGhhdCBhbGwgdGhlIHByaXZpbGVnZWQgc3Rh
Y2tzIGFyZSBpbiBvdXIKKyAqIGRhdGEgc3BhY2UuCisgKi8KK3N0YXRpYyBp
bmxpbmUgbG9uZyBnZXRfc3RhY2tfbG9uZyhzdHJ1Y3QgdGFza19zdHJ1Y3Qg
KnRhc2ssIGludCBvZmZzZXQpCit7CisJc3RydWN0IHB0X3JlZ3MgKnJlZ3M7
CisKKwlyZWdzID0gKHN0cnVjdCBwdF9yZWdzICopKCh1bnNpZ25lZCBsb25n
KXRhc2sgKyA4MTkyIC0gc2l6ZW9mKHN0cnVjdCBwdF9yZWdzKSk7CisKKwly
ZXR1cm4gcmVncy0+dXJlZ3Nbb2Zmc2V0XTsKK30KKworLyoKKyAqIHRoaXMg
cm91dGluZSB3aWxsIHB1dCBhIHdvcmQgb24gdGhlIHByb2Nlc3NlcyBwcml2
aWxlZ2VkIHN0YWNrLgorICogdGhlIG9mZnNldCBpcyBob3cgZmFyIGZyb20g
dGhlIGJhc2UgYWRkciBhcyBzdG9yZWQgaW4gdGhlIFRIUkVBRC4KKyAqIHRo
aXMgcm91dGluZSBhc3N1bWVzIHRoYXQgYWxsIHRoZSBwcml2aWxlZ2VkIHN0
YWNrcyBhcmUgaW4gb3VyCisgKiBkYXRhIHNwYWNlLgorICovCitzdGF0aWMg
aW5saW5lIGxvbmcgcHV0X3N0YWNrX2xvbmcoc3RydWN0IHRhc2tfc3RydWN0
ICp0YXNrLCBpbnQgb2Zmc2V0LAorCXVuc2lnbmVkIGxvbmcgZGF0YSkKK3sK
KwlzdHJ1Y3QgcHRfcmVncyAqcmVnczsKKworCXJlZ3MgPSAoc3RydWN0IHB0
X3JlZ3MgKikoKHVuc2lnbmVkIGxvbmcpdGFzayArIDgxOTIgLSBzaXplb2Yo
c3RydWN0IHB0X3JlZ3MpKTsKKworCXJlZ3MtPnVyZWdzW29mZnNldF0gPSBk
YXRhOworCisJcmV0dXJuIDA7Cit9CisKKwogLyoKICAqIFRoaXMgcm91dGlu
ZSBjaGVja3MgdGhlIHBhZ2UgYm91bmRhcmllcywgYW5kIHRoYXQgdGhlIG9m
ZnNldCBpcwogICogd2l0aGluIHRoZSB0YXNrIGFyZWEuIEl0IHRoZW4gY2Fs
bHMgZ2V0X2xvbmcoKSB0byByZWFkIGEgbG9uZy4KQEAgLTI4Niw2ICsyOTgs
OCBAQAogCXJldHVybiAwOwogfQogCisKKwogLyoKICAqIEdldCB2YWx1ZSBv
ZiByZWdpc3RlciBgcm4nIChpbiB0aGUgaW5zdHJ1Y3Rpb24pCiAgKi8KQEAg
LTI5OSw3ICszMTMsNiBAQAogCWVsc2UKIAkJdmFsID0gZ2V0X3N0YWNrX2xv
bmcgKGNoaWxkLCByZWcpOwogCi1wcmludGsgKCJyJTAyZD0lMDhsWCAiLCBy
ZWcsIHZhbCk7CiAJcmV0dXJuIHZhbDsKIH0KIApAQCAtMzEyLDEyICszMjUs
MTAgQEAKIAlpbnQgc2hpZnQ7CiAJaW50IHR5cGU7CiAKLXByaW50ayAoIm9w
Mj0iKTsKIAlpZiAoaW5zbiAmIDEgPDwgMjUpIHsKIAkJdmFsID0gaW5zbiAm
IDI1NTsKIAkJc2hpZnQgPSAoaW5zbiA+PiA4KSAmIDE1OwogCQl0eXBlID0g
MzsKLXByaW50ayAoIihpbW0pIik7CiAJfSBlbHNlIHsKIAkJdmFsID0gZ2V0
X3N0YWNrX2xvbmcgKGNoaWxkLCBpbnNuICYgMTUpOwogCkBAIC0zMjcsOSAr
MzM4LDcgQEAKIAkJCXNoaWZ0ID0gKGluc24gPj4gNykgJiAzMTsKIAogCQl0
eXBlID0gKGluc24gPj4gNSkgJiAzOwotcHJpbnRrICgiKHIlMDJsZCkiLCBp
bnNuICYgMTUpOwogCX0KLXByaW50ayAoInNoJWR4JWQiLCB0eXBlLCBzaGlm
dCk7CiAJc3dpdGNoICh0eXBlKSB7CiAJY2FzZSAwOgl2YWwgPDw9IHNoaWZ0
OwlicmVhazsKIAljYXNlIDE6CXZhbCA+Pj0gc2hpZnQ7CWJyZWFrOwpAQCAt
MzM3LDEwICszNDYsOSBAQAogCQl2YWwgPSAoKChzaWduZWQgbG9uZyl2YWwp
ID4+IHNoaWZ0KTsKIAkJYnJlYWs7CiAJY2FzZSAzOgotCQlfX2FzbV9fIF9f
dm9sYXRpbGVfXygibW92ICUwLCAlMCwgcm9yICUxIiA6ICI9ciIgKHZhbCkg
OiAiMCIgKHZhbCksICJyIiAoc2hpZnQpKTsKKyAJCXZhbCA9ICh2YWwgPj4g
c2hpZnQpIHwgKHZhbCA8PCAoMzIgLSBzaGlmdCkpOwogCQlicmVhazsKIAl9
Ci1wcmludGsgKCI9JTA4bFggIiwgdmFsKTsKIAlyZXR1cm4gdmFsOwogfQog
CkBAIC0zNTcsNyArMzY1LDYgQEAKIAlzaGlmdCA9IChpbnNuID4+IDcpICYg
MzE7CiAJdHlwZSA9IChpbnNuID4+IDUpICYgMzsKIAotcHJpbnRrICgib3Ay
PXIlMDJsZHNoJWR4JWQiLCBpbnNuICYgMTUsIHNoaWZ0LCB0eXBlKTsKIAlz
d2l0Y2ggKHR5cGUpIHsKIAljYXNlIDA6CXZhbCA8PD0gc2hpZnQ7CWJyZWFr
OwogCWNhc2UgMToJdmFsID4+PSBzaGlmdDsJYnJlYWs7CkBAIC0zNjUsMzMg
KzM3MiwyMiBAQAogCQl2YWwgPSAoKChzaWduZWQgbG9uZyl2YWwpID4+IHNo
aWZ0KTsKIAkJYnJlYWs7CiAJY2FzZSAzOgotCQlfX2FzbV9fIF9fdm9sYXRp
bGVfXygibW92ICUwLCAlMCwgcm9yICUxIiA6ICI9ciIgKHZhbCkgOiAiMCIg
KHZhbCksICJyIiAoc2hpZnQpKTsKKyAJCXZhbCA9ICh2YWwgPj4gc2hpZnQp
IHwgKHZhbCA8PCAoMzIgLSBzaGlmdCkpOwogCQlicmVhazsKIAl9Ci1wcmlu
dGsgKCI9JTA4bFggIiwgdmFsKTsKIAlyZXR1cm4gdmFsOwogfQotI3VuZGVm
IHBjX3BvaW50ZXIKLSNkZWZpbmUgcGNfcG9pbnRlcih4KSAoKHgpICYgMHgw
M2ZmZmZmYykKLWludCBwdHJhY2Vfc2V0X2JwdCAoc3RydWN0IHRhc2tfc3Ry
dWN0ICpjaGlsZCkKLXsKLQl1bnNpZ25lZCBsb25nIGluc24sIHBjLCBhbHQ7
Ci0JaW50IGksIG5zYXZlZCA9IDAsIHJlczsKLQotCXBjID0gcGNfcG9pbnRl
ciAoZ2V0X3N0YWNrX2xvbmcgKGNoaWxkLCAxNS8qUkVHX1BDKi8pKTsKIAot
CXJlcyA9IHJlYWRfbG9uZyAoY2hpbGQsIHBjLCAmaW5zbik7Ci0JaWYgKHJl
cyA8IDApCi0JCXJldHVybiByZXM7CitzdGF0aWMgdW5zaWduZWQgbG9uZwor
Z2V0X2JyYW5jaF9hZGRyZXNzKHN0cnVjdCB0YXNrX3N0cnVjdCAqY2hpbGQs
IHVuc2lnbmVkIGxvbmcgcGMsIHVuc2lnbmVkIGxvbmcgaW5zbikKK3sKKwl1
bnNpZ25lZCBsb25nIGFsdCA9IDA7CiAKLQljaGlsZC0+dHNzLmRlYnVnW25z
YXZlZCsrXSA9IGFsdCA9IHBjICsgNDsKLXByaW50ayAoInB0cmFjZV9zZXRf
YnB0OiBpbnNuPSUwOGxYIHBjPSUwOGxYICIsIGluc24sIHBjKTsKIAlzd2l0
Y2ggKGluc24gJiAweDBlMTAwMDAwKSB7CiAJY2FzZSAweDAwMDAwMDAwOgog
CWNhc2UgMHgwMDEwMDAwMDoKIAljYXNlIDB4MDIwMDAwMDA6CiAJY2FzZSAw
eDAyMTAwMDAwOiAvKiBkYXRhIHByb2Nlc3NpbmcgKi8KLQkJcHJpbnRrICgi
ZGF0YSAiKTsKIAkJc3dpdGNoIChpbnNuICYgMHgwMWUwZjAwMCkgewogCQlj
YXNlIDB4MDAwMGYwMDA6CiAJCQlhbHQgPSBwdHJhY2VfZ2V0cm4oY2hpbGQs
IGluc24pICYgcHRyYWNlX2dldGFsdW9wMihjaGlsZCwgaW5zbik7CkBAIC00
MzUsOSArNDMxLDggQEAKIAkJfQogCQlicmVhazsKIAotCWNhc2UgMHgwNDEw
MDAwMDogLyogbGRyICovCisJY2FzZSAweDA2MTAwMDAwOiAvKiBsZHIgKi8K
IAkJaWYgKChpbnNuICYgMHhmMDAwKSA9PSAweGYwMDApIHsKLXByaW50ayAo
ImxkciAiKTsKIAkJCWFsdCA9IHB0cmFjZV9nZXRybihjaGlsZCwgaW5zbik7
CiAJCQlpZiAoaW5zbiAmIDEgPDwgMjQpIHsKIAkJCQlpZiAoaW5zbiAmIDEg
PDwgMjMpCkBAIC00NDYsMTUgKzQ0MSwxNCBAQAogCQkJCQlhbHQgLT0gcHRy
YWNlX2dldGxkcm9wMiAoY2hpbGQsIGluc24pOwogCQkJfQogCQkJaWYgKHJl
YWRfbG9uZyAoY2hpbGQsIGFsdCwgJmFsdCkgPCAwKQotCQkJCWFsdCA9IHBj
ICsgNDsgLyogbm90IHZhbGlkICovCisJCQkJYWx0ID0gMDsgLyogbm90IHZh
bGlkICovCiAJCQllbHNlCiAJCQkJYWx0ID0gcGNfcG9pbnRlciAoYWx0KTsK
IAkJfQogCQlicmVhazsKIAotCWNhc2UgMHgwNjEwMDAwMDogLyogbGRyIGlt
bSAqLworCWNhc2UgMHgwNDEwMDAwMDogLyogbGRyIGltbSAqLwogCQlpZiAo
KGluc24gJiAweGYwMDApID09IDB4ZjAwMCkgewotcHJpbnRrICgibGRyaW1t
ICIpOwogCQkJYWx0ID0gcHRyYWNlX2dldHJuKGNoaWxkLCBpbnNuKTsKIAkJ
CWlmIChpbnNuICYgMSA8PCAyNCkgewogCQkJCWlmIChpbnNuICYgMSA8PCAy
MykKQEAgLTQ2Myw3ICs0NTcsNyBAQAogCQkJCQlhbHQgLT0gaW5zbiAmIDB4
ZmZmOwogCQkJfQogCQkJaWYgKHJlYWRfbG9uZyAoY2hpbGQsIGFsdCwgJmFs
dCkgPCAwKQotCQkJCWFsdCA9IHBjICsgNDsgLyogbm90IHZhbGlkICovCisJ
CQkJYWx0ID0gMDsgLyogbm90IHZhbGlkICovCiAJCQllbHNlCiAJCQkJYWx0
ID0gcGNfcG9pbnRlciAoYWx0KTsKIAkJfQpAQCAtNDczLDcgKzQ2Nyw2IEBA
CiAJCWlmIChpbnNuICYgKDEgPDwgMTUpKSB7CiAJCQl1bnNpZ25lZCBsb25n
IGJhc2U7CiAJCQlpbnQgbnJfcmVnczsKLXByaW50ayAoImxkbSAiKTsKIAog
CQkJaWYgKGluc24gJiAoMSA8PCAyMykpIHsKIAkJCQlucl9yZWdzID0gaW5z
biAmIDY1NTM1OwpAQCAtNDk2LDcgKzQ4OSw3IEBACiAJCQliYXNlID0gcHRy
YWNlX2dldHJuIChjaGlsZCwgaW5zbik7CiAKIAkJCWlmIChyZWFkX2xvbmcg
KGNoaWxkLCBiYXNlICsgbnJfcmVncywgJmFsdCkgPCAwKQotCQkJCWFsdCA9
IHBjICsgNDsgLyogbm90IHZhbGlkICovCisJCQkJYWx0ID0gMDsgLyogbm90
IHZhbGlkICovCiAJCQllbHNlCiAJCQkJYWx0ID0gcGNfcG9pbnRlciAoYWx0
KTsKIAkJCWJyZWFrOwpAQCAtNTA2LDcgKzQ5OSw2IEBACiAJY2FzZSAweDBh
MDAwMDAwOgogCWNhc2UgMHgwYTEwMDAwMDogeyAvKiBibCBvciBiICovCiAJ
CXNpZ25lZCBsb25nIGRpc3BsOwotcHJpbnRrICgiYi9ibCAiKTsKIAkJLyog
SXQncyBhIGJyYW5jaC9icmFuY2ggbGluazogaW5zdGVhZCBvZiB0cnlpbmcg
dG8KIAkJICogZmlndXJlIG91dCB3aGV0aGVyIHRoZSBicmFuY2ggd2lsbCBi
ZSB0YWtlbiBvciBub3QsCiAJCSAqIHdlJ2xsIHB1dCBhIGJyZWFrcG9pbnQg
YXQgZWl0aGVyIGxvY2F0aW9uLiAgVGhpcyBpcwpAQCAtNTIxLDQxICs1MTMs
OTcgQEAKIAkgICAgfQogCSAgICBicmVhazsKIAl9Ci1wcmludGsgKCI9JTA4
bFhcbiIsIGFsdCk7Ci0JaWYgKGFsdCAhPSBwYyArIDQpCi0JCWNoaWxkLT50
c3MuZGVidWdbbnNhdmVkKytdID0gYWx0OwogCi0JZm9yIChpID0gMDsgaSA8
IG5zYXZlZDsgaSsrKSB7Ci0JCXJlcyA9IHJlYWRfbG9uZyAoY2hpbGQsIGNo
aWxkLT50c3MuZGVidWdbaV0sICZpbnNuKTsKLQkJaWYgKHJlcyA+PSAwKSB7
Ci0JCQljaGlsZC0+dHNzLmRlYnVnW2kgKyAyXSA9IGluc247Ci0JCQlyZXMg
PSB3cml0ZV9sb25nIChjaGlsZCwgY2hpbGQtPnRzcy5kZWJ1Z1tpXSwgQlJF
QUtJTlNUKTsKKwlyZXR1cm4gYWx0OwogCQl9Ci0JCWlmIChyZXMgPCAwKSB7
Ci0JCQljaGlsZC0+dHNzLmRlYnVnWzRdID0gMDsKKworc3RhdGljIGludAor
YWRkX2JyZWFrcG9pbnQoc3RydWN0IHRhc2tfc3RydWN0ICpjaGlsZCwgc3Ry
dWN0IGRlYnVnX2luZm8gKmRiZywgdW5zaWduZWQgbG9uZyBhZGRyKQorewor
CWludCBuciA9IGRiZy0+bnNhdmVkOworCWludCByZXMgPSAtRUlOVkFMOwor
CisJaWYgKG5yIDwgMikgeworCQlyZXMgPSByZWFkX2xvbmcoY2hpbGQsIGFk
ZHIsICZkYmctPmJwW25yXS5pbnNuKTsKKwkJaWYgKHJlcyA9PSAwKQorCQkJ
cmVzID0gd3JpdGVfbG9uZyhjaGlsZCwgYWRkciwgQlJFQUtJTlNUKTsKKwor
CQlpZiAocmVzID09IDApIHsKKwkJCWRiZy0+YnBbbnJdLmFkZHJlc3MgPSBh
ZGRyOworCQkJZGJnLT5uc2F2ZWQgKz0gMTsKKwkJfQorCX0gZWxzZQorCQlw
cmludGsoS0VSTl9ERUJVRyAiYWRkX2JyZWFrcG9pbnQ6IHRvbyBtYW55IGJy
ZWFrcG9pbnRzXG4iKTsKKwogCQkJcmV0dXJuIHJlczsKIAkJfQorCisjZGVm
aW5lIHByZWRpY2F0ZSh4KQkoeCAmIDB4ZjAwMDAwMDApCisKK2ludCBwdHJh
Y2Vfc2V0X2JwdCAoc3RydWN0IHRhc2tfc3RydWN0ICpjaGlsZCkKK3sKKwlz
dHJ1Y3QgZGVidWdfaW5mbyAqZGJnID0gJmNoaWxkLT50c3MuZGVidWc7CisJ
dW5zaWduZWQgbG9uZyBpbnNuLCBwYywgYWx0OworCWludCByZXM7CisKKwlw
YyA9IHBjX3BvaW50ZXIgKGdldF9zdGFja19sb25nIChjaGlsZCwgMTUvKlJF
R19QQyovKSk7CisKKwlyZXMgPSByZWFkX2xvbmcoY2hpbGQsIHBjLCAmaW5z
bik7CisJaWYgKHJlcyA+PSAwKSB7CisJCXJlcyA9IDA7CisKKwkJZGJnLT5u
c2F2ZWQgPSAwOworCisJCWFsdCA9IGdldF9icmFuY2hfYWRkcmVzcyhjaGls
ZCwgcGMsIGluc24pOworCQlpZiAoYWx0KQorCQkJcmVzID0gYWRkX2JyZWFr
cG9pbnQoY2hpbGQsIGRiZywgYWx0KTsKKworCQlpZiAoIXJlcyAmJiAoIWFs
dCB8fCAocHJlZGljYXRlKGluc24pICE9IDB4ZTAwMDAwMDApKSkKKwkJCXJl
cyA9IGFkZF9icmVha3BvaW50KGNoaWxkLCBkYmcsIHBjICsgNCk7CiAJfQot
CWNoaWxkLT50c3MuZGVidWdbNF0gPSBuc2F2ZWQ7Ci0JcmV0dXJuIDA7CisK
KwlyZXR1cm4gcmVzOwogfQogCi0vKiBFbnN1cmUgbm8gc2luZ2xlLXN0ZXAg
YnJlYWtwb2ludCBpcyBwZW5kaW5nLiAgUmV0dXJucyBub24temVybwotICog
dmFsdWUgaWYgY2hpbGQgd2FzIGJlaW5nIHNpbmdsZS1zdGVwcGVkLgorLyog
RW5zdXJlIG5vIHNpbmdsZS1zdGVwIGJyZWFrcG9pbnQgaXMgcGVuZGluZy4K
ICAqLwotaW50IHB0cmFjZV9jYW5jZWxfYnB0IChzdHJ1Y3QgdGFza19zdHJ1
Y3QgKmNoaWxkKQordm9pZCBwdHJhY2VfZG9fY2FuY2VsX2JwdCAoc3RydWN0
IHRhc2tfc3RydWN0ICpjaGlsZCkKIHsKLQlpbnQgaSwgbnNhdmVkID0gY2hp
bGQtPnRzcy5kZWJ1Z1s0XTsKKwlzdHJ1Y3QgZGVidWdfaW5mbyAqZGJnID0g
JmNoaWxkLT50c3MuZGVidWc7CisJdW5zaWduZWQgbG9uZyB0bXA7CisJaW50
IGksIG5zYXZlZCA9IGRiZy0+bnNhdmVkOwogCi0JY2hpbGQtPnRzcy5kZWJ1
Z1s0XSA9IDA7CisJZGJnLT5uc2F2ZWQgPSAwOwogCiAJaWYgKG5zYXZlZCA+
IDIpIHsKIAkJcHJpbnRrICgicHRyYWNlX2NhbmNlbF9icHQ6IGJvZ3VzIG5z
YXZlZDogJWQhXG4iLCBuc2F2ZWQpOwogCQluc2F2ZWQgPSAyOwogCX0KLQlm
b3IgKGkgPSAwOyBpIDwgbnNhdmVkOyBpKyspCi0JCXdyaXRlX2xvbmcgKGNo
aWxkLCBjaGlsZC0+dHNzLmRlYnVnW2ldLCBjaGlsZC0+dHNzLmRlYnVnW2kg
KyAyXSk7Ci0JcmV0dXJuIG5zYXZlZCAhPSAwOworCisJZm9yIChpID0gMDsg
aSA8IG5zYXZlZDsgaSsrKSB7CisJCXJlYWRfbG9uZyhjaGlsZCwgZGJnLT5i
cFtpXS5hZGRyZXNzLCAmdG1wKTsKKwkJaWYgKHRtcCAhPSBCUkVBS0lOU1Qp
CisJCQlwcmludGsoS0VSTl9FUlIgInB0cmFjZV9jYW5jZWxfYnB0OiB3ZWly
ZG5lc3NcbiIpOworCQl3cml0ZV9sb25nKGNoaWxkLCBkYmctPmJwW2ldLmFk
ZHJlc3MsIGRiZy0+YnBbaV0uaW5zbik7CisJfQorfQorCisKK3N0YXRpYyBp
bmxpbmUgaW50IAorcHRyYWNlX3F1ZXJ5X2JwdCAoc3RydWN0IHRhc2tfc3Ry
dWN0ICpjaGlsZCkKK3sKKwlyZXR1cm4gKGNoaWxkLT50c3MuZGVidWcubnNh
dmVkICE9IDApOworfQorCitpbnQKK3B0cmFjZV9jYW5jZWxfYnB0IChzdHJ1
Y3QgdGFza19zdHJ1Y3QgKmNoaWxkKQoreworCWludCByOworCWlmIChyID0g
cHRyYWNlX3F1ZXJ5X2JwdCAoY2hpbGQpLCByID09IDApCisJCXJldHVybiAw
OworCisJcHRyYWNlX2RvX2NhbmNlbF9icHQgKGNoaWxkKTsKKwlyZXR1cm4g
cjsKIH0KIAogYXNtbGlua2FnZSBpbnQgc3lzX3B0cmFjZShsb25nIHJlcXVl
c3QsIGxvbmcgcGlkLCBsb25nIGFkZHIsIGxvbmcgZGF0YSkKQEAgLTU4OSw2
ICs2MzcsNyBAQAogCQkgICAgKGN1cnJlbnQtPnVpZCAhPSBjaGlsZC0+dWlk
KSB8fAogCSAJICAgIChjdXJyZW50LT5naWQgIT0gY2hpbGQtPmVnaWQpIHx8
CiAJIAkgICAgKGN1cnJlbnQtPmdpZCAhPSBjaGlsZC0+c2dpZCkgfHwKKwkJ
ICAgICghY2FwX2lzc3Vic2V0KGNoaWxkLT5jYXBfcGVybWl0dGVkLCBjdXJy
ZW50LT5jYXBfcGVybWl0dGVkKSkgfHwKIAkgCSAgICAoY3VycmVudC0+Z2lk
ICE9IGNoaWxkLT5naWQpKSAmJiAhY2FwYWJsZShDQVBfU1lTX1BUUkFDRSkp
CiAJCQlnb3RvIG91dDsKIAkJLyogdGhlIHNhbWUgcHJvY2VzcyBjYW5ub3Qg
YmUgYXR0YWNoZWQgbWFueSB0aW1lcyAqLwpAQCAtNjIwLDcgKzY2OSw3IEBA
CiAJCQl1bnNpZ25lZCBsb25nIHRtcDsKIAogCQkJcmV0ID0gcmVhZF9sb25n
KGNoaWxkLCBhZGRyLCAmdG1wKTsKLQkJCWlmIChyZXQgPj0gMCkKKwkJCWlm
ICghcmV0KQogCQkJCXJldCA9IHB1dF91c2VyKHRtcCwgKHVuc2lnbmVkIGxv
bmcgKilkYXRhKTsKIAkJCWdvdG8gb3V0OwogCQl9CkBAIC02ODcsMTIgKzcz
Niw1NCBAQAogCQkJcmV0ID0gLUVJTzsKIAkJCWlmICgodW5zaWduZWQgbG9u
ZykgZGF0YSA+IF9OU0lHKQogCQkJCWdvdG8gb3V0OwotCQkJY2hpbGQtPnRz
cy5kZWJ1Z1s0XSA9IC0xOworCQkJY2hpbGQtPnRzcy5kZWJ1Zy5uc2F2ZWQg
PSAtMTsKIAkJCWNoaWxkLT5mbGFncyAmPSB+UEZfVFJBQ0VTWVM7CiAJCQl3
YWtlX3VwX3Byb2Nlc3MoY2hpbGQpOwogCQkJY2hpbGQtPmV4aXRfY29kZSA9
IGRhdGE7CiAJCQkvKiBnaXZlIGl0IGEgY2hhbmNlIHRvIHJ1bi4gKi8KIAkJ
CXJldCA9IDA7CisJCQlnb3RvIG91dDsKKworCQljYXNlIFBUUkFDRV9HRVRS
RUdTOgorCQl7CS8qIEdldCBhbGwgZ3AgcmVncyBmcm9tIHRoZSBjaGlsZC4g
Ki8KKwkJCXVuc2lnbmVkIGNoYXIgKnN0YWNrOworCisJCQlyZXQgPSAwOwor
CQkJc3RhY2sgPSAodW5zaWduZWQgY2hhciAqKSgodW5zaWduZWQgbG9uZylj
aGlsZCArIDgxOTIgLSBzaXplb2Yoc3RydWN0IHB0X3JlZ3MpKTsKKwkJCWlm
IChjb3B5X3RvX3VzZXIoKHZvaWQgKilkYXRhLCBzdGFjaywKKwkJCQkJIHNp
emVvZihzdHJ1Y3QgcHRfcmVncykpKQorCQkJCXJldCA9IC1FRkFVTFQ7CisK
KwkJCWdvdG8gb3V0OworCQl9OworCisJCWNhc2UgUFRSQUNFX1NFVFJFR1M6
CisJCXsKKwkJCS8qIFNldCBhbGwgZ3AgcmVncyBpbiB0aGUgY2hpbGQuICov
CisJCQl1bnNpZ25lZCBjaGFyICpzdGFjazsKKworCQkJcmV0ID0gMDsKKwkJ
CXN0YWNrID0gKHVuc2lnbmVkIGNoYXIgKikoKHVuc2lnbmVkIGxvbmcpY2hp
bGQgKyA4MTkyIC0gc2l6ZW9mKHN0cnVjdCBwdF9yZWdzKSk7CisJCQlpZiAo
Y29weV9mcm9tX3VzZXIoc3RhY2ssICh2b2lkICopZGF0YSwKKwkJCQkJICAg
c2l6ZW9mKHN0cnVjdCBwdF9yZWdzKSkpCisJCQkJcmV0ID0gLUVGQVVMVDsK
KwkJCWdvdG8gb3V0OworCQkgIH07CisKKwkJY2FzZSBQVFJBQ0VfR0VURlBS
RUdTOiAKKwkJCS8qIEdldCB0aGUgY2hpbGQgRlBVIHN0YXRlLiAqLworCQkJ
cmV0ID0gMDsKKwkJCWlmIChjb3B5X3RvX3VzZXIoKHZvaWQgKilkYXRhLCAm
Y2hpbGQtPnRzcy5mcHN0YXRlLAorCQkJCQkgc2l6ZW9mKHN0cnVjdCB1c2Vy
X2ZwKSkpCisJCQkJcmV0ID0gLUVGQVVMVDsKKwkJCWdvdG8gb3V0OworCQkK
KwkJY2FzZSBQVFJBQ0VfU0VURlBSRUdTOgorCQkJLyogU2V0IHRoZSBjaGls
ZCBGUFUgc3RhdGUuICovCisJCQlyZXQgPSAwOworCQkJaWYgKGNvcHlfZnJv
bV91c2VyKCZjaGlsZC0+dHNzLmZwc3RhdGUsICh2b2lkICopZGF0YSwKKwkJ
CQkJICAgc2l6ZW9mKHN0cnVjdCB1c2VyX2ZwKSkpCisJCQkJcmV0ID0gLUVG
QVVMVDsKIAkJCWdvdG8gb3V0OwogCiAJCWNhc2UgUFRSQUNFX0RFVEFDSDoJ
CQkJLyogZGV0YWNoIGEgcHJvY2VzcyB0aGF0IHdhcyBhdHRhY2hlZC4gKi8K
LS0tIC9za2lmZi9qYW1leS9saW51eC0yLjIuMTQtcm1rMy1jcmwxL2FyY2gv
YXJtL2tlcm5lbC9wcm9jZXNzLmMJVHVlIEphbiAxOCAxODowNjozMiAyMDAw
CisrKyAvdXNyL3NyYy9saW51eC9hcmNoL2FybS9rZXJuZWwvcHJvY2Vzcy5j
CVR1ZSBKYW4gMjUgMDI6MzM6NDYgMjAwMApAQCAtMjA4LDEwICsyMDgsOCBA
QAogCiB2b2lkIGZsdXNoX3RocmVhZCh2b2lkKQogewotCWludCBpOwotCi0J
Zm9yIChpID0gMDsgaSA8IE5SX0RFQlVHUzsgaSsrKQotCQljdXJyZW50LT50
c3MuZGVidWdbaV0gPSAwOworCW1lbXNldCgmY3VycmVudC0+dHNzLmRlYnVn
LCAwLCBzaXplb2YoY3VycmVudC0+dHNzLmRlYnVnKSk7CisJbWVtc2V0KCZj
dXJyZW50LT50c3MuZnBzdGF0ZSwgMCwgc2l6ZW9mKGN1cnJlbnQtPnRzcy5m
cHN0YXRlKSk7CiAJY3VycmVudC0+dXNlZF9tYXRoID0gMDsKIAljdXJyZW50
LT5mbGFncyAmPSB+UEZfVVNFREZQVTsKIH0KQEAgLTI1Niw3ICsyNTQsNiBA
QAogICovCiB2b2lkIGR1bXBfdGhyZWFkKHN0cnVjdCBwdF9yZWdzICogcmVn
cywgc3RydWN0IHVzZXIgKiBkdW1wKQogewotCWludCBpOwogCiAJZHVtcC0+
bWFnaWMgPSBDTUFHSUM7CiAJZHVtcC0+c3RhcnRfY29kZSA9IGN1cnJlbnQt
Pm1tLT5zdGFydF9jb2RlOwpAQCAtMjY2LDggKzI2MywxMSBAQAogCWR1bXAt
PnVfZHNpemUgPSAoY3VycmVudC0+bW0tPmJyayAtIGN1cnJlbnQtPm1tLT5z
dGFydF9kYXRhICsgUEFHRV9TSVpFIC0gMSkgPj4gUEFHRV9TSElGVDsKIAlk
dW1wLT51X3NzaXplID0gMDsKIAotCWZvciAoaSA9IDA7IGkgPCBOUl9ERUJV
R1M7IGkrKykKLQkJZHVtcC0+dV9kZWJ1Z3JlZ1tpXSA9IGN1cnJlbnQtPnRz
cy5kZWJ1Z1tpXTsgIAorCWR1bXAtPnVfZGVidWdyZWdbMF0gPSBjdXJyZW50
LT50c3MuZGVidWcuYnBbMF0uYWRkcmVzczsKKwlkdW1wLT51X2RlYnVncmVn
WzFdID0gY3VycmVudC0+dHNzLmRlYnVnLmJwWzFdLmFkZHJlc3M7CisJZHVt
cC0+dV9kZWJ1Z3JlZ1syXSA9IGN1cnJlbnQtPnRzcy5kZWJ1Zy5icFswXS5p
bnNuOworCWR1bXAtPnVfZGVidWdyZWdbM10gPSBjdXJyZW50LT50c3MuZGVi
dWcuYnBbMV0uaW5zbjsKKwlkdW1wLT51X2RlYnVncmVnWzRdID0gY3VycmVu
dC0+dHNzLmRlYnVnLm5zYXZlZDsKIAogCWlmIChkdW1wLT5zdGFydF9zdGFj
ayA8IDB4MDQwMDAwMDApCiAJCWR1bXAtPnVfc3NpemUgPSAoMHgwNDAwMDAw
MCAtIGR1bXAtPnN0YXJ0X3N0YWNrKSA+PiBQQUdFX1NISUZUOwo=
------------=_1583534244-23286-7--
From eliz@delorie.com Sat Apr 01 00:00:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: ac131313@cygnus.com
Cc: kingdon@redhat.com, gdb@sourceware.cygnus.com
Subject: Re: Dependence on config.status
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200003050737.CAA10121@indy.delorie.com>
References: <200002280657.BAA27090@indy.delorie.com> <38BCCA84.74A4143E@cygnus.com> <bem9u49sh.fsf@rtl.cygnus.com> <200003021007.FAA04124@indy.delorie.com> <38C0ACF2.C00719B0@cygnus.com>
X-SW-Source: 2000-q1/msg00541.html
Content-length: 509
> Eli Zaretskii wrote:
> >
> > > Well, if memory serves, if you re-ran configure in such a way that
> > > tm.h started linking to a different file, then the config.status
> > > dependency was the only way to force a rebuild.
> >
> > How about adding some #define to config.h that would also change when
> > this happens?
>
> Such as the names of the tm, xm and nm files?
Yes, that's what I had in mind. Since the configure scripts already
knows the names of those files, it could put them into config.h.
From tromey@cygnus.com Sat Apr 01 00:00:00 2000
From: Tom Tromey <tromey@cygnus.com>
To: gdb@sourceware.cygnus.com
Subject: Re: INSTALL set incorrectly in gdb/doc/Makefile
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <87og88rxaf.fsf@cygnus.com>
References: <200002270838.DAA25037@indy.delorie.com> <38BCDC1C.2917C1D6@cygnus.com> <200003211816.NAA12426@indy.delorie.com>
X-SW-Source: 2000-q1/msg00761.html
Content-length: 323
>>>>> "Eli" == Eli Zaretskii <eliz@delorie.com> writes:
Eli> How would people suggest to go about trying to solve this problem? It
Eli> looks like some Autoconf problem. Where would be a good place to ask
Eli> about this?
I didn't follow this thread, but autoconf questions should go to
autoconf@gnu.org.
Tom
From hjl@valinux.com Sat Apr 01 00:00:00 2000
From: "H . J . Lu" <hjl@valinux.com>
To: GDB <gdb@sourceware.cygnus.com>
Subject: Problems with hardware watchpoint on ia32.
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <20000307132401.A20282@valinux.com>
X-SW-Source: 2000-q1/msg00564.html
Content-length: 4090
I don't like the hardware watchpoint support on ia32. That is one
reason I started hacking gdb. Here are some examples:
# cat y.c
int a1;
int a2;
int a3;
int a4;
int a5;
int a6;
main ()
{
a1 = 11;
a2 = 12;
a3 = 13;
a4 = 14;
a5 = 15;
a6 = 16;
return 0;
}
# gcc -g -o y y.c
# /work/build/gnu/bin/gdb.orig/gdb/gdb y
(gdb) watch a1
Hardware watchpoint 1: a1
(gdb) watch a2
Hardware watchpoint 2: a2
(gdb) watch a3
Hardware watchpoint 3: a3
(gdb) watch a4
Hardware watchpoint 4: a4
(gdb) watch a5
Hardware watchpoint 5: a5
(gdb) r
Starting program: /home/hjl/bugs/gdb/hw/y
warning: Could not insert hardware watchpoint 5.
ptrace: Unknown error 4294967295.
Cannot insert breakpoints.
The same program may be running in another process.
(gdb) del 5
(gdb) r
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /home/hjl/bugs/gdb/hw/y
warning: Could not insert hardware watchpoint 1.
warning: Could not insert hardware watchpoint 3.
ptrace: Unknown error 4294967295.
Cannot insert breakpoints.
The same program may be running in another process.
(gdb)
ia32 only has 4 hardware debug registers. But gdb shouldn't crash. Even
worse, after deleted one hardware watchpoint, gdb still refused to
work.
One more annoying thing:
# cat ll.c
unsigned long long a1 = 0;
double a2 = 0;
main ()
{
a1 = 0x00000000ffffffffL;
a2 = 12;
a1 = 0xffffffff00000000L;
return 0;
}
# gcc -g -o ll ll.c
# /work/build/gnu/bin/gdb.orig/gdb/gdb ll
(gdb) watch a1
Watchpoint 1: a1
(gdb) watch a2
Watchpoint 2: a2
(gdb)
gdb won't set hardware watchpoints on long long nor double.
I put some kludegs in gdb 4.17. They work for me the way I prefer. F
r
the first one, I got
# /work/build/gnu/bin/gdb/gdb/gdb y
(gdb) watch a1
Hardware watchpoint 1: a1
(gdb) watch a2
Hardware watchpoint 2: a2
(gdb) watch a3
Hardware watchpoint 3: a3
(gdb) watch a4
Hardware watchpoint 4: a4
(gdb) watch a5
Hardware watchpoint 5: a5
(gdb) r
Starting program: /home/hjl/bugs/gdb/hw/y
warning: Could not insert hardware watchpoint 5.
warning: Could not insert hardware watchpoint 5.
Hardware watchpoint 1: a1
Hardware watchpoint 2: a2
Hardware watchpoint 3: a3
Hardware watchpoint 4: a4
Hardware watchpoint 5: a5
Hardware watchpoint 1: a1
Hardware watchpoint 2: a2
Hardware watchpoint 3: a3
Hardware watchpoint 4: a4
Hardware watchpoint 5: a5
warning: Could not insert hardware watchpoint 5.
warning: Could not insert hardware watchpoint 5.
Hardware watchpoint 1: a1
Hardware watchpoint 2: a2
Hardware watchpoint 3: a3
Hardware watchpoint 4: a4
Hardware watchpoint 5: a5
warning: Could not insert hardware watchpoint 5.
Hardware watchpoint 1: a1
Old value = 0
New value = 11
main () at y.c:12
12 a2 = 12;
(gdb) del 1
(gdb) del 1
(gdb) r
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /home/hjl/bugs/gdb/hw/y
Hardware watchpoint 2: a2
Hardware watchpoint 3: a3
Hardware watchpoint 4: a4
Hardware watchpoint 5: a5
Hardware watchpoint 2: a2
Hardware watchpoint 3: a3
Hardware watchpoint 4: a4
Hardware watchpoint 5: a5
Hardware watchpoint 2: a2
Hardware watchpoint 3: a3
Hardware watchpoint 4: a4
Hardware watchpoint 5: a5
Hardware watchpoint 2: a2
Old value = 0
New value = 12
main () at y.c:13
13 a3 = 13;
(gdb)
For the second one,
# /work/build/gnu/bin/gdb/gdb/gdb ll
(gdb) watch a1
Hardware watchpoint 1: a1
(gdb) watch a2
Hardware watchpoint 2: a2
(gdb) r
Starting program: /home/hjl/bugs/gdb/hw/ll
Hardware watchpoint 1: a1
Hardware watchpoint 2: a2
Hardware watchpoint 1: a1
Hardware watchpoint 2: a2
Hardware watchpoint 1: a1
Hardware watchpoint 2: a2
Hardware watchpoint 1: a1
Old value = 0
New value = 4294967295
0x80483d3 in main () at ll.c:7
7 a1 = 0x00000000ffffffffL;
(gdb) c
Continuing.
Hardware watchpoint 2: a2
Old value = 0
New value = 12
main () at ll.c:9
9 a1 = 0xffffffff00000000L;
I know the support for long long and double is not perfect. But I
much prefer it than none at all.
I will send in a patch in another email.
H.J.
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: GDB Discussion <gdb@sourceware.cygnus.com>
Subject: [Fwd: Preparing for the GDB 5.0 / GDB 2000 / GDB2k release]
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <389ECBAF.66013B07@cygnus.com>
X-SW-Source: 2000-q1/msg00120.html
Content-length: 2738
To : GDB Testers <gdb-testers at sourceware dot cygnus dot com>
Subject : Preparing for the GDB 5.0 / GDB 2000 / GDB2k release
From : Andrew Cagney <ac131313 at cygnus dot com>
Date : Tue, 08 Feb 2000 00:26:45 +1100
Newsgroups : cygnus.testers.gdb
Organization : Cygnus Solutions
Xref : cygnus.com cygnus.testers.gdb:212
[Please follow up to the general GDB mailing list]
Hello,
Given it is now almost a year since the last release of GDB (4.18) and
given also the number of significant internal changes made since that
release (event-loop, multi-arch, ui-out, ISO-C, obsolete code, ...), it
is now time to start anew the process of releasing a major version of
GDB - GDB 5.0.
As this release is being conducted entirely from the (new!) public CVS
repository I'm hoping that a more aggressive release schedule can be
achieved. With that in mind, I've tentatively planned: two weeks of
patch resolution; the cutting of the 5.0 branch (2000-02-21?); one week
of last minute checks; and then the 5.0 release (29/2 2000-02-29?).
(Everyone is free to roll on the floor laughing at this point :-)
So, as Jason Molenda aptly wrote way back in '98:
> If you have patches that are ready to go in, but have not yet been
> submitted, please send them in now. If you don't have your FSF copyright
> assignment paperwork submitted and on-file at the FSF, we probably won't
> have time to get significant contributions in for this release.
>
> If you sent in a patch, but have not heard anything and the patch is not
> in the latest snapshot [snip],
> please send it in again. We have a backlog of patches which have not
> yet been evaluated, so we'll be going over those for the next few days.
> I'd rather have two copies of a patch than zero copies, so don't be shy.
It would be good to see this GDB release running on *Linux, *BSD and
cygwin as well as plenty of the more traditional UNIX platforms.
For your reference, general GDB information can be found at:
http://sourceware.cygnus.com/gdb/
while a pre- checked-out CVS source tree containing both GDB and DEJAGNU
can be found at:
ftp://sourceware.cygnus.com/pub/gdb/snapshots/gdb-dejagnu-pserver-2000-02-06.tar.bz2
Alternativly, the separate components:
ftp://sourceware.cygnus.com/pub/gdb/snapshots/dejagnu-pserver-2000-02-06.tar.bz2
ftp://sourceware.cygnus.com/pub/gdb/snapshots/gdb-pserver-2000-02-06.tar.bz2
are also available. You will need to build (install) dejagnu before
running the GDB testsuite.
Finally, the GDB 5.1 release process is scheduled to start before July
'00 (if not much sooner!). If you have a major new port or contribution
then perhaphs 5.1 is the release you should be shooting for.
enjoy,
Andrew
--
Andrew Cagney (Red Hat)
GDB
From jtc@redback.com Sat Apr 01 00:00:00 2000
From: jtc@redback.com (J.T. Conklin)
To: Eli Zaretskii <eliz@is.elta.co.il>
Cc: gdb@sourceware.cygnus.com
Subject: Re: memory region attribute CLI
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <5mhfe0kvpm.fsf@jtc.redbacknetworks.com>
References: <5mr9dd5dlt.fsf@jtc.redbacknetworks.com> <200003160944.EAA01842@indy.delorie.com> <5mem9avs45.fsf@jtc.redbacknetworks.com> <5m3dplwjri.fsf@jtc.redbacknetworks.com> <200003211819.NAA12438@indy.delorie.com>
X-SW-Source: 2000-q1/msg00762.html
Content-length: 600
>>>>> "Eli" == Eli Zaretskii <eliz@delorie.com> writes:
Eli> I think this is a very useful idea. But as far as I understand, the
Eli> information managed by the code you posted needs to be consulted by
Eli> other GDB commands, right? I don't see any code that does that yet.
Correct. I just started on the code that actually looks up and acts
on memory region attributes yesterday. I sent messages with the CLI
description and later the CLI code to get feedback on those parts, as
well as feedback on the general concept of region attributes.
--jtc
--
J.T. Conklin
RedBack Networks
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Eli Zaretskii <eliz@delorie.com>
Cc: gdb@sourceware.cygnus.com, DJ Delorie <dj@delorie.com>
Subject: Re: 000217: status of DJGPP support
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38B092B7.73CDF9B6@cygnus.com>
References: <200002201017.FAA12081@indy.delorie.com>
X-SW-Source: 2000-q1/msg00357.html
Content-length: 2418
Eli Zaretskii wrote:
>
> I fetched the 000217 snapshot yesterday and tried to build it with
> DJGPP. I had only limited success: after some tweaking, everything
> compiled, but linker complains about undefined references to several
> functions. In general, the DJGPP native support should be currently
> considered broken in several ways; I'm working on repairing it.
>
> Here are some specific comments/questions:
>
> - There are lots of warnings about comparison of signed with
> unsigned and unused arguments. I find it hard to believe that
> this is specific to DJGPP: doesn't anyone else see these warnings?
> No doubt they are due to -Wall, but I understand we want to go
> into production with these switches, right?
Not for 5.0. The only warnings I consider significant for 5.0 are those
from:
,-Wimplicit\
,-Wreturn-type\
,-Wcomment\
,-Wtrigraphs\
,-Wformat\
,-Wparentheses\
,-Wpointer-arith\
,-Woverloaded-virtual\
even then, there are going to be platforms that can't be compiled if
these flags are specified. Sorry.
> - The configure scripts cannot be run without some tricks, like
> setting a few variables in the environment. So I'm thinking about
> adding a gdb/djgpp subdirectory with a special script that DJGPP
> users will need to run (and which in turn will run the top-level
> configure), and maybe a few small Sed scripts to fix file-name
> related problems on 8+3 filesystems. Is this acceptable?
Well, there is currently:
gdb/mpw-make.sed
and gdb/config/mpw/*
I'd suggest:
gdb/config/djgpp/*
Comments? Stan?
> - What is the policy for fixing problems in the directories taken
> from Binutils? I'd imagine you want me to send patches to
> Binutils maintainers, but with the next Binutils release nowhere
> in sight, and some of my patches to Binutils in the queue since
> August, is this really practical? How can I make sure these
> problems are fixed in GDB before GDB 5.0 is released?
GDB 5.0 shares the bfd, include, and a few other directories with
BINUTILS. This means that once a patch is approved for BINUTILS, GDB
gets it immediatly - the problem of new release has been eliminated.
Unfortunatly, this also means that if BINUTILS pushes back on a patch,
GDB can't accept it :-(
How to solve the situtation you're in? Off hand, I don't know - what
exactly is the status of those patches?
Andrew
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Quality Quorum <qqi@world.std.com>
Cc: gdb@sourceware.cygnus.com, Leon Pollak <leonp@plris.com>
Subject: Re: gdb remote protocol, winnt, wigglers
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <3872E2E2.8E713C7F@cygnus.com>
References: <Pine.SGI.3.95.1000103001126.6751A-100000@world.std.com>
X-SW-Source: 2000-q1/msg00006.html
Content-length: 4779
[List pruned a little :-)]
Quality Quorum wrote:
> Hi,
>
> I am working on implmenting standard compliant remote.c and gdbserver.
> I found just a few problems with protocol specs so far.
>
> 1. There is no need in 'isThreadAlive' request: remote.c has to maintain
> local cache of available threads, which is updated by 'threadListQuery'
> if required (I tried a few variants implementing thread list
> synchronization and it seems this one is the most rational).
>
> Target methods xxx_is_thread_alive and xxxxx_find_new_thread
> are simply using this cache without generating any traffic
> on the wire.
>
> So. 'itThreadAlive' is depreciated.
>
> 2. I misread code implementing 'addBWPoint' and 'deleteBWPpoint',
> so the description was incorrec, it is fixed now.
>
> I put updated document at http://www.std.com/qqi/ftp/protocol.txt .
>
> I put updated rproxy at http://www.std.com/qqi/labslave/rproxy.html .
>
> It is now running on WinNT and sipports Wiggler among other things -
> I tried it with MPC860ADS. It will be not too complicated to add
> other processors, however, I do have 68360 based board only and no
> other wigglers. I have ICD cable which I am using under linux,
> I am planning to provide a target under linux using ICD cable to 68360.
>
> Please, be forgiving: WinNT stuff is barely in alpha state, rest is
> barely in beta.
>
> I have nagging outstanding problem: I do not know what paperwork and
> what changes in the files I have to make in order to turn it over
> to FSF. I signed and submitted the most appropriate paper I found on
> gnu website, however, I did not hear from them yet and it seems to me
> that it will not be enough.
>
> Can any kind soul help me with this ?
Just FYI, there are several things that we're going to need to keep in
mind if this is to go forward.
As a general comment, its good to at least see someone with the energy
to pursue the gdbserver/stub code so that there is a generic (and
correct!) stub reference implementation available. The fact that you're
hammering the external side is (as they say in the USofA) cool.
When it comes to things like the remote protocol spec and remote.c, you
might need to take a little care and think about what you want to do
with the work in the longer term. To that end, I've some notes on both
remote.c and the spec below.
[[As an aside, I'm away for much of January, because of that and because
you appearing to be moving at a rapid rate of knots, I'm going to try to
be fairly to the point with the problems we're going to encounter. That
way, I'm hopefully avoiding the possibility of you doing much
significant work that, unfortunately, ends up in limbo.]]
Andrew
Spec:
The current ``official'' protocol spec is in the GDB user guide. (As an
aside, it wasn't put in the internals manual as it was documenting an
external interface.)
Rather than end up with two possibly conflicting definitions, its
obviously going to be better if there was only one definition of the
protocol. To that end, you many want to first think about how to
re-structure (before re-wording) the protocol spec. Should it go into a
separate chapter or as an appendix / attatchment? It's actually Stan
Shebs decision (as the doco maintainer).
With the higher level stuff out the way, it will become possible,
through a series of patches, to evolve the current spec into something
better.
FWIW, I'm strongly against simply replacing the existing spec with a new
one. I'd like to be able to see (using CVS diff) what was changed at
each point so that any problems/issues can be traced down and then
fixed.
remote.c:
Beware, remote.c's underlying architecture is in a state of flux.
Of the possible targets to async first remote was selected as it wasn't
going to affect native targets and was entirely self contained (also it
didn't involve signals or ptrace). It turned out that it had some of the
more complex interactions but that is another story. :-)
The consequence is that remote.c currently contains two remote targets:
remote / extended-remote and async / extended-async. Once all the async
issues are resolved, the old code will be given the flick. If you've
been looking through remote.c you'll have noticed the FIXME's I've added
as place holders while other async code is finished.
If you're looking to re-do remote.c you'll need to keep in mind that
file is going to continue to receive major changes and those changes
will, unfortunately, take priority over anything else (sigh). If you're
able to submit small and distinct patches then there is a really high
likelihood of your work being accepted quickly and that will allow the
work to keep reasonably in sync with the mainline code.
Take care,
Andrew
From Guenther.Grau@marconicomms.com Sat Apr 01 00:00:00 2000
From: Guenther Grau <Guenther.Grau@marconicomms.com>
To: gdb@sourceware.cygnus.com
Subject: Re: A patch for gnu-regex
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38C7C369.97CF2A7F@marconicomms.com>
References: <38C585BB.3F7B1AC7@apple.com> <20000307155806.A30106@valinux.com> <5mg0u2l3g0.fsf@jtc.redbacknetworks.com> <20000307162127.D485@lucon.org> <200003080044.e280iGB00429@delius.kettenis.local> <5m4saivyew.fsf@jtc.redbacknetworks.com> <38C7B8BD.26C0E220@cygnus.com>
X-SW-Source: 2000-q1/msg00651.html
Content-length: 714
Andrew Cagney wrote:
>
[...]
> > http://sourceware.cygnus.com/ml/gdb-patches/2000-q1/msg00562.html
> > http://sourceware.cygnus.com/ml/gdb-patches/2000-q1/msg00566.html
>
> This patch is definitly much better than the original.
>
> Unfortunatly, I don't think that selecting a pre-installed regexp should
> be the default. My rationale (As Mark? noted) is that ensuring that a
> GDB release provides consistent behavour between systems (1) is more
> important than having it select the latest/greatest random regexp.
I support this (not that it matters :-). If H.J. Lu wants it on
Linux, he can ./configure --with-libc-regex or --with-native-regex,
but the default should be the regex within gdb.
Guenther
From shebs@apple.com Sat Apr 01 00:00:00 2000
From: Stan Shebs <shebs@apple.com>
To: Elena Zannoni <ezannoni@cygnus.com>
Cc: "Peter.Schauer" <Peter.Schauer@regent.e-technik.tu-muenchen.de>, Mark Kettenis <kettenis@wins.uva.nl>, gdb@sourceware.cygnus.com
Subject: Re: Testsuite regression
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38DFF635.A64D0CC8@apple.com>
References: <200003261706.e2QH6Yn08493@delius.kettenis.local> <200003261941.VAA32661@reisser.regent.e-technik.tu-muenchen.de> <14559.39965.642134.260490@kwikemart.cygnus.com>
X-SW-Source: 2000-q1/msg00822.html
Content-length: 301
Elena Zannoni wrote:
>
> I tested your fix on solaris and linux, it seems to work fine. I have
> committed it. (Sorry, I know I shouldn't have done it w/o official
> approval from Stan).
No, that's cool. To quote from the GCC pages, "We don't want to get overly
anal about checkin policies".
Stan
From kettenis@wins.uva.nl Sat Apr 01 00:00:00 2000
From: Mark Kettenis <kettenis@wins.uva.nl>
To: msnyder@cygnus.com
Cc: gdb@sourceware.cygnus.com
Subject: lin-thread cannot handle thread exit
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200003031635.e23GZwi00372@delius.kettenis.local>
X-SW-Source: 2000-q1/msg00525.html
Content-length: 1394
Hi Michael,
The thread_db assisted debugging code doesn't handle exiting threads
properly, at least in combination with glibc 2.1.3. There are at
least two problems that prevent this from working:
1. In lin-thread.c:enable_thread_event_reporting(), GDB requests
TD_DEATH events to be reported, and sets a breakpoint at the
appropriate location. The problem is that the LinuxThreads
implementation included with glibc 2.1.3 triggers that breakpoint
after it has flagged the thread as terminated. As a conseuqence
when GDB tries to fetch the registers for that thread it doesn't
succeed, and GDB complains about a breakpoint at location 0x0 that
it doesn't know of.
2. If I disable the reporting of TD_DEATH events, things still don't
work. The problem is that when the thread really exits, a
TARGET_WAITKIND_EXITED event is reported to GDB in. So the answer to
the question ``Can I get this event mistakenly from a thread?'' in
lin-thread.c:thread_db_wait() is ``Yes''. Since the
TARGET_WAITKIND_EXITED event is passed on to other code in GDB, GDB
thinks that the entire process has died.
Ignoring those "spurious" TARGET_WAITKIND_EXITED events doesn't help
since some parts of GDB still think that the thread is still alive
then.
Looking through the code, it seems that there quite a few "loose
ends". Is this still "work in progress"?
Mark
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: annotate.texi
2000-03-08 2:03 ` annotate.texi Eli Zaretskii
2000-04-01 0:00 ` annotate.texi Eli Zaretskii
@ 2000-04-01 0:00 ` Jim Kingdon
2000-04-01 0:00 ` annotate.texi Eli Zaretskii
2 siblings, 0 replies; 5+ messages in thread
From: Jim Kingdon @ 2000-04-01 0:00 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: gdb
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 34383 bytes --]
> I'm trying to add some indexing whenever I can. But I suggest that
> every manual patch be scrutinized for appropriate index entries
Sounds like the voice of someone volunteering to do some scrutinization ;-).
Believe me, "people sending in lots of manual patches which never get
merged" just hasn't been a problem on any free software project I've
worked on. Having Stan as the documentation maintainer is a good
thing too, because we are willing to hurt him if he slacks off :-).
From toddpw@windriver.com Sat Apr 01 00:00:00 2000
From: Todd Whitesel <toddpw@windriver.com>
To: akale@veritas.com (Amit S. Kale)
Cc: toddpw@windriver.com (Todd Whitesel), kingdon@redhat.com (Jim Kingdon), akale@veritas.com, kettenis@wins.uva.nl, gdb@sourceware.cygnus.com, gdb-patches@sourceware.cygnus.com
Subject: Re: Regression caused by elfread.c patch
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200002152007.MAA08037@alabama.wrs.com>
References: <00021514224700.31608@fermat.vxindia.veritas.com>
X-SW-Source: 2000-q1/msg00299.html
Content-length: 2051
> I guess gdb first prepares text, data, bss segments and following code
> bfd/section.c:bfd_make_section_anyway():
> newsect->index = abfd->section_count++;
> indicates that section->index contains SECT_OFF_* codes when segments are
> loaded. This may not have been designed this way, but it seems to be that way.
Yes, this looks like a desperate attempt to deal with the fundamental
numbering conflict that currently exists.
Any time stabs are read, much of GDB assumes that ANOFFSET takes SECT_OFF_*
values, even in cases where you'd expect it to take BFD section indices. So
anyone actually attempting to use BFD indices for real is plagued by subtle
bugs.
> Using sym->section->index is not right for segments that are not text or data
> segments. Using sym->section->index should be all right for data segments.
It depends on the path through the *_symfile_offsets code that is taken.
symtab.h explicitly claims that the section numbers in ANOFFSET are
"file-type-dependent" but this is largely ignored by the rest of GDB.
> I suggest following patch. I have verified that the vfprintf problem reported
> by Mark does not appear with this patch. I haven't tested it with test suite.
I guarantee you it won't completely solve the problem. But if the test suite
uses fully-linked programs, it will end up passing the tests anyway because
ANOFFSET returns 0 for all sections when a file is fully linked.
> > However, so few configurations (read: vxWorks and ??) actually use different
> > offsets for, say, SECT_OFF_TEXT and SECT_OFF_DATA, that no one notices the
> > problems with it. (We read relocatable .o files too, which is also rare.)
>
> It won'd be rare when gdb will be used by more people to debug linux kernel
> modules.
I hope you've got patches to symbol_file_add() and *_symfile_offsets to
accept more than one address offset for the section_offsets->offsets array.
If not, then any section loaded independently from .text is going to have
mucho problems being relocated by GDB.
--
Todd Whitesel
toddpw @ windriver.com
From grante@visi.com Sat Apr 01 00:00:00 2000
From: Grant Edwards <grante@visi.com>
To: Fernando Nasser <fnasser@cygnus.com>
Cc: Fernando Nasser <fnasser@redhat.com>, gdb@sourceware.cygnus.com
Subject: Re: RDI target broken in 000215 snapshot
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <20000224133238.A723@visi.com>
References: <20000221104541.A28578@visi.com> <38B2AD14.7B0B4A4E@redhat.com> <20000224124726.A663@visi.com> <38B58292.3B11D622@cygnus.com>
X-SW-Source: 2000-q1/msg00402.html
Content-length: 1495
On Thu, Feb 24, 2000 at 02:12:18PM -0500, Fernando Nasser wrote:
> > When I download code with the "load" command, the byte order of
> > the data gets flipped -- it ends up in little-endian order
> > (it's big-endian in the file, and I need it to stay that way
> > when it is downloaded). Downloading with a patched 4.18 doesn't
> > have this problem.
> >
> Grant,
>
> What compiler, in what host and with which parameters did you
> generate your executable file?
$ uname -a
Linux grante.comtrol.com 2.2.12-20 #1 Mon Sep 27 10:25:54 EDT 1999 i586 unknown
$ arm-elf-gcc --version
2.95.2
$ arm-elf-as --version
GNU assembler 991018
$ make
arm-elf-as --gstabs -EB -m arm7tdmi -amhlsnd=memconfigR10_S0_D100.lst -o memconfigR10_S0_D100.o memconfigR10_S0_D100.s
arm-elf-gcc -g -mcpu=arm7tdmi -fverbose-asm -mbig-endian -Wl,-Map,memconfigR10_S0_D100.map -nostartfiles -o memconfigR10_S0_D100 memconfigR10_S0_D100.o -T./memconfig.ld -nostdlib libgcc.a
> Is it the same one you can successifuly load with the patched 4.18?
Yes.
> In both cases you are loading the program into the AEB board, right?
No. I'm loading to custom hardware (big-endian), but I verified
that the same thing happens with the Samsung SNDS eval board
(also big-endian hardware).
I've used the EPI Jeeni (via ethernet) and the ARM Embedded ICE
(via serial port) and had the same results.
> I forgot, which host are you running gdb in? Linux, Solaris, Cygwin?
Linux (same as above).
--
Grant Edwards
grante@visi.com
From jtc@redback.com Sat Apr 01 00:00:00 2000
From: jtc@redback.com (J.T. Conklin)
To: "H . J . Lu" <hjl@valinux.com>
Cc: Stan Shebs <shebs@apple.com>, gdb-patches@sourceware.cygnus.com, GDB <gdb@sourceware.cygnus.com>
Subject: Re: A patch for gnu-regex
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <5mg0u2l3g0.fsf@jtc.redbacknetworks.com>
References: <20000307134103.A20533@valinux.com> <38C585BB.3F7B1AC7@apple.com> <20000307155806.A30106@valinux.com>
X-SW-Source: 2000-q1/msg00575.html
Content-length: 334
>>>>> "hjl" == H J Lu <hjl@valinux.com> writes:
hjl> 2000-03-07 H.J. Lu <hjl@gnu.org>
hjl>
hjl> * gdb-regex.h: New. Include <regex.h> for glibc 2 and include
hjl> "gnu-regex.h" otherwise.
If we follow the naming convention we have been using, gdb-regex.h
should be gdb_regex.h.
--jtc
--
J.T. Conklin
RedBack Networks
From jimb@cygnus.com Sat Apr 01 00:00:00 2000
From: Jim Blandy <jimb@cygnus.com>
To: gdb@sourceware.cygnus.com
Subject: Try out the patch database
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200002292134.QAA10095@zwingli.cygnus.com>
X-SW-Source: 2000-q1/msg00450.html
Content-length: 858
Take a look at http://sourceware.cygnus.com/gdb/contribute.html , and
let me know what you think.
I'd like to incorporate the text of that page itself into the main GDB
page, http://sourceware.cygnus.com/gdb/ .
contribute.html refers to three new pages:
- patch-db.html, which is supposed to be everything a new contributor
needs to know to add a patch to the patch database.
- patch-checklist.html, a checklist for submitting patches via
E-mail. Originally, I was going to do a template, but it seems like
GNATS will do everything that's important automatically, so I don't
think a template offers much benefit over simple instructions.
- assigning.html, a page explaining the copyright situation, and
directing people to talk to me. Eventually, of course, we'll want a
role mail address for this, but I want to get things going quickly.
From shebs@apple.com Sat Apr 01 00:00:00 2000
From: Stan Shebs <shebs@apple.com>
To: Jim Kingdon <kingdon@redhat.com>, gdb@sourceware.cygnus.com
Subject: Re: Status
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38A48A0D.D7AE28C2@apple.com>
References: <38A34041.B443DAFB@apple.com> <bitzw8fvy.fsf@rtl.cygnus.com> <38A46C5C.F8301644@apple.com>
X-SW-Source: 2000-q1/msg00234.html
Content-length: 370
Stan Shebs wrote:
> There's some kind of Mach layer underneath, 2.5 I think, [...]
Ooops, should have checked http://www.apple.com/macosx/inside.html
where this is described for everybody:
The systemÂ’s kernel [...] is based on Mach 3.0 from
Carnegie-Mellon University and FreeBSD 3.2 (derived
from the University of California at BerkeleyÂ’s BSD 4.4-Lite)
Stan
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: "Gabor Z. Papp" <gzp@gzp.org.hu>
Cc: gdb@sourceware.cygnus.com
Subject: Re: gdb cvs
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38BDE5F9.49AD7232@cygnus.com>
References: <200003011940.e21Je9528423@mail.gzp.org.hu> <20000302032052.L17285@gzp.org.hu>
X-SW-Source: 2000-q1/msg00484.html
Content-length: 324
"Gabor Z. Papp" wrote:
>
> | cvs checkout: authorization failed: server anoncvs.cygnus.com rejected access
>
> What is with the cvs access?
Same problem as the BINUTILS repository - it's been moved. Both GDB and
BINUTILS are drawn from a common CVS repository.
Check http://sourceware.cygnus.com/gdb/
enjoy,
Andrew
From kingdon@redhat.com Sat Apr 01 00:00:00 2000
From: Jim Kingdon <kingdon@redhat.com>
To: gdb@sourceware.cygnus.com
Subject: Re: new version of rproxy
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <bya8wg9pf.fsf@rtl.cygnus.com>
References: <Pine.SGI.3.95.1000206105418.150A-100000@world.std.com>
X-SW-Source: 2000-q1/msg00131.html
Content-length: 155
> I put a new rproxy-0.6 to my web site
> http://www.std.com/qqi/labslave/rproxy.html
Cool! I've added a link from http://sourceware.cygnus.com/gdb/
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Eli Zaretskii <eliz@delorie.com>
Cc: kingdon@redhat.com, gdb@sourceware.cygnus.com
Subject: Re: Dependence on config.status
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38C220BE.44922A6@cygnus.com>
References: <200002280657.BAA27090@indy.delorie.com> <38BCCA84.74A4143E@cygnus.com> <bem9u49sh.fsf@rtl.cygnus.com> <200003021007.FAA04124@indy.delorie.com> <38C0ACF2.C00719B0@cygnus.com> <200003050737.CAA10121@indy.delorie.com>
X-SW-Source: 2000-q1/msg00545.html
Content-length: 1020
Eli Zaretskii wrote:
>
> > Eli Zaretskii wrote:
> > >
> > > > Well, if memory serves, if you re-ran configure in such a way that
> > > > tm.h started linking to a different file, then the config.status
> > > > dependency was the only way to force a rebuild.
> > >
> > > How about adding some #define to config.h that would also change when
> > > this happens?
> >
> > Such as the names of the tm, xm and nm files?
>
> Yes, that's what I had in mind. Since the configure scripts already
> knows the names of those files, it could put them into config.h.
Well I've long had in mind a ``maint build-info'' command that printed
out things like:
tm/xm/hm.h
the --host/target/build tupples
the compiler
the path to the source tree
the build date
the user/machine
Assuming your suggestion works (JimK doesn't find more technical flaws
(1) :-) A change putting tm/xm/hm into config.h is ok with me :-)
Andrew
(1) I think changing tm/xm/nm happens sufficiently often for it to be
dangerous to not force a rebuild.
From Guenther.Grau@marconicomms.com Sat Apr 01 00:00:00 2000
From: Guenther Grau <Guenther.Grau@marconicomms.com>
To: gdb@sourceware.cygnus.com
Subject: Re: gdb and iso-c
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38DB7FF7.E3AFDE79@marconicomms.com>
References: <200003241301.OAA04488@mail.macqel.be>
X-SW-Source: 2000-q1/msg00796.html
Content-length: 1036
Hi,
Philippe De Muyter wrote:
> Up to some years ago, gdb could be compiled by a K&R C compiler.
> Now, it can not anymore, and the change seems to be deliberate.
Well, you have to move forward, even if you don't see it
as a step forwad ;-)
> It seems to me that the freedom of the gdb users is now restricted compared
> to the previous versions because of the need of an ISO-C compiler instead
> of any C compiler to compile it.
>
> And I do not understand why the same reasons that apply to binutils and gcc
> do not hold for gdb. gdb, because it is better than the debugger you get
> with your operating system, is needed to bootstrap the installation of
> gas, gld, or gcc in the likely case that not everything works well
> the first time.
All major operating systems I know come with a reasonable modern
iso-c compiler (or at least you can get one for it). And even if
this weren't the case, you can always crosscompile gdb on a different
platform (This feature needs more testing anyways ;-)
Just my 0,02 EUR,
Guenther
From eliz@delorie.com Sat Apr 01 00:00:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: gdb@sourceware.cygnus.com
Cc: ezannoni@cygnus.com
Subject: Buffering problems with "gdb < foo"
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200003050850.DAA10185@indy.delorie.com>
X-SW-Source: 2000-q1/msg00544.html
Content-length: 1150
A comment in event-top.c (inside the change_line_handler function)
says this:
/* NOTE: this operates on input_fd, not instream. If we are reading
commands from a file, instream will point to the file. However in
async mode, we always read commands from a file with editing
off. This means that the 'set editing on/off' will have effect
only on the interactive session. */
However, running "gdb < foo" seems to contradict this: I put a
breakpoint in gdb_readline2, and it is never hit. Am I missing
something?
The problem with this is that if the file `foo' includes a command
which needs a confirmation, the call to fgetc in query will eatup lots
of characters which will never again be seen by the event loop. In my
case, fgetc read all the file (it was small), so GDB hit EOF and
exited. I can prevent this from happening by putting "set editing off"
in the input file. Invoking GDB with --noasync also solves the
problem.
Does this work on Unix? If so, it would make this a DJGPP-specific
problem.
If this is not DJGPP-specific, then I think _initialize_event_loop
should turn editing off if input_fd is not a tty.
From muller@cerbere.u-strasbg.fr Sat Apr 01 00:00:00 2000
From: Pierre Muller <muller@cerbere.u-strasbg.fr>
To: gdb@sourceware.cygnus.com
Subject: Re: Updated MAINTAINERS file - work in progress
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200002111033.LAA29442@cerbere.u-strasbg.fr>
X-SW-Source: 2000-q1/msg00221.html
Content-length: 434
At 21:33 10/02/00 -0800, you wrote:
>> Andrew Cagney ac131313@cygnus.com?
>> Stan Shebs shebs@cygnus.com?
Wouldn't it be much more logical to have aliases here ?
Andrew.Cagney@sourceware.cygnus.com
or even better
Andrew.Cagney@gdb.fsf.org ???
Pierre Muller
Institut Charles Sadron
6,rue Boussingault
F 67083 STRASBOURG CEDEX (France)
mailto:muller@ics.u-strasbg.fr
Phone : (33)-3-88-41-40-07 Fax : (33)-3-88-41-40-99
From hanymorcos@yahoo.com Sat Apr 01 00:00:00 2000
From: Hany Morcos <hanymorcos@yahoo.com>
To: Hany Morcos <hanymorcos@yahoo.com>, gdb@sourceware.cygnus.com
Subject: Re: Debugging a constructor
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <20000225003041.21219.qmail@web3204.mail.yahoo.com>
X-SW-Source: 2000-q1/msg00413.html
Content-length: 686
Got it
thank you
--- Hany Morcos <hanymorcos@yahoo.com> wrote:
>
>
> How do I print the variable values inside
> a constructor?
>
> I can't use this... Because doesn't exist yet..
> The object hasn't been constructed...
>
> Then how do I print the value of x??
>
> class y{
>
> public:
> y(int* x) {x =
> coreDumpAndGenerateManyHeadaches(); // print x
> inside
> gdb } ;
> };
>
>
> __________________________________________________
> Do You Yahoo!?
> Talk to your friends online with Yahoo! Messenger.
> http://im.yahoo.com
>
__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com
From kettenis@wins.uva.nl Sat Apr 01 00:00:00 2000
From: Mark Kettenis <kettenis@wins.uva.nl>
To: gdb@sourceware.cygnus.com, gdb-patches@sourceware.cygnus.com
Subject: `long double' support for ix86 targets
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200003031531.e23FV8T00285@delius.kettenis.local>
X-SW-Source: 2000-q1/msg00523.html
Content-length: 5450
Hi,
Kevin's changes to findvar.c:extract_floating() and store_floating()
together with some further analysis have convinced me that for all but
one ix86 targets 96-bit long doubles of type &floatformat_i387_ext are
the right thing. This would give most of the ix86 targets instant
support for long doubles. It also gives us the opportunity to remove
some ugly bits introduced by people who tried to hack around the
current limitations.
Here are some personal notes I made about this:
Support for `long double'
-------------------------
The majority of i386 targets in GCC have a `long double' that is
96 bits wide (of which only 80 bits are used, the rest is padding).
In fact the only exception is OSF/1, where `long double' is equivalent
to `double' and has only 64 bits. This length of 96 bits is also
used in the debugging information generated by the compiler.
The origional i386 System V ABI specification doesn't say anything about
`long double', but the new (draft) IA-64 System V ABI specification
uses a `long double' of 96 bits for things running in 32-bit mode.
I guess that 32-bit mode is supposed to be provided for compatible
with IA-32, this implies that 96 bits is supposed to be the standard.
Therefore, `config/i386/tm-i386.h' should define:
#define TARGET_LONG_DOUBLE_FORMAT &floatformat_i387_ext
#define TARGET_LONG_DOUBLE_BITS 96
Targets such as OSF/1 can override this.
If we do the above, we can make the default "virtual" type of the FPU
registers `builtin_type_long_double'. A lot of the Linux cruft for
dealing with `long double' could be removed.
I intend to check in the following patch in a week or two, but since
this change affects most of the ix86 targets, I'd like to give people
the opportunity to object.
Mark
2000-03-02 Mark Kettenis <kettenis@gnu.org>
* config/i386/tm-i386.h (TARGET_LONG_DOUBLE_FORMAT): Define as
&floatformat_i387_ext.
(TARGET_LONG_DOUBLE_BITS): Define as 96.
(REGISTER_VIRTUAL_TYPE): Change type for FPU registers to
`builtin_type_long_double'.
(REGISTER_CONVERT_TO_VIRTUAL): Simply copy over the data, and pad
with zeroes.
(REGISTER_CONVERT_TO_RAW): Simply copy over the significant data.
(i387_to_double, double_to_i387): Remove prototypes.
Index: config/i386/tm-i386.h
===================================================================
RCS file: /cvs/src/src/gdb/config/i386/tm-i386.h,v
retrieving revision 1.2
diff -u -p -r1.2 tm-i386.h
--- config/i386/tm-i386.h 2000/02/29 13:28:24 1.2
+++ config/i386/tm-i386.h 2000/03/03 15:00:49
@@ -1,5 +1,5 @@
/* Macro definitions for GDB on an Intel i[345]86.
- Copyright (C) 1995, 1996 Free Software Foundation, Inc.
+ Copyright (C) 1995, 1996, 2000 Free Software Foundation, Inc.
This file is part of GDB.
@@ -28,6 +28,19 @@ struct type;
#define TARGET_BYTE_ORDER LITTLE_ENDIAN
+/* The format used for `long double' on almost all i386 targets is the
+ i387 extended floating-point format. In fact, of all targets in the
+ GCC 2.95 tree, only OSF/1 does it different, and insists on having
+ a `long double' that's not `long' at all. */
+
+#define TARGET_LONG_DOUBLE_FORMAT &floatformat_i387_ext
+
+/* Although the i386 extended floating-point has only 80 significant
+ bits, a `long double' actually takes up 96, probably to enforce
+ alignment. */
+
+#define TARGET_LONG_DOUBLE_BITS 96
+
/* Used for example in valprint.c:print_floating() to enable checking
for NaN's */
@@ -229,7 +242,7 @@ extern int i386_register_virtual_size[];
#define REGISTER_VIRTUAL_TYPE(N) \
(((N) == PC_REGNUM || (N) == FP_REGNUM || (N) == SP_REGNUM) \
? lookup_pointer_type (builtin_type_void) \
- : IS_FP_REGNUM(N) ? builtin_type_double \
+ : IS_FP_REGNUM(N) ? builtin_type_long_double \
: IS_SSE_REGNUM(N) ? builtin_type_v4sf \
: builtin_type_int)
@@ -239,25 +252,22 @@ extern int i386_register_virtual_size[];
that SSE registers need conversion. Even if we can't find a
counterexample, this is still sloppy. */
#define REGISTER_CONVERTIBLE(n) (IS_FP_REGNUM (n))
-
-/* Convert data from raw format for register REGNUM in buffer FROM
- to virtual format with type TYPE in buffer TO. */
-extern void i387_to_double (char *, char *);
+/* Convert data from raw format for register REGNUM in buffer FROM to
+ virtual format with type TYPE in buffer TO. In principle both
+ formats are identical except that the virtual format has two extra
+ bytes appended that aren't used. We set these to zero. */
#define REGISTER_CONVERT_TO_VIRTUAL(REGNUM,TYPE,FROM,TO) \
-{ \
- double val; \
- i387_to_double ((FROM), (char *)&val); \
- store_floating ((TO), TYPE_LENGTH (TYPE), val); \
-}
-
-extern void double_to_i387 (char *, char *);
-
-#define REGISTER_CONVERT_TO_RAW(TYPE,REGNUM,FROM,TO) \
-{ \
- double val = extract_floating ((FROM), TYPE_LENGTH (TYPE)); \
- double_to_i387((char *)&val, (TO)); \
-}
+ { \
+ memset ((TO), 0, TYPE_LENGTH (TYPE)); \
+ memcpy ((TO), (FROM), FPU_REG_RAW_SIZE); \
+ }
+
+/* Convert data from virtual format with type TYPE in buffer FROM to
+ raw format for register REGNUM in buffer TO. Simply omit the two
+ unused bytes. */
+#define REGISTER_CONVERT_TO_RAW(TYPE,REGNUM,FROM,TO) \
+ memcpy ((TO), (FROM), FPU_REG_RAW_SIZE)
/* Print out the i387 floating point state. */
#ifdef HAVE_I387_REGS
From msnyder@cygnus.com Sat Apr 01 00:00:00 2000
From: Michael Snyder <msnyder@cygnus.com>
To: "H . J . Lu" <hjl@lucon.org>
Cc: Mark Kettenis <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: <38C69870.709F@cygnus.com>
References: <20000307120800.A27315@valinux.com> <200003080058.e280wga00453@delius.kettenis.local> <20000307170321.A884@lucon.org> <200003080119.e281Jul00524@delius.kettenis.local> <20000307173547.A1068@lucon.org>
X-SW-Source: 2000-q1/msg00610.html
Content-length: 1507
H . J . Lu wrote:
>
> On Wed, Mar 08, 2000 at 02:19:56AM +0100, Mark Kettenis wrote:
> > Date: Tue, 7 Mar 2000 17:03:21 -0800
> > From: "H . J . Lu" <hjl@lucon.org>
> > Cc: gdb-patches@sourceware.cygnus.com, gdb@sourceware.cygnus.com
> > Content-Type: text/plain; charset=us-ascii
> >
> > > HJ, please stop wasting your time pushing this patch. The patch has
> > > several bad points, that you cannot fix without considerable changes
> > > to the way solib.c handles and caches the link map.
> >
> > I just pointed out gdb needed to check the unloaded DSOs when handling
> > the BPSTAT_WHAT_CHECK_SHLIBS and BPSTAT_WHAT_CHECK_SHLIBS_RESUME_FROM_HOOK
> > events. It is a serious bug to me and it should be fixed in 5.0. I
> > don't care how it is fixed.
> >
> > But I, and I hope most of the other GDB maintainers, do care how it is
> > fixed!
>
> That is fine with me as long as it is fixed in 5.0. There is no excuse
> not to get gdb to work with dlclose. "I don't like the way it fixes the
> bug" doesn't count unless you can provide a different approach. I
> think it is unreasonable to have a perfect fix for every bug. We can
> work a better one after 5.0 if we don't have the time now.
I'm sorry, but I have to disagree. I'm not addressing your
patch in particular, but there are many "fixes" that are
worse than no fix at all. In fact, GDB is full of them,
to our (the maintainers) daily regret. There is never time
to fix it right the second time.
Michael
From hjl@lucon.org Sat Apr 01 00:00:00 2000
From: "H . J . Lu" <hjl@lucon.org>
To: Michael Snyder <msnyder@cygnus.com>
Cc: Mark Kettenis <kettenis@wins.uva.nl>, gdb@sourceware.cygnus.com
Subject: Re: lin-thread cannot handle thread exit
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <20000307161609.B485@lucon.org>
References: <200003031635.e23GZwi00372@delius.kettenis.local> <38C59074.2D7C@cygnus.com>
X-SW-Source: 2000-q1/msg00574.html
Content-length: 527
On Tue, Mar 07, 2000 at 03:27:48PM -0800, Michael Snyder wrote:
> I appreciate your helping to find problems with it, and
> I'd like to know what else in the code you regard as a
> "loose end". One of my problems is that I'm not really
> an experienced writer of multi-threaded apps -- I'm just
> the person on the GDB team with the most experience with
> GDB multi-thread debugging.
There are 6 multi-thread examples under linuxthreads in glibc 2.
They will be built when you do "make check". Play with them in
gdb.
H.J.
From jtc@redback.com Sat Apr 01 00:00:00 2000
From: jtc@redback.com (J.T. Conklin)
To: Quality Quorum <qqi@world.std.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: Z-protocol errors and limts
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <5mln5btbmy.fsf@jtc.redbacknetworks.com>
References: <Pine.SGI.3.95.1000125201837.17703B-100000@world.std.com>
X-SW-Source: 2000-q1/msg00064.html
Content-length: 1524
>>>>> "Quality" == Quality Quorum <qqi@world.std.com> writes:
Quality> I have a few questions related to Z-protocol on implmentation
Quality> on the stub side:
Quality>
Quality> 1. How many soft break point has to be supported ?
Quality>
Quality> 2. How stub tells gdb that it run out of soft break points ?
Quality>
Quality> 3. If stub supports soft break points but does not support
Quality> hw (or some of hw break points), how it tells gdb about it?
You point out weaknesses in the Z/z specification.
In the debug stub I wrote, I reserved 32 nodes to store breakpoints of
all types and returned a 'EXX' code on all failures (out of breakpoint
nodes, unable to insert breakpoint, etc.).
I picked 32 breakpoints out of thin air. Based on my experiences, 32
seemed like more than enough. And if it turned out too be too small,
I could always re-compile the debug agent with a larger number.
When my stub only supported software breakpoints, it returned a 'EXX'
code for hardware breakpoint and watchpoints. GDB's remote.c handles
such a response as an error (ie. remote_insert_watchpoint(), etc. will
return -1), but I'm not sure this will result in an error message a
user will be able to interpret correctly
In retrospect, I should have given unique error codes for each
possible error so that GDB could handle errors more inteligently.
I'm addressing this, and many other shortcomings, in a replacement
protocol I've been designing the last month or so.
--jtc
--
J.T. Conklin
RedBack Networks
From grante@visi.com Sat Apr 01 00:00:00 2000
From: Grant Edwards <grante@visi.com>
To: leedh <leedh@cs.hongik.ac.kr>
Cc: gdb@sourceware.cygnus.com
Subject: Re: Question.....
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <20000329094518.C17092@visi.com>
References: <38E1B5BA.C555471B@cs.hongik.ac.kr>
X-SW-Source: 2000-q1/msg00836.html
Content-length: 705
On Wed, Mar 29, 2000 at 04:50:19PM +0900, leedh wrote:
> Now, We are willing to connect cygnus GNU debugger toolkit(host
> system-window NT) to angel debugger on EBSA-285 Board(target
> system-strongArm).
>
> But, cygnus debugger isn't connectted to target system.
You're trying to use gdb to talk to the Angel ROM monitor to
debug ARM software, right? And you can't get gdb to talk to
the Angel monitor?
1) Make sure you have a current snapshot of gdb -- something
less than two months old. Older versions of gdb don't
handle RDI/ADP as well.
2) What exactly happens when you tell gdb to coneect to the
Angle ROM monitor using the "target rdi" command?
--
Grant Edwards
grante@visi.com
From Guenther.Grau@marconicomms.com Sat Apr 01 00:00:00 2000
From: Guenther Grau <Guenther.Grau@marconicomms.com>
To: gdb@sourceware.cygnus.com
Subject: Re: Try out the patch database
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38BD61EF.81A4E3C6@marconicomms.com>
References: <200002292134.QAA10095@zwingli.cygnus.com> <1000229221310.ZM16579@ocotillo.lan> <npem9ulja1.fsf@zwingli.cygnus.com>
X-SW-Source: 2000-q1/msg00476.html
Content-length: 602
Hi,
> > > Take a look at http://sourceware.cygnus.com/gdb/contribute.html , and
> > > let me know what you think.
I have a few comments on this.
First of all: great to have a bug database online!
Second, why is the category named gdb-patches instead of gdb?
Is it not intended for people to report bugs? Is it only
for patches?
Third, (but not very important) why do you use persistant
cookies? I don't like cookies und usually disable them,
but I could live with session cookies, if you really insist
on them. But persistent cookies that last for a month are
not what I like.
Thanx,
Guenther
From kingdon@redhat.com Sat Apr 01 00:00:00 2000
From: Jim Kingdon <kingdon@redhat.com>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: Objective-C patches?
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <bn1nth9gu.fsf@rtl.cygnus.com>
References: <38CF0958.DCEDD532@doc.com> <38D5B417.64A47BC5@cygnus.com>
X-SW-Source: 2000-q1/msg00744.html
Content-length: 272
> I can't speak for Apple so don't believe what follows ...
For more background see:
http://slashdot.org/articles/00/03/17/1656240.shtml
http://webx.lists.apple.com/?13@222.lE3famDWjDu^2@.ee90f2e
If anyone wants to help, I'm sure there are ways to do that :-).
From assar@sics.se Sat Apr 01 00:00:00 2000
From: Assar Westerlund <assar@sics.se>
To: gdb@sourceware.cygnus.com
Subject: anoncvs errors?
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <5l7lgez651.fsf@assaris.sics.se>
X-SW-Source: 2000-q1/msg00191.html
Content-length: 216
Hi, I'm getting this error trying to use anonymous CVS to
:pserver:anoncvs@anoncvs.cygnus.com:/cvs/gdb.
Sorry, you don't have read/write access to the history file /cvs/gdb/CVSROOT/history
Permission denied
/assar
From kettenis@wins.uva.nl Sat Apr 01 00:00:00 2000
From: Mark Kettenis <kettenis@wins.uva.nl>
To: scottb@netwinder.org
Cc: msnyder@cygnus.com, gdb@sourceware.cygnus.com
Subject: Re: Problems with changes to linux-thread.c, gdb_wait.h
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200003192243.e2JMhPe00619@delius.kettenis.local>
References: <38D2A8E2.755D235D@netwinder.org>
X-SW-Source: 2000-q1/msg00739.html
Content-length: 482
Date: Fri, 17 Mar 2000 16:51:30 -0500
From: Scott Bambrough <scottb@netwinder.org>
Your changes listed below are causing me two problems on ARM with
glibc 2.1.3.
They're not exactly *my* changes :-(.
2000-03-17 Mark Kettenis <kettenis@gnu.org>
* gdb_wait.h: add definitions of WSETSTOP and WSETEXIT for Linux.
* linux-thread.c: Use WSETSTOP instead of W_STOPCODE.
Michael, if you rework a patch a bit, could you please put your own
name on it?
Mark
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Richard Chan <cshihpin@dso.org.sg>
Cc: gdb@sourceware.cygnus.com
Subject: Re: GDB supporting namespace std?
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38A7E3AD.5BE72E9C@cygnus.com>
References: <Pine.LNX.4.10.10001142208380.673-100000@cshihpin.dso.org.sg>
X-SW-Source: 2000-q1/msg00263.html
Content-length: 401
Chan Shih-Ping wrote:
>
> Does GDB support the use of namespace std::,
> code compiled with -fhonor-std (and an
> appropriately compiled libgcc.a) and using
> std::string s.
>
> However attempts at using
> print s.size
>
> gives messages like
> Couldn't find method string::size()
Given that no one has responded, I'd suspect the answer to be no.
It sounds like a good problem to persue.
Andrew
From shebs@apple.com Sat Apr 01 00:00:00 2000
From: Stan Shebs <shebs@apple.com>
To: Philippe De Muyter <phdm@macqel.be>
Cc: gdb@sourceware.cygnus.com
Subject: Re: gdb and iso-c
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38DBB76D.65C58273@apple.com>
References: <200003241301.OAA04488@mail.macqel.be>
X-SW-Source: 2000-q1/msg00799.html
Content-length: 1525
Philippe De Muyter wrote:
>
> Up to some years ago, gdb could be compiled by a K&R C compiler.
> Now, it can not anymore, and the change seems to be deliberate.
Dude, we discussed this over a year ago, and we even tested it by
including an deliberately ISO-only file in 4.18. Not a single
user reported this as a problem with the 4.18 release, and I was
watching closely for such a complaint.
> It seems to me that the freedom of the gdb users is now restricted compared
> to the previous versions because of the need of an ISO-C compiler instead
> of any C compiler to compile it.
>
> And I do not understand why the same reasons that apply to binutils and gcc
> do not hold for gdb. gdb, because it is better than the debugger you get
> with your operating system, is needed to bootstrap the installation of
> gas, gld, or gcc in the likely case that not everything works well
> the first time.
Indeed, I sent our results back to RMS, saying that there didn't seem to
be any reason not to change the GNU coding standards for all GNU tools,
including GCC and binutils. I don't know if he actually made the
change though.
So I think we've been sufficiently careful to ascertain whether the
modernization was justified, and there is no good reason to try to revive
K&R compat and the additional complexity that goes along with it. In fact,
I've been a little disappointed that people haven't gone through random source
files, and simplified their sources by stripping out all the now-unneeded
K&R compat bits.
Stan
From kettenis@wins.uva.nl Sat Apr 01 00:00:00 2000
From: Mark Kettenis <kettenis@wins.uva.nl>
To: nsd@cygnus.com
Cc: gdb@sourceware.cygnus.com
Subject: Re: problems with gdb
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200002121806.e1CI66F02876@delius.kettenis.local>
References: <38A47E89.3F4674B3@mozilla.org> <882mue$s0f$1@cronkite.cygnus.com>
X-SW-Source: 2000-q1/msg00245.html
Content-length: 745
From: nsd@cygnus.com (Nick Duffek)
Date: 12 Feb 2000 04:18:22 GMT
In article < 38A47E89.3F4674B3@mozilla.org >,
>There are also various problems with threads. A lot of times gdb
>won't exit after the last thread exits because it keeps trying to
>kill a process which doesn't exist any more.
I've got a similar report from elsewhere; I'll be checking into it shortly.
As I wrote in a reaction to Chris's message, this may very well be
caused by a bug in LinuxThreads. I've seen several bug-reports about
apps not exiting after the last thread finished. Apparently there is
a race of some sort (surprise, surprise), and it may very well be that
debugging with GDB just makes it more likely to trigger the race.
Mark
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: annotate.texi
2000-03-08 2:03 ` annotate.texi Eli Zaretskii
2000-04-01 0:00 ` annotate.texi Eli Zaretskii
2000-04-01 0:00 ` annotate.texi Jim Kingdon
@ 2000-04-01 0:00 ` Eli Zaretskii
2 siblings, 0 replies; 5+ messages in thread
From: Eli Zaretskii @ 2000-04-01 0:00 UTC (permalink / raw)
To: Jim Kingdon; +Cc: gdb, shebs
Jim Kingdon writes:
> > I'm trying to add some indexing whenever I can. But I suggest that
> > every manual patch be scrutinized for appropriate index entries
>
> Sounds like the voice of someone volunteering to do some scrutinization ;-).
If that's what it takes to make this happen, then yes, I do volunteer.
But I do request that this be declared as an official policy, so that
individual contributors could be requested to add the index entries,
if the manual changes are large.
Adding an index entry to a typical manual patch is really a small
nuisance. It's only when you need to add them all at once to a large
manual, only then the job becomes too large to bear.
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2000-04-01 0:00 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <200003070832.DAA14451@indy.delorie.com>
2000-04-01 0:00 ` annotate.texi Stan Shebs
2000-03-08 2:03 ` annotate.texi Eli Zaretskii
2000-04-01 0:00 ` annotate.texi Eli Zaretskii
2000-04-01 0:00 ` annotate.texi Jim Kingdon
2000-04-01 0:00 ` annotate.texi Eli Zaretskii
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox