* Re: [patch] fix for infinite recursion in lookup_symbol
[not found] <200101121935.LAA03678@scv2.apple.com>
@ 2001-01-12 12:13 ` Fernando Nasser
2001-01-17 13:09 ` Elena Zannoni
1 sibling, 0 replies; 6+ messages in thread
From: Fernando Nasser @ 2001-01-12 12:13 UTC (permalink / raw)
To: Jim Ingham; +Cc: gdb-patches, insight
Jim,
You saved my life!
This causes Insight to crash. One case I saw is that there were C++ methods
starting with "main", so the look for main to show in the Source Window would
cause a memory exhaust situation. The other case is when a the Variable Balloons
try to show some overloaded symbol and it also goes into loop.
TO THE INSIGHT LIST FOLKS WHO WERE HAVING THOSE PROBLEMS: Can you please
try Jim's patch and let us know if it fixed your problems? Thanks.
Fernando
Jim Ingham wrote:
>
> Hi, all,
>
> The following patch fixes an infinite recursion in the variable lookup
> code for C++ objects that are specified in mangled form. The old code
> would take the mangled name into lookup_symbol, unmangle it, and then in
> this bit pass the mangled name BACK to lookup_symbol, which would
> unmangle it and come right back here... Not a good thing. The bug
> crept in when lookup_symbol was broken up into lookup_symbol and
> lookup_symbol_aux, the correction is clearly what was meant.
>
> 2001-01-09 James Ingham <jingham@inghji.apple.com>
>
> * symtab.c (lookup_symbol_aux): Call lookup_symbol_aux to
> lookup a
> mangled symbol rather than recursing into lookup_symbol, since
> this
> will just re-unmangle the name & call lookup_symbol_aux -
> leading to
> an infinite recursion.
>
> Index: symtab.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/symtab.c,v
> retrieving revision 1.15
> diff -c -w -r1.15 symtab.c
> *** symtab.c 2000/09/04 08:29:25 1.15
> --- symtab.c 2001/01/12 19:29:21
> ***************
> *** 754,760 ****
> {
> /* This is a mangled variable, look it up by its
> mangled name. */
> ! return lookup_symbol (SYMBOL_NAME (msymbol), block,
> namespace, is_a_field_of_this,
> symtab);
> }
> /* There are no debug symbols for this file, or we are looking
> --- 754,760 ----
> {
> /* This is a mangled variable, look it up by its
> mangled name. */
> ! return lookup_symbol_aux (SYMBOL_NAME (msymbol), block,
> namespace, is_a_field_of_this,
> symtab);
> }
> /* There are no debug symbols for this file, or we are looking
--
Fernando Nasser
Red Hat - Toronto E-Mail: fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario M4P 2C9
From nsd@redhat.com Fri Jan 12 12:43:00 2001
From: Nick Duffek <nsd@redhat.com>
To: ac131313@cygnus.com
Cc: gdb-patches@sources.redhat.com
Subject: Re: [RFA] spelling corrections
Date: Fri, 12 Jan 2001 12:43:00 -0000
Message-id: <200101122051.f0CKpYT04311@rtl.cygnus.com>
References: <3A5ED35A.B41E9304@cygnus.com>
X-SW-Source: 2001-01/msg00094.html
Content-length: 70
On 12-Jan-2001, Andrew Cagney wrote:
>yes.
Thanks, committed.
Nick
From nsd@redhat.com Fri Jan 12 12:48:00 2001
From: Nick Duffek <nsd@redhat.com>
To: ac131313@cygnus.com
Cc: gdb-patches@sources.redhat.com
Subject: Re: [RFA] gdbarch.sh: multi-arch PARM_BOUNDARY
Date: Fri, 12 Jan 2001 12:48:00 -0000
Message-id: <200101122055.f0CKtkD04372@rtl.cygnus.com>
References: <3A5EF5A4.7C7EF047@cygnus.com>
X-SW-Source: 2001-01/msg00095.html
Content-length: 299
On 12-Jan-2001, Andrew Cagney wrote:
>This is a new architecture method.
No, it's an existing method, I'm just multi-arching it.
>Can you explain its intended purpose.
From gdbint.texinfo:
If non-zero, round arguments to a boundary of this many bits before
pushing them on the stack.
Nick
From nsd@redhat.com Fri Jan 12 13:32:00 2001
From: Nick Duffek <nsd@redhat.com>
To: ac131313@cygnus.com
Cc: gdb-patches@sources.redhat.com
Subject: Re: [RFA] new BASEREG_ADDRESS macro
Date: Fri, 12 Jan 2001 13:32:00 -0000
Message-id: <200101122140.f0CLeYF04411@rtl.cygnus.com>
References: <3A5EF913.DD51B9E2@cygnus.com>
X-SW-Source: 2001-01/msg00096.html
Content-length: 370
On 12-Jan-2001, Andrew Cagney wrote:
>Can you think of a name other than BASEREG_ADDRESS() that better reflects
>the transformation being performed?
>my first guess was that BASEREG_ADDRESS returns the address of the
>register BASE in, at or near ``addr''.
Yes, I can see how one might think that. How about
ADJUST_BASEREG_ADDRESS? Other suggestions welcome.
Nick
From nsd@redhat.com Fri Jan 12 13:36:00 2001
From: Nick Duffek <nsd@redhat.com>
To: ac131313@cygnus.com
Cc: gdb-patches@sources.redhat.com
Subject: Re: [RFA] New register definition interface
Date: Fri, 12 Jan 2001 13:36:00 -0000
Message-id: <200101122144.f0CLi0104421@rtl.cygnus.com>
References: <3A5F09B3.93555F06@cygnus.com>
X-SW-Source: 2001-01/msg00097.html
Content-length: 399
On 12-Jan-2001, Andrew Cagney wrote:
>At a guess the cli/* change is independant of the file reg.c.
It depends on regs.c, but not vice versa. So yes, it could have been a
separate add-on patch.
>Assuming it is it should go in per fixes from Fernando and (private)
>notes from me.
As Fernando said, he's approved it, but I'd be interested in hearing
whatever additional comments you have.
Nick
From jingham@apple.com Fri Jan 12 14:03:00 2001
From: Jim Ingham <jingham@apple.com>
To: Daniel Berlin <dberlin@redhat.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [patch] fix for infinite recursion in lookup_symbol
Date: Fri, 12 Jan 2001 14:03:00 -0000
Message-id: <200101122203.OAA20207@scv1.apple.com>
References: <Pine.LNX.4.10.10101121507570.8389-100000@www.cgsoftware.com>
X-SW-Source: 2001-01/msg00098.html
Content-length: 1351
Daniel,
Well, while you are waiting, it might be nice to check in fixes for some
of these, since they are pretty simple fixes, and the bugs are pretty
annoying (in this case it causes gdb to crash, and people tend to REALLY
hate it when their debugger crashes). It wasted a couple of days of my
time chasing it down, and apparently a couple of days of Fernando's time
as well.
Jim
On Friday, January 12, 2001, at 12:10 PM, Daniel Berlin wrote:
>
>
> On Fri, 12 Jan 2001, Jim Ingham wrote:
>
>> Hi, all,
>>
>> The following patch fixes an infinite recursion in the variable lookup
>> code for C++ objects that are specified in mangled form. The old code
>> would take the mangled name into lookup_symbol, unmangle it, and then
>> in
>> this bit pass the mangled name BACK to lookup_symbol, which would
>> unmangle it and come right back here... Not a good thing. The bug
>> crept in when lookup_symbol was broken up into lookup_symbol and
>> lookup_symbol_aux, the correction is clearly what was meant.
>
> This was already known, and we are still waiting for Jim Blandy to
> make a
> decision whether we should revert the binary searching symbol lookup for
> C++ stuff or not.
> If we decide to stay with the non-linear symbol lookup, i'll fix the
> bugs,
> as i already have patches for most of them (there aren't many).
>
> --Dan
>
From dberlin@redhat.com Fri Jan 12 17:52:00 2001
From: Daniel Berlin <dberlin@redhat.com>
To: Jim Ingham <jingham@apple.com>
Cc: Daniel Berlin <dberlin@redhat.com>, <gdb-patches@sources.redhat.com>
Subject: Re: [patch] fix for infinite recursion in lookup_symbol
Date: Fri, 12 Jan 2001 17:52:00 -0000
Message-id: <Pine.LNX.4.31.0101122049230.14785-100000@www.cgsoftware.com>
References: <200101122203.OAA20207@scv1.apple.com>
X-SW-Source: 2001-01/msg00099.html
Content-length: 873
On Fri, 12 Jan 2001, Jim Ingham wrote:
> Daniel,
>
> Well, while you are waiting, it might be nice to check in fixes for some
> of these, since they are pretty simple fixes, and the bugs are pretty
> annoying (in this case it causes gdb to crash, and people tend to REALLY
> hate it when their debugger crashes).
I can't without approval from Jim anyway. I'm still waiting for approval
for some simple changes I submitted a few weeks ago to be approved as
well, i don't want to juggle that many outstanding patches.
> It wasted a couple of days of my
> time chasing it down, and apparently a couple of days of Fernando's time
> as well.
Sorry to hear that. If you look back, ti was reported in either november
or december, and a huge discussion ensued.
Wish there was something more I could do, but it's not my area of
maintenance, so all I can do is submit patches.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [patch] fix for infinite recursion in lookup_symbol
[not found] <200101121935.LAA03678@scv2.apple.com>
2001-01-12 12:13 ` [patch] fix for infinite recursion in lookup_symbol Fernando Nasser
@ 2001-01-17 13:09 ` Elena Zannoni
[not found] ` <20010117161229.B15404@redhat.com>
1 sibling, 1 reply; 6+ messages in thread
From: Elena Zannoni @ 2001-01-17 13:09 UTC (permalink / raw)
To: Jim Ingham, fnasser; +Cc: gdb-patches
I would like to see this in. There are too many divergences already.
Fernando, JimI can one of you commit this?
Unless there is some opposition from JimB. (if he replies within say,
5 hours :-).
Thanks
Elena
Jim Ingham writes:
> Hi, all,
>
> The following patch fixes an infinite recursion in the variable lookup
> code for C++ objects that are specified in mangled form. The old code
> would take the mangled name into lookup_symbol, unmangle it, and then in
> this bit pass the mangled name BACK to lookup_symbol, which would
> unmangle it and come right back here... Not a good thing. The bug
> crept in when lookup_symbol was broken up into lookup_symbol and
> lookup_symbol_aux, the correction is clearly what was meant.
>
> 2001-01-09 James Ingham <jingham@inghji.apple.com>
>
> * symtab.c (lookup_symbol_aux): Call lookup_symbol_aux to
> lookup a
> mangled symbol rather than recursing into lookup_symbol, since
> this
> will just re-unmangle the name & call lookup_symbol_aux -
> leading to
> an infinite recursion.
>
>
> Index: symtab.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/symtab.c,v
> retrieving revision 1.15
> diff -c -w -r1.15 symtab.c
> *** symtab.c 2000/09/04 08:29:25 1.15
> --- symtab.c 2001/01/12 19:29:21
> ***************
> *** 754,760 ****
> {
> /* This is a mangled variable, look it up by its
> mangled name. */
> ! return lookup_symbol (SYMBOL_NAME (msymbol), block,
> namespace, is_a_field_of_this,
> symtab);
> }
> /* There are no debug symbols for this file, or we are looking
> --- 754,760 ----
> {
> /* This is a mangled variable, look it up by its
> mangled name. */
> ! return lookup_symbol_aux (SYMBOL_NAME (msymbol), block,
> namespace, is_a_field_of_this,
> symtab);
> }
> /* There are no debug symbols for this file, or we are looking
>
From cgf@redhat.com Wed Jan 17 13:12:00 2001
From: Christopher Faylor <cgf@redhat.com>
To: gdb-patches@sources.redhat.com
Subject: Re: [patch] fix for infinite recursion in lookup_symbol
Date: Wed, 17 Jan 2001 13:12:00 -0000
Message-id: <20010117161229.B15404@redhat.com>
References: <200101121935.LAA03678@scv2.apple.com> <14950.2567.654425.826984@kwikemart.cygnus.com>
X-SW-Source: 2001-01/msg00158.html
Content-length: 754
On Wed, Jan 17, 2001 at 04:09:27PM -0500, Elena Zannoni wrote:
>
>I would like to see this in. There are too many divergences already.
>
>Fernando, JimI can one of you commit this?
>
>Unless there is some opposition from JimB. (if he replies within say,
>5 hours :-).
Can I just suggest that we check it in now and let JimB yell if he
disapproves? I think enough experienced eyes have looked at this for
there to be a very small chance that the patch is wrong.
What does everyone think about setting a "vote system" for this kind
of contingency? We could say that the vote of four gdb engineers with
write-after-approval == one maintainer with the maintainer having
absolute authority to remove patches that they think are incorrect,
of course.
cgf
From nsd@redhat.com Wed Jan 17 13:17:00 2001
From: Nick Duffek <nsd@redhat.com>
To: ac131313@cygnus.com
Cc: gdb-patches@sources.redhat.com
Subject: Re: [RFA] New register definition interface
Date: Wed, 17 Jan 2001 13:17:00 -0000
Message-id: <200101172125.f0HLPDs01986@rtl.cygnus.com>
References: <3A64CBAE.D480ADB7@cygnus.com>
X-SW-Source: 2001-01/msg00159.html
Content-length: 1086
On 17-Jan-2001, Andrew Cagney wrote:
>> That looks good to me. It's very similar to what regs.c does, except that
>> it calls set_gdbarch_register_list() instead of set_gdbarch_data().
>The difference is that the data is kept private to the regs.c file
>(those interfaces again). It isn't possible for external code to go
>grubbing around in internals when you're not looking.
Yes. I wrote:
>I can deal with the memory waste by:
>
> 1. ignoring it;
> 2. using regs.c's approach with e.g. CLIREGS_INTERNAL instead of
> REGISTER_LIST;
> 3. implementing set_gdbarch_data().
>
>I'd prefer 2 or 3. Do you have a preference?
If I understand correctly, you're expressing a preference for 3. I'll
look into implementing that.
On 17-Jan-2001, Andrew Cagney wrote:
>The nice thing about REGISTER_MODULE_INSTALLED_P() is that it is so
>informative that the caller can conclude nothing about the actual
>module. This is a good thing :-)
I don't understand whether that means "regcache.c is active" or "regs.c is
active". I'd rather use REGCACHE_MODULE_ACTIVE_P(), okay?
Nick
From dberlin@redhat.com Wed Jan 17 13:28:00 2001
From: Daniel Berlin <dberlin@redhat.com>
To: Christopher Faylor <cgf@redhat.com>, gdb-patches@sources.redhat.com
Subject: Re: [patch] fix for infinite recursion in lookup_symbol
Date: Wed, 17 Jan 2001 13:28:00 -0000
Message-id: <8890000.979766696@dynamic-addr-83-177.resnet.rochester.edu>
References: <20010117161229.B15404@redhat.com>
X-SW-Source: 2001-01/msg00160.html
Content-length: 1162
--On Wednesday, January 17, 2001 16:12:29 -0500 Christopher Faylor
<cgf@redhat.com> wrote:
> On Wed, Jan 17, 2001 at 04:09:27PM -0500, Elena Zannoni wrote:
>>
>> I would like to see this in. There are too many divergences already.
>>
>> Fernando, JimI can one of you commit this?
>>
>> Unless there is some opposition from JimB. (if he replies within say,
>> 5 hours :-).
>
> Can I just suggest that we check it in now and let JimB yell if he
> disapproves? I think enough experienced eyes have looked at this for
> there to be a very small chance that the patch is wrong.
>
> What does everyone think about setting a "vote system" for this kind
> of contingency? We could say that the vote of four gdb engineers with
> write-after-approval == one maintainer with the maintainer having
> absolute authority to remove patches that they think are incorrect,
> of course.
>
> cgf
I like this idea.
after all, patches can always be reverted or backed out if necessary.
It's unlikely this will happen anyway, since maintainers generally got to
be maintainers from submitting good patches, and having expertise in GDB
(except me, I slept my way there).
--Dan
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [patch] fix for infinite recursion in lookup_symbol
[not found] ` <20010117161229.B15404@redhat.com>
@ 2001-01-17 13:55 ` Fernando Nasser
0 siblings, 0 replies; 6+ messages in thread
From: Fernando Nasser @ 2001-01-17 13:55 UTC (permalink / raw)
To: Christopher Faylor; +Cc: gdb-patches
Christopher Faylor wrote:
>
> On Wed, Jan 17, 2001 at 04:09:27PM -0500, Elena Zannoni wrote:
> >
> >I would like to see this in. There are too many divergences already.
> >
> >Fernando, JimI can one of you commit this?
> >
> >Unless there is some opposition from JimB. (if he replies within say,
> >5 hours :-).
>
> Can I just suggest that we check it in now and let JimB yell if he
> disapproves? I think enough experienced eyes have looked at this for
> there to be a very small chance that the patch is wrong.
>
Yes, it is causing lots of trouble everywhere. I will check it in and
leave it for Jim Blandy to decide if it stays or is reverted.
> What does everyone think about setting a "vote system" for this kind
> of contingency? We could say that the vote of four gdb engineers with
> write-after-approval == one maintainer with the maintainer having
> absolute authority to remove patches that they think are incorrect,
> of course.
>
It is a good suggestion.
We do need some mechanism to deal with these cases.
--
Fernando Nasser
Red Hat - Toronto E-Mail: fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario M4P 2C9
From taylor@cygnus.com Wed Jan 17 13:57:00 2001
From: David Taylor <taylor@cygnus.com>
To: Christopher Faylor <cgf@redhat.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [patch] fix for infinite recursion in lookup_symbol
Date: Wed, 17 Jan 2001 13:57:00 -0000
Message-id: <200101172157.QAA21576@texas.cygnus.com>
X-SW-Source: 2001-01/msg00164.html
Content-length: 2517
Date: Wed, 17 Jan 2001 16:12:29 -0500
From: Christopher Faylor <cgf@redhat.com>
On Wed, Jan 17, 2001 at 04:09:27PM -0500, Elena Zannoni wrote:
>
>I would like to see this in. There are too many divergences already.
>
>Fernando, JimI can one of you commit this?
>
>Unless there is some opposition from JimB. (if he replies within say,
>5 hours :-).
Radical Idea: You might try calling him...
[I say that because I know that several of the people participating in
this discussion have Jim's phone number.]
There is no guarantee that he will even see the discussion within 5
hours, much less have looked over the posting and approved of it.
From Jim's lack of response, I would guess that:
. he's on vacation, or
. he's not reading email, or
. he's no longer reading gdb-patches
I tried calling him and got voice mail, so it wouldn't surprise me if
he was on vacation or otherwise occupied. I left him a message.
Can I just suggest that we check it in now and let JimB yell if he
disapproves? I think enough experienced eyes have looked at this for
there to be a very small chance that the patch is wrong.
Elena, if I'm reading the MAINTAINERS file correctly, you are a backup
maintainer for the generic symtab stuff -- so, your approval should
suffice (unless you feel uncomfortable with it and want Jim to look it
over, too).
What does everyone think about setting a "vote system" for this kind
of contingency? We could say that the vote of four gdb engineers with
write-after-approval == one maintainer with the maintainer having
absolute authority to remove patches that they think are incorrect,
of course.
cgf
I don't think we need such a system.
For the generic symtab stuff, the MAINTAINERS file says that Jim
Blandy is the primary and Elena Zannoni is a backup maintainer. So,
if Elena approved it, it can go in. And Daniel Berlin can just check
it in. Ditto if any "Blanket Write Privs" maintainer has approved it.
[Since any Blanket Write Privs maintainer can just check it in, I
would assume that they could also just "approve it" and then leave the
actual checkin task to the person that submitted it -- provided he/she
has checkin privileges.]
In general, I think that if a maintainer is unresponsive, then that
should be dealt with -- whether it's by politely asking him/her to be
more responsive, by nagging, by adding additional maintainers to some
areas, by replacing the maintainer, or something else.
From ezannoni@cygnus.com Wed Jan 17 14:15:00 2001
From: Elena Zannoni <ezannoni@cygnus.com>
To: David Taylor <taylor@cygnus.com>
Cc: Christopher Faylor <cgf@redhat.com>, gdb-patches@sources.redhat.com
Subject: Re: [patch] fix for infinite recursion in lookup_symbol
Date: Wed, 17 Jan 2001 14:15:00 -0000
Message-id: <14950.6503.362049.921003@kwikemart.cygnus.com>
References: <200101172157.QAA21576@texas.cygnus.com>
X-SW-Source: 2001-01/msg00165.html
Content-length: 2440
David Taylor writes:
> >Unless there is some opposition from JimB. (if he replies within say,
> >5 hours :-).
>
That was a joke!
Elena
> Radical Idea: You might try calling him...
>
> [I say that because I know that several of the people participating in
> this discussion have Jim's phone number.]
>
> There is no guarantee that he will even see the discussion within 5
> hours, much less have looked over the posting and approved of it.
>
> >From Jim's lack of response, I would guess that:
>
> . he's on vacation, or
>
> . he's not reading email, or
>
> . he's no longer reading gdb-patches
>
> I tried calling him and got voice mail, so it wouldn't surprise me if
> he was on vacation or otherwise occupied. I left him a message.
>
> Can I just suggest that we check it in now and let JimB yell if he
> disapproves? I think enough experienced eyes have looked at this for
> there to be a very small chance that the patch is wrong.
>
> Elena, if I'm reading the MAINTAINERS file correctly, you are a backup
> maintainer for the generic symtab stuff -- so, your approval should
> suffice (unless you feel uncomfortable with it and want Jim to look it
> over, too).
>
> What does everyone think about setting a "vote system" for this kind
> of contingency? We could say that the vote of four gdb engineers with
> write-after-approval == one maintainer with the maintainer having
> absolute authority to remove patches that they think are incorrect,
> of course.
>
> cgf
>
> I don't think we need such a system.
>
> For the generic symtab stuff, the MAINTAINERS file says that Jim
> Blandy is the primary and Elena Zannoni is a backup maintainer. So,
> if Elena approved it, it can go in. And Daniel Berlin can just check
> it in. Ditto if any "Blanket Write Privs" maintainer has approved it.
>
> [Since any Blanket Write Privs maintainer can just check it in, I
> would assume that they could also just "approve it" and then leave the
> actual checkin task to the person that submitted it -- provided he/she
> has checkin privileges.]
>
> In general, I think that if a maintainer is unresponsive, then that
> should be dealt with -- whether it's by politely asking him/her to be
> more responsive, by nagging, by adding additional maintainers to some
> areas, by replacing the maintainer, or something else.
>
From jtc@redback.com Wed Jan 17 15:18:00 2001
From: jtc@redback.com (J.T. Conklin)
To: gdb-patches@sourceware.cygnus.com
Subject: [PATCH]: tweak netbsd/m68k config
Date: Wed, 17 Jan 2001 15:18:00 -0000
Message-id: <5mn1cp4vjv.fsf@jtc.redback.com>
X-SW-Source: 2001-01/msg00166.html
Content-length: 5038
I have committed the enclosed patch.
Due to a missing header file, the netbsd/m68k target didn't compile.
While fixing that, I fixed structure returns and some leftover cruft
in i386nbsd-tdep.c.
I noticed when preparing this message that I missed documenting the
change to BKP_VECTOR and REMOTE_BKP_VECTOR, so I'll be updating the
ChangeLog file accordingly.
--jtc
001-01-17 J.T. Conklin <jtc@redback.com>
* config/m68k/tm-nbsd.h (USE_STRUCT_CONVENTION): Define.
* config/m68k/nbsd.mt (TDEPFILES): Add m68knbsd-tdep.o.
* m68knbsd-tdep.c: New file.
* i386nbsd-tdep.c: Remove #if 0'd out #includes.
* m68knbsd-nat.c: #include gdbcore.h.
Index: i386nbsd-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/i386nbsd-tdep.c,v
retrieving revision 1.1
retrieving revision 1.2
diff -c -r1.1 -r1.2
*** i386nbsd-tdep.c 2000/09/07 20:08:40 1.1
--- i386nbsd-tdep.c 2001/01/17 23:07:15 1.2
***************
*** 21,34 ****
#include "defs.h"
#include "gdbtypes.h"
- #if 0
- #include <sys/types.h>
- #include <sys/ptrace.h>
- #include <machine/reg.h>
- #include <machine/frame.h>
- #include "inferior.h"
- #include "gdbcore.h" /* for registers_fetched() */
- #endif
int
i386nbsd_use_struct_convention (int gcc_p, struct type *type)
--- 21,26 ----
Index: config/m68k/nbsd.mt
===================================================================
RCS file: /cvs/src/src/gdb/config/m68k/nbsd.mt,v
retrieving revision 1.4
retrieving revision 1.5
diff -c -r1.4 -r1.5
*** nbsd.mt 2000/12/08 19:46:06 1.4
--- nbsd.mt 2001/01/17 23:07:15 1.5
***************
*** 1,5 ****
# Target: Motorola m68k running NetBSD
! TDEPFILES= m68k-tdep.o solib.o solib-svr4.o
TM_FILE= tm-nbsd.h
GDBSERVER_DEPFILES= low-nbsd.o
--- 1,5 ----
# Target: Motorola m68k running NetBSD
! TDEPFILES= m68k-tdep.o m68knbsd-tdep.o solib.o solib-svr4.o
TM_FILE= tm-nbsd.h
GDBSERVER_DEPFILES= low-nbsd.o
Index: config/m68k/tm-nbsd.h
===================================================================
RCS file: /cvs/src/src/gdb/config/m68k/tm-nbsd.h,v
retrieving revision 1.1
retrieving revision 1.2
diff -c -r1.1 -r1.2
*** tm-nbsd.h 1999/04/16 01:34:22 1.1
--- tm-nbsd.h 2001/01/17 23:07:15 1.2
***************
*** 1,21 ****
/* Macro definitions for i386 running under NetBSD.
Copyright 1994 Free Software Foundation, Inc.
! This file is part of GDB.
! This program is free software; you can redistribute it and/or modify
! it under the terms of the GNU General Public License as published by
! the Free Software Foundation; either version 2 of the License, or
! (at your option) any later version.
!
! This program is distributed in the hope that it will be useful,
! but WITHOUT ANY WARRANTY; without even the implied warranty of
! MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
! GNU General Public License for more details.
!
! You should have received a copy of the GNU General Public License
! along with this program; if not, write to the Free Software
! Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. */
#ifndef TM_NBSD_H
#define TM_NBSD_H
--- 1,22 ----
/* Macro definitions for i386 running under NetBSD.
Copyright 1994 Free Software Foundation, Inc.
! This file is part of GDB.
! This program is free software; you can redistribute it and/or modify
! it under the terms of the GNU General Public License as published by
! the Free Software Foundation; either version 2 of the License, or
! (at your option) any later version.
!
! This program is distributed in the hope that it will be useful,
! but WITHOUT ANY WARRANTY; without even the implied warranty of
! MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
! GNU General Public License for more details.
!
! You should have received a copy of the GNU General Public License
! along with this program; if not, write to the Free Software
! Foundation, Inc., 59 Temple Place - Suite 330,
! Boston, MA 02111-1307, USA. */
#ifndef TM_NBSD_H
#define TM_NBSD_H
***************
*** 25,33 ****
/* Define BPT_VECTOR if it is different than the default.
This is the vector number used by traps to indicate a breakpoint. */
- #define BPT_VECTOR 0x2
-
/* Address of end of stack space. */
#define STACK_END_ADDR USRSTACK
--- 26,34 ----
/* Define BPT_VECTOR if it is different than the default.
This is the vector number used by traps to indicate a breakpoint. */
+ #define BPT_VECTOR 0xf
+ #define REMOTE_BPT_VECTOR 0xf
/* Address of end of stack space. */
#define STACK_END_ADDR USRSTACK
***************
*** 37,41 ****
--- 38,46 ----
#include "m68k/tm-m68k.h"
#include "tm-nbsd.h"
+
+ extern use_struct_convention_fn m68knbsd_use_struct_convention;
+ #define USE_STRUCT_CONVENTION(gcc_p, type) \
+ m68knbsd_use_struct_convention(gcc_p, type)
#endif /* TM_NBSD_H */
--
J.T. Conklin
RedBack Networks
From ac131313@cygnus.com Wed Jan 17 17:30:00 2001
From: Andrew Cagney <ac131313@cygnus.com>
To: GDB Patches <gdb-patches@sourceware.cygnus.com>
Subject: [rfc] FREEIF -> xfree()
Date: Wed, 17 Jan 2001 17:30:00 -0000
Message-id: <3A6646C0.CDAFD1A4@cygnus.com>
X-SW-Source: 2001-01/msg00167.html
Content-length: 1862
Continuing the move to xfree().
Comments?
Andrew
Thu Jan 18 12:25:06 2001 Andrew Cagney <cagney@b1.cygnus.com>
* varobj.c (FREEIF): Delete macro.
(varobj_set_value, free_variable): Replace FREEIF with ``xfree''
call.
Index: varobj.c
===================================================================
RCS file: /cvs/src/src/gdb/varobj.c,v
retrieving revision 1.14
diff -p -r1.14 varobj.c
*** varobj.c 2000/12/15 01:01:51 1.14
--- varobj.c 2001/01/18 01:27:58
*************** static int rootcount = 0; /* number of r
*** 391,401 ****
/* Pointer to the varobj hash table (built at run time) */
static struct vlist **varobj_table;
- #if defined(FREEIF)
- #undef FREEIF
- #endif
- #define FREEIF(x) if (x != NULL) free((char *) (x))
-
/* Is the variable X one of our "fake" children? */
#define CPLUS_FAKE_CHILD(x) \
((x) != NULL && (x)->type == NULL && (x)->value == NULL)
--- 391,396 ----
*************** varobj_set_value (struct varobj *var, ch
*** 788,794 ****
if (!gdb_evaluate_expression (exp, &value))
{
/* We cannot proceed without a valid expression. */
! FREEIF (exp);
return 0;
}
--- 783,789 ----
if (!gdb_evaluate_expression (exp, &value))
{
/* We cannot proceed without a valid expression. */
! xfree (exp);
return 0;
}
*************** free_variable (struct varobj *var)
*** 1353,1364 ****
if (var->root->rootvar == var)
{
free_current_contents ((char **) &var->root->exp);
! FREEIF (var->root);
}
! FREEIF (var->name);
! FREEIF (var->obj_name);
! FREEIF (var);
}
static void
--- 1348,1359 ----
if (var->root->rootvar == var)
{
free_current_contents ((char **) &var->root->exp);
! xfree (var->root);
}
! xfree (var->name);
! xfree (var->obj_name);
! xfree (var);
}
static void
From ac131313@cygnus.com Wed Jan 17 17:58:00 2001
From: Andrew Cagney <ac131313@cygnus.com>
To: GDB Patches <gdb-patches@sourceware.cygnus.com>
Subject: [rfc] Replace STRCMP() with strcmp()
Date: Wed, 17 Jan 2001 17:58:00 -0000
Message-id: <3A664D3D.62952710@cygnus.com>
X-SW-Source: 2001-01/msg00168.html
Content-length: 7933
Comments?
Unlike STREQ() and STREQN(), this is one is a text substitution so
should be ok :-)
Andrew
Thu Jan 18 12:48:04 2001 Andrew Cagney <cagney@b1.cygnus.com>
* defs.h (STRCMP): Delete macro.
* objfiles.c (objfile_relocate): Replace STRCMP with call to
strcmp.
* symtab.c (lookup_partial_symbol, lookup_block_symbol): Ditto.
* symfile.c (compare_symbols): Ditto.
* standalone.c (open): Ditto.
* remote-es.c (verify_break): Ditto.
* cli/cli-decode.c (add_cmd, add_show_from_set): Ditto.
* symfile.c (compare_psymbols): Delete comment refering to STRCMP.
Index: defs.h
===================================================================
RCS file: /cvs/src/src/gdb/defs.h,v
retrieving revision 1.33
diff -p -r1.33 defs.h
*** defs.h 2000/12/15 01:01:46 1.33
--- defs.h 2001/01/18 01:54:18
*************** typedef bfd_vma CORE_ADDR;
*** 148,154 ****
issue is found that we spend the effort on algorithmic
optimizations than micro-optimizing.'' J.T. */
- #define STRCMP(a,b) (*(a) == *(b) ? strcmp ((a), (b)) : (int)*(a) - (int)*(b))
#define STREQ(a,b) (*(a) == *(b) ? !strcmp ((a), (b)) : 0)
#define STREQN(a,b,c) (*(a) == *(b) ? !strncmp ((a), (b), (c)) : 0)
--- 148,153 ----
Index: objfiles.c
===================================================================
RCS file: /cvs/src/src/gdb/objfiles.c,v
retrieving revision 1.12
diff -p -r1.12 objfiles.c
*** objfiles.c 2000/12/15 01:01:48 1.12
--- objfiles.c 2001/01/18 01:54:24
*************** objfile_relocate (struct objfile *objfil
*** 584,590 ****
else if (SYMBOL_CLASS (sym) == LOC_CONST
&& SYMBOL_NAMESPACE (sym) == LABEL_NAMESPACE
! && STRCMP (SYMBOL_NAME (sym), MIPS_EFI_SYMBOL_NAME) == 0)
ecoff_relocate_efi (sym, ANOFFSET (delta,
s->block_line_section));
#endif
--- 584,590 ----
else if (SYMBOL_CLASS (sym) == LOC_CONST
&& SYMBOL_NAMESPACE (sym) == LABEL_NAMESPACE
! && strcmp (SYMBOL_NAME (sym), MIPS_EFI_SYMBOL_NAME) == 0)
ecoff_relocate_efi (sym, ANOFFSET (delta,
s->block_line_section));
#endif
Index: remote-es.c
===================================================================
RCS file: /cvs/src/src/gdb/remote-es.c,v
retrieving revision 1.7
diff -p -r1.7 remote-es.c
*** remote-es.c 2000/12/15 01:01:48 1.7
--- remote-es.c 2001/01/18 01:54:26
*************** verify_break (int vec)
*** 1151,1157 ****
{
memory_error (status, memaddress);
}
! return (STRCMP (instr, buf));
}
return (-1);
}
--- 1151,1157 ----
{
memory_error (status, memaddress);
}
! return (strcmp (instr, buf));
}
return (-1);
}
Index: standalone.c
===================================================================
RCS file: /cvs/src/src/gdb/standalone.c,v
retrieving revision 1.3
diff -p -r1.3 standalone.c
*** standalone.c 2000/07/30 01:48:27 1.3
--- standalone.c 2001/01/18 01:54:29
*************** open (char *filename, int modes)
*** 145,151 ****
for (next = files_start; *(int *) next; next += *(int *) next)
{
! if (!STRCMP (next + 4, filename))
{
sourcebeg = next + 4 + strlen (next + 4) + 1;
sourcebeg = (char *) (((int) sourcebeg + 3) & (-4));
--- 145,151 ----
for (next = files_start; *(int *) next; next += *(int *) next)
{
! if (!strcmp (next + 4, filename))
{
sourcebeg = next + 4 + strlen (next + 4) + 1;
sourcebeg = (char *) (((int) sourcebeg + 3) & (-4));
Index: symfile.c
===================================================================
RCS file: /cvs/src/src/gdb/symfile.c,v
retrieving revision 1.22
diff -p -r1.22 symfile.c
*** symfile.c 2000/12/15 01:01:50 1.22
--- symfile.c 2001/01/18 01:54:36
*************** compare_symbols (const PTR s1p, const PT
*** 213,219 ****
s1 = (struct symbol **) s1p;
s2 = (struct symbol **) s2p;
! return (STRCMP (SYMBOL_SOURCE_NAME (*s1), SYMBOL_SOURCE_NAME (*s2)));
}
/*
--- 213,219 ----
s1 = (struct symbol **) s1p;
s2 = (struct symbol **) s2p;
! return (strcmp (SYMBOL_SOURCE_NAME (*s1), SYMBOL_SOURCE_NAME (*s2)));
}
/*
*************** compare_psymbols (const PTR s1p, const P
*** 260,277 ****
}
else
{
- /* Note: I replaced the STRCMP line (commented out below)
- * with a simpler "strcmp()" which compares the 2 strings
- * from the beginning. (STRCMP is a macro which first compares
- * the initial characters, then falls back on strcmp).
- * The reason is that the STRCMP line was tickling a C compiler
- * bug on HP-UX 10.30, which is avoided with the simpler
- * code. The performance gain from the more complicated code
- * is negligible, given that we have already checked the
- * initial 2 characters above. I reported the compiler bug,
- * and once it is fixed the original line can be put back. RT
- */
- /* return ( STRCMP (st1 + 2, st2 + 2)); */
return (strcmp (st1, st2));
}
}
--- 260,265 ----
Index: symtab.c
===================================================================
RCS file: /cvs/src/src/gdb/symtab.c,v
retrieving revision 1.25
diff -p -r1.25 symtab.c
*** symtab.c 2000/12/15 01:01:50 1.25
--- symtab.c 2001/01/18 01:54:42
*************** lookup_partial_symbol (struct partial_sy
*** 1004,1010 ****
{
do_linear_search = 1;
}
! if (STRCMP (SYMBOL_SOURCE_NAME (*center), name) >= 0)
{
top = center;
}
--- 1004,1010 ----
{
do_linear_search = 1;
}
! if (strcmp (SYMBOL_SOURCE_NAME (*center), name) >= 0)
{
top = center;
}
*************** lookup_block_symbol (register const stru
*** 1237,1243 ****
{
top = inc;
}
! else if (STRCMP (SYMBOL_SOURCE_NAME (sym), name) < 0)
{
bot = inc;
}
--- 1237,1243 ----
{
top = inc;
}
! else if (strcmp (SYMBOL_SOURCE_NAME (sym), name) < 0)
{
bot = inc;
}
Index: cli/cli-decode.c
===================================================================
RCS file: /cvs/src/src/gdb/cli/cli-decode.c,v
retrieving revision 1.5
diff -p -r1.5 cli-decode.c
*** cli-decode.c 2000/12/15 01:01:51 1.5
--- cli-decode.c 2001/01/18 01:54:47
*************** add_cmd (char *name, enum command_class
*** 67,73 ****
delete_cmd (name, list);
! if (*list == NULL || STRCMP ((*list)->name, name) >= 0)
{
c->next = *list;
*list = c;
--- 67,73 ----
delete_cmd (name, list);
! if (*list == NULL || strcmp ((*list)->name, name) >= 0)
{
c->next = *list;
*list = c;
*************** add_cmd (char *name, enum command_class
*** 75,81 ****
else
{
p = *list;
! while (p->next && STRCMP (p->next->name, name) <= 0)
{
p = p->next;
}
--- 75,81 ----
else
{
p = *list;
! while (p->next && strcmp (p->next->name, name) <= 0)
{
p = p->next;
}
*************** add_show_from_set (struct cmd_list_eleme
*** 312,318 ****
else
fprintf_unfiltered (gdb_stderr, "GDB internal error: Bad docstring for set command\n");
! if (*list == NULL || STRCMP ((*list)->name, showcmd->name) >= 0)
{
showcmd->next = *list;
*list = showcmd;
--- 312,318 ----
else
fprintf_unfiltered (gdb_stderr, "GDB internal error: Bad docstring for set command\n");
! if (*list == NULL || strcmp ((*list)->name, showcmd->name) >= 0)
{
showcmd->next = *list;
*list = showcmd;
*************** add_show_from_set (struct cmd_list_eleme
*** 320,326 ****
else
{
p = *list;
! while (p->next && STRCMP (p->next->name, showcmd->name) <= 0)
{
p = p->next;
}
--- 320,326 ----
else
{
p = *list;
! while (p->next && strcmp (p->next->name, showcmd->name) <= 0)
{
p = p->next;
}
From ac131313@cygnus.com Wed Jan 17 18:47:00 2001
From: Andrew Cagney <ac131313@cygnus.com>
To: GDB Patches <gdb-patches@sourceware.cygnus.com>
Subject: [rfc] Replace strsave() with xstrdup()
Date: Wed, 17 Jan 2001 18:47:00 -0000
Message-id: <3A6658B9.3B5FD07F@cygnus.com>
X-SW-Source: 2001-01/msg00169.html
Content-length: 13286
Any comments?
Andrew
Thu Jan 18 13:22:51 2001 Andrew Cagney <cagney@b1.cygnus.com>
* defs.h (strsave): Delete declaration.
* utils.c (strsave): Delete definition.
* mac-xdep.c (tilde_expand): Replace strsave with xstrdup.
* sparcl-tdep.c (sparclite_open): Ditto.
* mips-tdep.c (mips_set_processor_type_command): Ditto.
(_initialize_mips_tdep): Ditto.
* solib.c (solib_open): Ditto.
* symfile.c (add_filename_language): Ditto.
(set_ext_lang_command): Ditto.
* source.c (init_source_path): Ditto.
(mod_path): Ditto.
* sh3-rom.c (sh3_open): Ditto.
(sh3e_open): Ditto.
* serial.c (serial_open): Ditto.
* remote-mips.c (common_open): Ditto.
* monitor.c (monitor_open): Ditto.
* m32r-rom.c (m32r_upload_command): Ditto.
* infcmd.c (path_command): Ditto.
* f-exp.y (parse_number): Ditto.
* breakpoint.c (create_longjmp_breakpoint): Ditto.
(create_thread_event_breakpoint): Ditto.
* arc-tdep.c (arc_set_cpu_type_command): Ditto.
(_initialize_arc_tdep): Ditto.
Index: arc-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/arc-tdep.c,v
retrieving revision 1.3
diff -u -r1.3 arc-tdep.c
--- arc-tdep.c 2000/07/30 01:48:24 1.3
+++ arc-tdep.c 2001/01/18 02:33:54
@@ -639,7 +639,7 @@
printf_unfiltered ("%s\n", arc_cpu_type_table[i].name);
/* Restore the value. */
- tmp_arc_cpu_type = strsave (arc_cpu_type);
+ tmp_arc_cpu_type = xstrdup (arc_cpu_type);
return;
}
@@ -648,7 +648,7 @@
{
error ("Unknown cpu type `%s'.", tmp_arc_cpu_type);
/* Restore its value. */
- tmp_arc_cpu_type = strsave (arc_cpu_type);
+ tmp_arc_cpu_type = xstrdup (arc_cpu_type);
}
}
@@ -698,9 +698,9 @@
c = add_show_from_set (c, &showlist);
c->function.cfunc = arc_show_cpu_type_command;
- /* We have to use strsave here because the `set' command frees it before
- setting a new value. */
- tmp_arc_cpu_type = strsave (DEFAULT_ARC_CPU_TYPE);
+ /* We have to use xstrdup() here because the `set' command frees it
+ before setting a new value. */
+ tmp_arc_cpu_type = xstrdup (DEFAULT_ARC_CPU_TYPE);
arc_set_cpu_type (tmp_arc_cpu_type);
c = add_set_cmd ("displaypipeline", class_support, var_zinteger,
Index: breakpoint.c
===================================================================
RCS file: /cvs/src/src/gdb/breakpoint.c,v
retrieving revision 1.22
diff -u -r1.22 breakpoint.c
--- breakpoint.c 2000/12/15 01:01:45 1.22
+++ breakpoint.c 2001/01/18 02:35:10
@@ -3871,7 +3871,7 @@
b->enable = disabled;
b->silent = 1;
if (func_name)
- b->addr_string = strsave (func_name);
+ b->addr_string = xstrdup (func_name);
b->number = internal_breakpoint_number--;
}
@@ -3928,7 +3928,7 @@
b->enable = enabled;
/* addr_string has to be used or breakpoint_re_set will delete me. */
sprintf (addr_string, "*0x%s", paddr (b->address));
- b->addr_string = strsave (addr_string);
+ b->addr_string = xstrdup (addr_string);
return b;
}
Index: defs.h
===================================================================
RCS file: /cvs/src/src/gdb/defs.h,v
retrieving revision 1.33
diff -u -r1.33 defs.h
--- defs.h 2000/12/15 01:01:46 1.33
+++ defs.h 2001/01/18 02:35:20
@@ -823,8 +823,6 @@
extern char *msavestring (void *, const char *, int);
-extern char *strsave (const char *);
-
extern char *mstrsave (void *, const char *);
/* FIXME; was long, but this causes compile errors in msvc if already
Index: f-exp.y
===================================================================
RCS file: /cvs/src/src/gdb/f-exp.y,v
retrieving revision 1.2
diff -u -r1.2 f-exp.y
--- f-exp.y 2000/05/28 01:12:27 1.2
+++ f-exp.y 2001/01/18 02:35:25
@@ -653,7 +653,7 @@
/* [dD] is not understood as an exponent by atof, change it to 'e'. */
char *tmp, *tmp2;
- tmp = strsave (p);
+ tmp = xstrdup (p);
for (tmp2 = tmp; *tmp2; ++tmp2)
if (*tmp2 == 'd' || *tmp2 == 'D')
*tmp2 = 'e';
Index: infcmd.c
===================================================================
RCS file: /cvs/src/src/gdb/infcmd.c,v
retrieving revision 1.15
diff -u -r1.15 infcmd.c
--- infcmd.c 2001/01/12 09:45:57 1.15
+++ infcmd.c 2001/01/18 02:35:43
@@ -1420,7 +1420,7 @@
/* Can be null if path is not set */
if (!env)
env = "";
- exec_path = strsave (env);
+ exec_path = xstrdup (env);
mod_path (dirname, &exec_path);
set_in_environ (inferior_environ, path_var_name, exec_path);
xfree (exec_path);
Index: m32r-rom.c
===================================================================
RCS file: /cvs/src/src/gdb/m32r-rom.c,v
retrieving revision 1.4
diff -u -r1.4 m32r-rom.c
--- m32r-rom.c 2000/12/02 13:43:26 1.4
+++ m32r-rom.c 2001/01/18 02:35:43
@@ -480,7 +480,7 @@
error ("Please use 'set board-address' to set the M32R-EVA board's IP address.");
if (strchr (myIPaddress, '('))
*(strchr (myIPaddress, '(')) = '\0'; /* delete trailing junk */
- board_addr = strsave (myIPaddress);
+ board_addr = xstrdup (myIPaddress);
}
if (server_addr == 0)
{
@@ -508,7 +508,7 @@
if (args[0] != '/' && download_path == 0)
{
if (current_directory)
- download_path = strsave (current_directory);
+ download_path = xstrdup (current_directory);
else
error ("Need to know default download path (use 'set download-path')");
}
Index: mac-xdep.c
===================================================================
RCS file: /cvs/src/src/gdb/mac-xdep.c,v
retrieving revision 1.2
diff -u -r1.2 mac-xdep.c
--- mac-xdep.c 2000/07/30 01:48:26 1.2
+++ mac-xdep.c 2001/01/18 02:35:43
@@ -926,7 +926,7 @@
char *
tilde_expand (char *str)
{
- return strsave (str);
+ return xstrdup (str);
}
/* Modified versions of standard I/O. */
Index: mips-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/mips-tdep.c,v
retrieving revision 1.38
diff -u -r1.38 mips-tdep.c
--- mips-tdep.c 2001/01/04 23:22:45 1.38
+++ mips-tdep.c 2001/01/18 02:36:20
@@ -3331,7 +3331,7 @@
printf_unfiltered ("%s\n", mips_processor_type_table[i].name);
/* Restore the value. */
- tmp_mips_processor_type = strsave (mips_processor_type);
+ tmp_mips_processor_type = xstrdup (mips_processor_type);
return;
}
@@ -3340,7 +3340,7 @@
{
error ("Unknown processor type `%s'.", tmp_mips_processor_type);
/* Restore its value. */
- tmp_mips_processor_type = strsave (mips_processor_type);
+ tmp_mips_processor_type = xstrdup (mips_processor_type);
}
}
@@ -4610,8 +4610,8 @@
c = add_show_from_set (c, &showlist);
c->function.cfunc = mips_show_processor_type_command;
- tmp_mips_processor_type = strsave (DEFAULT_MIPS_TYPE);
- mips_set_processor_type_command (strsave (DEFAULT_MIPS_TYPE), 0);
+ tmp_mips_processor_type = xstrdup (DEFAULT_MIPS_TYPE);
+ mips_set_processor_type_command (xstrdup (DEFAULT_MIPS_TYPE), 0);
#endif
/* We really would like to have both "0" and "unlimited" work, but
Index: monitor.c
===================================================================
RCS file: /cvs/src/src/gdb/monitor.c,v
retrieving revision 1.15
diff -u -r1.15 monitor.c
--- monitor.c 2000/12/15 01:01:48 1.15
+++ monitor.c 2001/01/18 02:36:35
@@ -753,7 +753,7 @@
if (dev_name)
xfree (dev_name);
- dev_name = strsave (args);
+ dev_name = xstrdup (args);
monitor_desc = SERIAL_OPEN (dev_name);
Index: remote-mips.c
===================================================================
RCS file: /cvs/src/src/gdb/remote-mips.c,v
retrieving revision 1.11
diff -u -r1.11 remote-mips.c
--- remote-mips.c 2000/12/15 01:01:48 1.11
+++ remote-mips.c 2001/01/18 02:37:29
@@ -1528,7 +1528,7 @@
nomem (0);
make_cleanup_freeargv (argv);
- serial_port_name = strsave (argv[0]);
+ serial_port_name = xstrdup (argv[0]);
if (argv[1]) /* remote TFTP name specified? */
{
remote_name = argv[1];
@@ -1584,8 +1584,8 @@
local_name++; /* skip over the colon */
if (local_name == NULL)
local_name = remote_name; /* local name same as remote name */
- tftp_name = strsave (remote_name);
- tftp_localname = strsave (local_name);
+ tftp_name = xstrdup (remote_name);
+ tftp_localname = xstrdup (local_name);
tftp_in_use = 1;
}
}
@@ -1595,7 +1595,7 @@
/* Reset the expected monitor prompt if it's never been set before. */
if (mips_monitor_prompt == NULL)
- mips_monitor_prompt = strsave (new_monitor_prompt);
+ mips_monitor_prompt = xstrdup (new_monitor_prompt);
mips_monitor = new_monitor;
mips_initialize ();
@@ -1611,7 +1611,7 @@
/* Try to figure out the processor model if possible. */
ptype = mips_read_processor_type ();
if (ptype)
- mips_set_processor_type_command (strsave (ptype), 0);
+ mips_set_processor_type_command (xstrdup (ptype), 0);
/* This is really the job of start_remote however, that makes an assumption
that the target is about to print out a status message of some sort. That
Index: serial.c
===================================================================
RCS file: /cvs/src/src/gdb/serial.c,v
retrieving revision 1.6
diff -u -r1.6 serial.c
--- serial.c 2000/12/15 12:04:03 1.6
+++ serial.c 2001/01/18 02:37:36
@@ -213,7 +213,7 @@
return NULL;
}
- scb->name = strsave (name);
+ scb->name = xstrdup (name);
scb->next = scb_base;
scb->refcnt = 1;
scb->debug_p = 0;
Index: sh3-rom.c
===================================================================
RCS file: /cvs/src/src/gdb/sh3-rom.c,v
retrieving revision 1.5
diff -u -r1.5 sh3-rom.c
--- sh3-rom.c 2000/07/30 01:48:27 1.5
+++ sh3-rom.c 2001/01/18 02:37:36
@@ -249,7 +249,7 @@
if (args)
{
- char *cursor = serial_port_name = strsave (args);
+ char *cursor = serial_port_name = xstrdup (args);
while (*cursor && *cursor != ' ')
cursor++;
@@ -289,7 +289,7 @@
if (args)
{
- char *cursor = serial_port_name = strsave (args);
+ char *cursor = serial_port_name = xstrdup (args);
while (*cursor && *cursor != ' ')
cursor++;
Index: solib.c
===================================================================
RCS file: /cvs/src/src/gdb/solib.c,v
retrieving revision 1.31
diff -u -r1.31 solib.c
--- solib.c 2000/12/23 00:27:20 1.31
+++ solib.c 2001/01/18 02:37:44
@@ -143,7 +143,7 @@
/* Done. If not found, tough luck. Return found_file and
(optionally) found_pathname. */
if (found_pathname != NULL && temp_pathname != NULL)
- *found_pathname = strsave (temp_pathname);
+ *found_pathname = xstrdup (temp_pathname);
return found_file;
}
Index: source.c
===================================================================
RCS file: /cvs/src/src/gdb/source.c,v
retrieving revision 1.7
diff -u -r1.7 source.c
--- source.c 2001/01/16 17:36:44 1.7
+++ source.c 2001/01/18 02:37:58
@@ -255,7 +255,7 @@
char buf[20];
sprintf (buf, "$cdir%c$cwd", DIRNAME_SEPARATOR);
- source_path = strsave (buf);
+ source_path = xstrdup (buf);
forget_cached_source_info ();
}
@@ -295,7 +295,7 @@
if (dirname == 0)
return;
- dirname = strsave (dirname);
+ dirname = xstrdup (dirname);
make_cleanup (xfree, dirname);
do
Index: sparcl-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/sparcl-tdep.c,v
retrieving revision 1.8
diff -u -r1.8 sparcl-tdep.c
--- sparcl-tdep.c 2000/12/15 01:01:49 1.8
+++ sparcl-tdep.c 2001/01/18 02:37:58
@@ -413,7 +413,7 @@
if (remote_target_name)
xfree (remote_target_name);
- remote_target_name = strsave (name);
+ remote_target_name = xstrdup (name);
/* We need a 'serial' or 'udp' keyword to disambiguate host:port, which can
mean either a serial port on a terminal server, or the IP address of a
Index: symfile.c
===================================================================
RCS file: /cvs/src/src/gdb/symfile.c,v
retrieving revision 1.22
diff -u -r1.22 symfile.c
--- symfile.c 2000/12/15 01:01:50 1.22
+++ symfile.c 2001/01/18 02:38:20
@@ -1783,7 +1783,7 @@
fl_table_size);
}
- filename_language_table[fl_table_next].ext = strsave (ext);
+ filename_language_table[fl_table_next].ext = xstrdup (ext);
filename_language_table[fl_table_next].lang = lang;
fl_table_next++;
}
@@ -1842,7 +1842,7 @@
/* ext_args, language_str (lang)); */
xfree (filename_language_table[i].ext);
- filename_language_table[i].ext = strsave (ext_args);
+ filename_language_table[i].ext = xstrdup (ext_args);
filename_language_table[i].lang = lang;
}
}
Index: utils.c
===================================================================
RCS file: /cvs/src/src/gdb/utils.c,v
retrieving revision 1.25
diff -u -r1.25 utils.c
--- utils.c 2000/12/15 01:01:50 1.25
+++ utils.c 2001/01/18 02:38:31
@@ -1162,15 +1162,6 @@
return p;
}
-/* The "const" is so it compiles under DGUX (which prototypes strsave
- in <string.h>. FIXME: This should be named "xstrsave", shouldn't it?
- Doesn't real strsave return NULL if out of memory? */
-char *
-strsave (const char *ptr)
-{
- return savestring (ptr, strlen (ptr));
-}
-
char *
mstrsave (void *md, const char *ptr)
{
From ac131313@cygnus.com Wed Jan 17 22:46:00 2001
From: Andrew Cagney <ac131313@cygnus.com>
To: GDB Patches <gdb-patches@sourceware.cygnus.com>
Subject: [Fwd: [rfc] Remove 5.0 obsolete code]
Date: Wed, 17 Jan 2001 22:46:00 -0000
Message-id: <3A6690B8.F1C1F0D@cygnus.com>
X-SW-Source: 2001-01/msg00170.html
Content-length: 8520
(Sorry, wrong mailing list.)
To : GDB Discussion <gdb at sourceware dot cygnus dot com>
Subject : [rfc] Remove 5.0 obsolete code
From : Andrew Cagney <ac131313 at cygnus dot com>
Date : Thu, 18 Jan 2001 15:52:12 +1100
Hello,
This follows up a discussion on the gdb@ mailing list. It removes the
obsolete targets. I would draw your attention to the news file where it
will now read:
* OBSOLETE configurations
....
Configurations that have been declared obsolete in this release have
been commented out. Unless there is activity to revive these
configurations, the next release of GDB will have their sources
permanently REMOVED.
In GDB 5.0 this note read:
Configurations that have been declared obsolete will be commented out,
but the code will be left in place. If there is no activity to revive
these configurations before the next release of GDB, the sources will
be permanently REMOVED.
The old paragraph could give the impression that the removal would only
occure just before the next GDB release. Given that everything is in
CVS this is no longer needed.
Andrew
Thu Jan 18 14:03:13 2001 Andrew Cagney <cagney@b1.cygnus.com>
* configure.tgt: Remove references to convex, pyramid, altos and
tahoe.
* configure.host: Ditto.
* MAINTAINERS: Ditto.
* NEWS: Update.
* tahoe-tdep.c: Delete obsolete file.
* pyr-xdep.c: Ditto.
* pyr-tdep.c: Ditto.
* convex-tdep.c: Ditto.
* convex-xdep.c: Ditto.
* config/tahoe/xm-tahoe.h: Ditto.
* config/tahoe/tm-tahoe.h: Ditto.
* config/tahoe/tahoe.mt: Ditto.
* config/tahoe/tahoe.mh: Ditto.
* config/pyr/xm-pyr.h: Ditto.
* config/pyr/tm-pyr.h: Ditto.
* config/pyr/pyramid.mt: Ditto.
* config/pyr/pyramid.mh: Ditto.
* config/m68k/xm-altos.h: Ditto.
* config/m68k/tm-altos.h: Ditto.
* config/m68k/altos.mt: Ditto.
* config/m68k/altos.mh: Ditto.
* config/convex/xm-convex.h: Ditto.
* config/convex/tm-convex.h: Ditto.
* config/convex/convex.mt: Ditto.
* config/convex/convex.mh: Ditto.
* config/convex/Convex.notes: Ditto.
* config/arm/xm-arm.h: Ditto.
* config/arm/nm-arm.h: Ditto.
* config/arm/arm.mt: Ditto.
* config/arm/arm.mh: Ditto.
* arm-convert.s: Ditto.
* arm-xdep.c: Ditto.
* altos-xdep.c: Ditto.
Index: MAINTAINERS
===================================================================
RCS file: /cvs/src/src/gdb/MAINTAINERS,v
retrieving revision 1.62
diff -p -r1.62 MAINTAINERS
*** MAINTAINERS 2001/01/16 22:45:48 1.62
--- MAINTAINERS 2001/01/18 03:36:42
*************** maintainer works with the native maintai
*** 42,49 ****
Jim Ingham jingham@apple.com
Scott Bambrough scottb@netwinder.org
- convex OBSOLETE
-
d10v Andrew Cagney cagney@cygnus.com
d30v David Taylor taylor@cygnus.com
--- 42,47 ----
*************** maintainer works with the native maintai
*** 80,87 ****
powerpc Kevin Buettner kevinb@cygnus.com
Nick Duffek nsd@cygnus.com
- pyramid OBSOLETE
-
romp maintenance only (?)
rs6000 (see rs6000 native and ppc target)
--- 78,83 ----
*************** maintainer works with the native maintai
*** 89,96 ****
sh Elena Zannoni ezannoni@cygnus.com
sparc David Taylor taylor@cygnus.com
-
- tahoe OBSOLETE
tic80 maintenance only (tic80-coff)
v850 maintenance only (v850-elf)
--- 85,90 ----
Index: NEWS
===================================================================
RCS file: /cvs/src/src/gdb/NEWS,v
retrieving revision 1.11
diff -p -r1.11 NEWS
*** NEWS 2000/10/24 05:22:11 1.11
--- NEWS 2001/01/18 03:37:26
*************** x86 FreeBSD 3.x and 4.x i[3456]86*-fr
*** 14,20 ****
x86 FreeBSD before 2.2 i[3456]86*-freebsd{1,2.[01]}*,
! * Deleted configurations
* Other news:
--- 14,31 ----
x86 FreeBSD before 2.2 i[3456]86*-freebsd{1,2.[01]}*,
! Configurations that have been declared obsolete in this release have
! been commented out. Unless there is activity to revive these
! configurations, the next release of GDB will have their sources
! permanently REMOVED.
!
! * REMOVED configurations
!
! Altos 3068 m68*-altos-*
! Convex c1-*-*, c2-*-*
! Pyramid pyramid-*-*
! ARM RISCix arm-*-* (as host)
! Tahoe tahoe-*-*
* Other news:
Index: configure.host
===================================================================
RCS file: /cvs/src/src/gdb/configure.host,v
retrieving revision 1.10
diff -p -r1.10 configure.host
*** configure.host 2000/11/26 20:04:41 1.10
--- configure.host 2001/01/18 03:37:26
*************** case "${host_cpu}" in
*** 12,23 ****
alpha*) gdb_host_cpu=alpha ;;
arm*) gdb_host_cpu=arm ;;
- # OBSOLETE c[12]) gdb_host_cpu=convex ;;
hppa*) gdb_host_cpu=pa ;;
i[3456]86*) gdb_host_cpu=i386 ;;
m68*) gdb_host_cpu=m68k ;;
m88*) gdb_host_cpu=m88k ;;
- # OBSOLETE pyramid) gdb_host_cpu=pyr ;;
powerpc*) gdb_host_cpu=powerpc ;;
sparc64) gdb_host_cpu=sparc ;;
*) gdb_host_cpu=$host_cpu ;;
--- 12,21 ----
*************** alpha*-*-freebsd*) gdb_host=fbsd ;;
*** 39,46 ****
arm*-*-linux*) gdb_host=linux ;;
arm*-*-*) gdb_host=arm ;;
- # OBSOLETE c[12]-*-*) gdb_host=convex ;;
-
hppa*-*-bsd*) gdb_host=hppabsd ;;
hppa*-*-hiux*) gdb_host=hppahpux ;;
hppa*-*-hpux10.20) gdb_host=hpux1020 ;;
--- 37,42 ----
*************** m680[01]0-sun-sunos3*) gdb_host=sun2os3
*** 90,96 ****
m680[01]0-sun-sunos4*) gdb_host=sun2os4 ;;
m68030-sony-*) gdb_host=news1000 ;;
- # OBSOLETE m68*-altos-*) gdb_host=altos ;;
m68*-apollo*-sysv*) gdb_host=apollo68v ;;
m68*-apollo*-bsd*) gdb_host=apollo68b ;;
m68*-att-*) gdb_host=3b1 ;;
--- 86,91 ----
*************** powerpcle-*-solaris*) gdb_host=solaris ;
*** 140,149 ****
powerpc-*-linux*) gdb_host=linux ;;
powerpc-*-netbsd*) gdb_host=nbsd ;;
- # OBSOLETE pn-*-*) gdb_host=pn ;;
-
- # OBSOLETE pyramid-*-*) gdb_host=pyramid ;;
-
romp-*-*) gdb_host=rtbsd ;;
rs6000-*-lynxos*) gdb_host=rs6000lynx ;;
--- 135,140 ----
*************** sparc64-*-*) gdb_host=sun4sol2 ;;
*** 163,170 ****
strongarm-*-*) gdb_host=arm ;;
xscale-*-*) gdb_host=arm ;;
-
- # OBSOLETE tahoe-*-*) gdb_host=tahoe ;;
vax-*-bsd*) gdb_host=vaxbsd ;;
vax-*-ultrix2*) gdb_host=vaxult2 ;;
--- 154,159 ----
Index: configure.tgt
===================================================================
RCS file: /cvs/src/src/gdb/configure.tgt,v
retrieving revision 1.16
diff -p -r1.16 configure.tgt
*** configure.tgt 2000/12/14 20:15:45 1.16
--- configure.tgt 2001/01/18 03:37:26
*************** case "${target_cpu}" in
*** 14,20 ****
alpha*) gdb_target_cpu=alpha ;;
arm*) gdb_target_cpu=arm ;;
- # OBSOLETE c[12]) gdb_target_cpu=convex ;;
hppa*) gdb_target_cpu=pa ;;
i[3456]86*) gdb_target_cpu=i386 ;;
m68hc11*|m6811*) gdb_target_cpu=m68hc11 ;;
--- 14,19 ----
*************** m68*) gdb_target_cpu=m68k ;;
*** 22,28 ****
m88*) gdb_target_cpu=m88k ;;
mips*) gdb_target_cpu=mips ;;
powerpc*) gdb_target_cpu=powerpc ;;
- # OBSOLETE pyramid) gdb_target_cpu=pyr ;;
sparc*) gdb_target_cpu=sparc ;;
thumb*) gdb_target_cpu=arm ;;
strongarm*) gdb_target_cpu=arm ;;
--- 21,26 ----
*************** arm*-*-* | thumb*-*-* | strongarm*-*-*)
*** 63,70 ****
xscale-*-*) gdb_target=embed
configdirs="$configdirs rdi-share"
;;
- # OBSOLETE c1-*-*) gdb_target=convex ;;
- # OBSOLETE c2-*-*) gdb_target=convex ;;
d10v-*-*) gdb_target=d10v ;;
d30v-*-*) gdb_target=d30v ;;
--- 61,66 ----
*************** m68*-apollo*-bsd*) gdb_target=apollo68b
*** 149,155 ****
m68*-bull-sysv*) gdb_target=dpx2 ;;
m68*-hp-bsd*) gdb_target=hp300bsd ;;
m68*-hp-hpux*) gdb_target=hp300hpux ;;
- # OBSOLETE m68*-altos-*) gdb_target=altos ;;
m68*-att-*) gdb_target=3b1 ;;
m68*-cisco*-*) gdb_target=cisco ;;
m68*-ericsson-*) gdb_target=es1800 ;;
--- 145,150 ----
*************** powerpcle-*-eabi* | powerpcle-*-sysv* |
*** 255,262 ****
powerpc-*-linux*) gdb_target=linux ;;
powerpc-*-vxworks*) gdb_target=vxworks ;;
- # OBSOLETE pyramid-*-*) gdb_target=pyramid ;;
-
rs6000-*-lynxos*) gdb_target=rs6000lynx
configdirs="${configdirs} gdbserver" ;;
rs6000-*-aix4*) gdb_target=aix4 ;;
--- 250,255 ----
*************** sparc86x-*-*) gdb_target=sparclite ;;
*** 288,295 ****
# deleted though presumably it should be eventually.
#sparc64-*-solaris2*) gdb_target=sp64sol2 ;;
sparc64-*-*) gdb_target=sp64 ;;
-
- # OBSOLETE tahoe-*-*) gdb_target=tahoe ;;
tic80-*-*) gdb_target=tic80
configdirs="${configdirs} gdbserver" ;;
--- 281,286 ----
From ac131313@cygnus.com Wed Jan 17 22:56:00 2001
From: Andrew Cagney <ac131313@cygnus.com>
To: Nick Clifton <nickc@redhat.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: RFA: Fix to build arc-tdep.c with new ARC machine numbers
Date: Wed, 17 Jan 2001 22:56:00 -0000
Message-id: <3A669318.D4BA6E4D@cygnus.com>
References: <200101112131.NAA30844@elmo.cygnus.com>
X-SW-Source: 2001-01/msg00171.html
Content-length: 2273
Nick Clifton wrote:
>
> Hi Guys,
>
> The ARC port in binutils was recently changes by a submission from
> Peter Taggert at arccores.com. This change introduced some new
> machine numbers for the ARC and also changed how the disassembler is
> invoked. The patch below makes adjustments to arc-tdep.c for both
> of these changes.
>
> OK to apply ?
Approved (but with reservations).
If the ARC target is going to have a long term future then it needs to
move away from this arc_cpu_type[] table and onto multi-arch. If there
is any intention to extend the ARC target support beyond this simple
patch then, again, it will need to first be multi-arched.
Andrew
> Cheers
> Nick
>
> 2001-01-11 Nick Clifton <nickc@redhat.com>
>
> * arc-tdep.c (arc_cpu_type_table): Add new arc core numbers.
> (arc_print_insn): No bfd available, so pass NULL to
> arc_get_disassembler.
>
> Index: gdb/arc-tdep.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/arc-tdep.c,v
> retrieving revision 1.3
> diff -p -r1.3 arc-tdep.c
> *** arc-tdep.c 2000/07/30 01:48:24 1.3
> --- arc-tdep.c 2001/01/11 21:27:27
> *************** struct
> *** 44,56 ****
> }
> arc_cpu_type_table[] =
> {
> ! {
> ! "base", bfd_mach_arc_base
> ! }
> ! ,
> ! {
> ! NULL, 0
> ! }
> };
>
> /* Used by simulator. */
> --- 44,54 ----
> }
> arc_cpu_type_table[] =
> {
> ! { "arc5", bfd_mach_arc_5 },
> ! { "arc6", bfd_mach_arc_6 },
> ! { "arc7", bfd_mach_arc_7 },
> ! { "arc8", bfd_mach_arc_8 },
> ! { NULL, 0 }
> };
>
> /* Used by simulator. */
> *************** arc_print_insn (bfd_vma vma, disassemble
> *** 618,625 ****
> {
> current_mach = arc_bfd_mach_type;
> current_endian = TARGET_BYTE_ORDER;
> ! current_disasm = arc_get_disassembler (current_mach,
> ! current_endian == BIG_ENDIAN);
> }
>
> return (*current_disasm) (vma, info);
> --- 616,622 ----
> {
> current_mach = arc_bfd_mach_type;
> current_endian = TARGET_BYTE_ORDER;
> ! current_disasm = arc_get_disassembler (NULL);
> }
>
> return (*current_disasm) (vma, info);
From eliz@is.elta.co.il Thu Jan 18 00:43:00 2001
From: Eli Zaretskii <eliz@is.elta.co.il>
To: Christopher Faylor <cgf@redhat.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [patch] fix for infinite recursion in lookup_symbol
Date: Thu, 18 Jan 2001 00:43:00 -0000
Message-id: <Pine.SUN.3.91.1010118104033.3768K-100000@is>
References: <20010117161229.B15404@redhat.com>
X-SW-Source: 2001-01/msg00172.html
Content-length: 667
On Wed, 17 Jan 2001, Christopher Faylor wrote:
> What does everyone think about setting a "vote system" for this kind
> of contingency?
Voting doesn't sound right, if a simple majority can win. I think if
a patch draws opposition, it should be rejected even if the opposing
parties are in the minority.
Also, it might be useful if the individual who suggests the patch
tries to play ``devil's advocate'' and describe the possible downsides
of the patch, to allow others make up their minds in a more educated
way. The rationale for this is that, in the absence of the
responsible maintainer, we might lack insight and know-how to make
good decisions on our own.
From ac131313@cygnus.com Thu Jan 18 05:03:00 2001
From: Andrew Cagney <ac131313@cygnus.com>
To: GDB Patches <gdb-patches@sourceware.cygnus.com>
Subject: [rfc] MAINTAINERS target buildable list and configure.in wind-back
Date: Thu, 18 Jan 2001 05:03:00 -0000
Message-id: <3A66E90C.3162F8B5@cygnus.com>
X-SW-Source: 2001-01/msg00173.html
Content-length: 7107
Hello,
This change does two things:
o For each ISA it specifies a target
that is known to build (or failing that
should probably build)
o winds back the -Werror list dropping
-Wuninitialized. That is a catch 22.
Unless -Wuninitialized warnings are
displayed no one will think of fixing
them but if you add -Wuninit, GDB
won't compile with -Werror :-/
It follows through an earlier and very similar patch. The host/build
was FreeBSD 3.5.x. From memory, the most common build problem was
attributable to <link.h> being included when it shouldn't.
thoughts?
Andrew
PS:
awk < "${maintainers}" '
$2 ~ /^--target=.*/ {
targets = gensub (/--target=/, "", 1, $2)
split (targets, targ, /,/)
for (i in targ) {
print targ[i], $3
}
}
' | while read target warnings
do
Thu Jan 18 12:08:57 2001 Andrew Cagney <cagney@b1.cygnus.com>
* configure.in (build_warnings): Disable -Wuninitialized until GDB
compiles with -Wuninitialized,-Werror.
* configure: Regenerate.
* MAINTAINERS: Add list of targets.
Index: MAINTAINERS
===================================================================
RCS file: /cvs/src/src/gdb/MAINTAINERS,v
retrieving revision 1.62
diff -p -r1.62 MAINTAINERS
*** MAINTAINERS 2001/01/16 22:45:48 1.62
--- MAINTAINERS 2001/01/18 11:55:29
*************** variants. *-tdep.c. The Target/Architec
*** 34,102 ****
host maintainer when resolving build issues. The Target/Architecture
maintainer works with the native maintainer when resolving API issues.
! a29k maintenance only (a29k-amd-udi -Werror)
! alpha maintenance only (alpha-dec-osf4.0a)
! arc maintenance only (arc-elf)
! arm Fernando Nasser fnasser@cygnus.com
Jim Ingham jingham@apple.com
Scott Bambrough scottb@netwinder.org
convex OBSOLETE
! d10v Andrew Cagney cagney@cygnus.com
! d30v David Taylor taylor@cygnus.com
! djgpp (see native and host)
! fr30 maintenance only (fr30-elf)
! h8300 maintenance only (h8300hms)
! h8500 maintenance only (h8500hms)
! i386 Mark Kettenis kettenis@gnu.org
! i960 maintenance only (i960-coff)
! ia64 Kevin Buettner kevinb@cygnus.com
! m32r Michael Snyder msnyder@cygnus.com
! m68hc11 Stephane Carrez Stephane.Carrez@worldnet.fr
! m68k maintenance only (m68k-aout, m68k-coff, m68k-elf)
! m88k maintenance only (?)
! mcore maintenance only (?)
! mips Andrew Cagney cagney@cygnus.com
! mn10200 maintenance only (mn10200-elf)
! mn10300 Andrew Cagney cagney@cygnus.com
! ns32k maintenance only (?)
! pa Jeff Law law@cygnus.com
! powerpc Kevin Buettner kevinb@cygnus.com
Nick Duffek nsd@cygnus.com
pyramid OBSOLETE
! romp maintenance only (?)
! rs6000 (see rs6000 native and ppc target)
! sh Elena Zannoni ezannoni@cygnus.com
! sparc David Taylor taylor@cygnus.com
tahoe OBSOLETE
! tic80 maintenance only (tic80-coff)
! v850 maintenance only (v850-elf)
! vax maintenance only (vax-dec-vms5.5)
! w65 maintenance only (?)
! z8k maintenance only (?)
All maintainers can make arbitrary changes to OBSOLETE targets.
--- 34,146 ----
host maintainer when resolving build issues. The Target/Architecture
maintainer works with the native maintainer when resolving API issues.
! a29k --target=a29k-amd-udi -Werror
! Maintenance only
! alpha --target=alpha-dec-osf4.0a -Werror
! Maintenance only
!
! arc --target=arc-elf ,-Werror
! Maintenance only
!
! arm --target=arm-coff,arm-elf,arm-pe ,-Werror
! Fernando Nasser fnasser@cygnus.com
Jim Ingham jingham@apple.com
Scott Bambrough scottb@netwinder.org
convex OBSOLETE
+
+ d10v --target=d10v-elf ,-Werror
+ Andrew Cagney cagney@cygnus.com
+
+ d30v --target=d30v-elf ,-Werror
+ David Taylor taylor@cygnus.com
+
+ djgpp --target=i586-pc-msdosdjgpp ,-Werror
+ (See native and host)
+
+ fr30 --target=fr30-elf -Werror
+ Maintenance only
! h8300 --target=h8300hms -Werror
! Maintenance only
! h8500 --target=h8500hms -Werror
! Maintenance only
! i386 --target=i386-elf,i386-aout ,-Werror
! Mark Kettenis kettenis@gnu.org
! i960 (--target=i960-coff broken)
! Maintenance only
! ia64 (--target=ia64-elf broken)
! Kevin Buettner kevinb@cygnus.com
! m32r --target=m32r-elf -Werror
! Michael Snyder msnyder@cygnus.com
! m68hc11 --target=m68hc11-elf ,-Werror
! Stephane Carrez Stephane.Carrez@worldnet.fr
! m68k --target=m68k-aout,m68k-coff,m68k-elf ,-Werror
! Maintenance only
! m88k (?)
! Maintenance only
! mcore (--target=mcore-elf,mcore-pe broken)
! Maintenance only
! mips --target=mips-elf,mips64-elf ,-Werror
! Andrew Cagney cagney@cygnus.com
! mn10200 (--target=mn10200-elf broken)
! Maintenance only
! mn10300 (--target=mn10300-elf broken)
! Andrew Cagney cagney@cygnus.com
! ns32k (--target=ns32k-netbsd broken)
! Maintenance only
! pa (--target=hppa1.1-hp-proelf broken)
! Jeff Law law@cygnus.com
!
! powerpc (--target=powerpc-eabi,powerpcle-eabi broken)
! Kevin Buettner kevinb@cygnus.com
Nick Duffek nsd@cygnus.com
pyramid OBSOLETE
! romp (?)
! Maintenance only
! rs6000 --target=rs6000-ibm-aix3.2,rs6000-ibm-aix4.1 ,-Werror
! (see rs6000 native and ppc target)
! sh (--target=sh-hms,sh-elf broken)
! Elena Zannoni ezannoni@cygnus.com
! sparc --target=sparc-elf,sparc64-elf ,-Werror
! David Taylor taylor@cygnus.com
tahoe OBSOLETE
+
+ tic80 (--target=tic80-coff broken)
+ Maintenance only
+
+ v850 (--target=v850-elf broken)
+ Maintenance only
+
+ vax --target=vax-dec-vms5.5 ,-Werror
+ Maintenance only
+
+ w65 (--target=w64 broken)
+ Maintenance only
! z8k (--target=z8k-coff broken)
! Maintenance only
All maintainers can make arbitrary changes to OBSOLETE targets.
Index: configure.in
===================================================================
RCS file: /cvs/src/src/gdb/configure.in,v
retrieving revision 1.53
diff -p -r1.53 configure.in
*** configure.in 2000/12/21 16:16:17 1.53
--- configure.in 2001/01/18 11:55:47
*************** fi
*** 594,600 ****
# NOTE: If you add to this list, remember to update
# gdb/doc/gdbint.texinfo.
build_warnings="-Wimplicit -Wreturn-type -Wcomment -Wtrigraphs \
! -Wformat -Wparentheses -Wpointer-arith -Wuninitialized"
# Up for debate: -Wswitch -Wcomment -trigraphs -Wtrigraphs
# -Wunused-function -Wunused-label -Wunused-variable -Wunused-value
# -Wchar-subscripts -Wuninitialized -Wtraditional -Wshadow -Wcast-qual
--- 594,600 ----
# NOTE: If you add to this list, remember to update
# gdb/doc/gdbint.texinfo.
build_warnings="-Wimplicit -Wreturn-type -Wcomment -Wtrigraphs \
! -Wformat -Wparentheses -Wpointer-arith"
# Up for debate: -Wswitch -Wcomment -trigraphs -Wtrigraphs
# -Wunused-function -Wunused-label -Wunused-variable -Wunused-value
# -Wchar-subscripts -Wuninitialized -Wtraditional -Wshadow -Wcast-qual
From ac131313@cygnus.com Thu Jan 18 07:28:00 2001
From: Andrew Cagney <ac131313@cygnus.com>
To: Mark Salter <msalter@redhat.com>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: Z packet change
Date: Thu, 18 Jan 2001 07:28:00 -0000
Message-id: <3A670B0F.602D7C94@cygnus.com>
References: <200010271317.e9RDHVL10194@deneb.localdomain>
X-SW-Source: 2001-01/msg00174.html
Content-length: 1727
Mark Salter wrote:
>
> The following patch changes the Z packet support for hw breakpoints to
> match the documentation. Its not clear to me if we should do this or
> change the documentation to make make the 'len' field optional. Some
> hw lets you specify a range for hw breakpoints and although gdb doesn't
> support that right now, it may in the future.
FYI,
I've committed this patch.
Andrew
> 2000-10-27 Mark Salter <msalter@redhat.com>
>
> * remote.c (remote_remove_hw_breakpoint): Add 'len' field to Z packet.
> (remote_insert_hw_breakpoint): Ditto.
>
> Index: remote.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/remote.c,v
> retrieving revision 1.26
> diff -p -c -r1.26 remote.c
> *** remote.c 2000/10/23 22:49:28 1.26
> --- remote.c 2000/10/27 13:06:52
> *************** remote_insert_hw_breakpoint (CORE_ADDR a
> *** 4433,4439 ****
>
> addr = remote_address_masked (addr);
> p += hexnumstr (p, (ULONGEST) addr);
> ! *p = '\0';
>
> putpkt (buf);
> getpkt (buf, PBUFSIZ, 0);
> --- 4433,4439 ----
>
> addr = remote_address_masked (addr);
> p += hexnumstr (p, (ULONGEST) addr);
> ! sprintf (p, ",%x", len);
>
> putpkt (buf);
> getpkt (buf, PBUFSIZ, 0);
> *************** remote_remove_hw_breakpoint (CORE_ADDR a
> *** 4469,4475 ****
>
> addr = remote_address_masked (addr);
> p += hexnumstr (p, (ULONGEST) addr);
> ! *p = '\0';
>
> putpkt(buf);
> getpkt (buf, PBUFSIZ, 0);
> --- 4469,4475 ----
>
> addr = remote_address_masked (addr);
> p += hexnumstr (p, (ULONGEST) addr);
> ! sprintf (p, ",%x", len);
>
> putpkt(buf);
> getpkt (buf, PBUFSIZ, 0);
From fnasser@cygnus.com Thu Jan 18 07:52:00 2001
From: Fernando Nasser <fnasser@cygnus.com>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: GDB Patches <gdb-patches@sourceware.cygnus.com>
Subject: Re: [rfc] FREEIF -> xfree()
Date: Thu, 18 Jan 2001 07:52:00 -0000
Message-id: <3A671126.61DB3079@cygnus.com>
References: <3A6646C0.CDAFD1A4@cygnus.com>
X-SW-Source: 2001-01/msg00175.html
Content-length: 3280
Andrew Cagney wrote:
>
> Continuing the move to xfree().
> Comments?
>
That is what we decided to do, as far as I remember.
Fernando
> Andrew
>
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> Thu Jan 18 12:25:06 2001 Andrew Cagney <cagney@b1.cygnus.com>
>
> * varobj.c (FREEIF): Delete macro.
> (varobj_set_value, free_variable): Replace FREEIF with ``xfree''
> call.
>
> Index: varobj.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/varobj.c,v
> retrieving revision 1.14
> diff -p -r1.14 varobj.c
> *** varobj.c 2000/12/15 01:01:51 1.14
> --- varobj.c 2001/01/18 01:27:58
> *************** static int rootcount = 0; /* number of r
> *** 391,401 ****
> /* Pointer to the varobj hash table (built at run time) */
> static struct vlist **varobj_table;
>
> - #if defined(FREEIF)
> - #undef FREEIF
> - #endif
> - #define FREEIF(x) if (x != NULL) free((char *) (x))
> -
> /* Is the variable X one of our "fake" children? */
> #define CPLUS_FAKE_CHILD(x) \
> ((x) != NULL && (x)->type == NULL && (x)->value == NULL)
> --- 391,396 ----
> *************** varobj_set_value (struct varobj *var, ch
> *** 788,794 ****
> if (!gdb_evaluate_expression (exp, &value))
> {
> /* We cannot proceed without a valid expression. */
> ! FREEIF (exp);
> return 0;
> }
>
> --- 783,789 ----
> if (!gdb_evaluate_expression (exp, &value))
> {
> /* We cannot proceed without a valid expression. */
> ! xfree (exp);
> return 0;
> }
>
> *************** free_variable (struct varobj *var)
> *** 1353,1364 ****
> if (var->root->rootvar == var)
> {
> free_current_contents ((char **) &var->root->exp);
> ! FREEIF (var->root);
> }
>
> ! FREEIF (var->name);
> ! FREEIF (var->obj_name);
> ! FREEIF (var);
> }
>
> static void
> --- 1348,1359 ----
> if (var->root->rootvar == var)
> {
> free_current_contents ((char **) &var->root->exp);
> ! xfree (var->root);
> }
>
> ! xfree (var->name);
> ! xfree (var->obj_name);
> ! xfree (var);
> }
>
> static void
--
Fernando Nasser
Red Hat - Toronto E-Mail: fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario M4P 2C9
From fnasser@cygnus.com Thu Jan 18 08:01:00 2001
From: Fernando Nasser <fnasser@cygnus.com>
To: Eli Zaretskii <eliz@is.elta.co.il>
Cc: Christopher Faylor <cgf@redhat.com>, gdb-patches@sources.redhat.com
Subject: Re: [patch] fix for infinite recursion in lookup_symbol
Date: Thu, 18 Jan 2001 08:01:00 -0000
Message-id: <3A671351.3C33ADFF@cygnus.com>
References: <Pine.SUN.3.91.1010118104033.3768K-100000@is>
X-SW-Source: 2001-01/msg00176.html
Content-length: 825
Eli Zaretskii wrote:
>
> On Wed, 17 Jan 2001, Christopher Faylor wrote:
>
> > What does everyone think about setting a "vote system" for this kind
> > of contingency?
>
> Voting doesn't sound right, if a simple majority can win. I think if
> a patch draws opposition, it should be rejected even if the opposing
> parties are in the minority.
>
This situation where the minority rules is commonly referred to as
"dictatorship".
Yes, because if any opposition causes the rejection of a patch, any individual
can make his/her preferences prevail by systematically "opposing" to patches
that go against his believes.
I think you must refine your definition of "opposition".
--
Fernando Nasser
Red Hat - Toronto E-Mail: fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario M4P 2C9
From eliz@is.elta.co.il Thu Jan 18 08:25:00 2001
From: Eli Zaretskii <eliz@is.elta.co.il>
To: Fernando Nasser <fnasser@cygnus.com>
Cc: Christopher Faylor <cgf@redhat.com>, gdb-patches@sources.redhat.com
Subject: Re: [patch] fix for infinite recursion in lookup_symbol
Date: Thu, 18 Jan 2001 08:25:00 -0000
Message-id: <Pine.SUN.3.91.1010118181831.8466B-100000@is>
References: <3A671351.3C33ADFF@cygnus.com>
X-SW-Source: 2001-01/msg00177.html
Content-length: 450
On Thu, 18 Jan 2001, Fernando Nasser wrote:
> if any opposition causes the rejection of a patch, any individual
> can make his/her preferences prevail by systematically "opposing" to patches
> that go against his believes.
I assume that individuals with such attitude are absent from this fine
forum. I have yet to see any sign of such an approach from anyone here.
Therefore, I don't think we need to consider such a possibility as a
real one.
From ac131313@cygnus.com Thu Jan 18 08:34:00 2001
From: Andrew Cagney <ac131313@cygnus.com>
To: matthew green <mrg@cygnus.com>
Cc: Fernando Nasser <fnasser@redhat.com>, gdb-patches@sources.redhat.com
Subject: Re: patch for compilers that don't define "unix"
Date: Thu, 18 Jan 2001 08:34:00 -0000
Message-id: <3A671A63.68AD4A22@cygnus.com>
References: <8062.979583347@cygnus.com>
X-SW-Source: 2001-01/msg00178.html
Content-length: 1735
matthew green wrote:
>
>
> This is not the proper fix though. The rdi-share subdirectory is supposed to
> contain code shared with ARM, so we shouldn't make local modifications in there
> (unless absolutely necessary).
>
> how about this then? tested on netbsd/i386 and solaris 2.6. you'll need to
> regenerate `configure' after applying this patch.
>
> thanks.
>
> 2001-01-15 matthew green <mrg@redhat.com>
>
> * configure.in: Define missing `__unix' if `__unix__' is present.
> * configure: Regenerate.
I think this is wrong (I actually prefered the original patch).
GDB's build process should not be defining symbols that polute the
system name space (anything with a leading double ``__'').
enjoy,
Andrew
> Index: configure.in
> ===================================================================
> RCS file: /cvs/src/src/gdb/configure.in,v
> retrieving revision 1.53
> diff -p -r1.53 configure.in
> *** configure.in 2000/12/21 16:16:17 1.53
> --- configure.in 2001/01/15 18:21:54
> *************** if test x${want_included_regex} = xtrue;
> *** 703,708 ****
> --- 703,718 ----
> AC_DEFINE(USE_INCLUDED_REGEX)
> fi
> AC_SUBST(REGEX)
> +
> + # NetBSD compiler defines __unix__ only; rdi-share needs __unix.
> + AC_CACHE_CHECK([for NetBSD [__unix__]], gdb_cv_missing_netbsd___unix,
> + [AC_EGREP_CPP(lose, [
> + #if defined (__unix__) || !defined (__unix)
> + lose
> + #endif],[gdb_cv_missing_netbsd___unix=yes],[gdb_cv_missing_netbsd___unix=no])])
> + if test x$gdb_cv_missing_netbsd___unix = xyes; then
> + CFLAGS="$CFLAGS -D__unix"
> + fi
>
> # In the Cygwin environment, we need some additional flags.
> AC_CACHE_CHECK([for cygwin], gdb_cv_os_cygwin,
From cgf@redhat.com Thu Jan 18 09:27:00 2001
From: Christopher Faylor <cgf@redhat.com>
To: Eli Zaretskii <eliz@is.elta.co.il>
Cc: Fernando Nasser <fnasser@cygnus.com>, gdb-patches@sources.redhat.com
Subject: Re: [patch] fix for infinite recursion in lookup_symbol
Date: Thu, 18 Jan 2001 09:27:00 -0000
Message-id: <20010118122723.A31930@redhat.com>
References: <3A671351.3C33ADFF@cygnus.com> <Pine.SUN.3.91.1010118181831.8466B-100000@is>
X-SW-Source: 2001-01/msg00179.html
Content-length: 749
On Thu, Jan 18, 2001 at 06:21:18PM +0200, Eli Zaretskii wrote:
>
>On Thu, 18 Jan 2001, Fernando Nasser wrote:
>
>> if any opposition causes the rejection of a patch, any individual
>> can make his/her preferences prevail by systematically "opposing" to patches
>> that go against his believes.
>
>I assume that individuals with such attitude are absent from this fine
>forum. I have yet to see any sign of such an approach from anyone here.
>
>Therefore, I don't think we need to consider such a possibility as a
>real one.
I agree. I was really thinking of this as a special case situation where
we could get patches into gdb when the patch maintainer is inexplicably
absent.
If *anyone* disagrees with the patch then it shouldn't go in.
cgf
From dberlin@redhat.com Thu Jan 18 13:42:00 2001
From: Daniel Berlin <dberlin@redhat.com>
To: Christopher Faylor <cgf@redhat.com>
Cc: Eli Zaretskii <eliz@is.elta.co.il>, Fernando Nasser <fnasser@cygnus.com>, <gdb-patches@sources.redhat.com>
Subject: Re: [patch] fix for infinite recursion in lookup_symbol
Date: Thu, 18 Jan 2001 13:42:00 -0000
Message-id: <Pine.LNX.4.31.0101181329510.15385-100000@www.cgsoftware.com>
References: <20010118122723.A31930@redhat.com>
X-SW-Source: 2001-01/msg00180.html
Content-length: 1371
On Thu, 18 Jan 2001, Christopher Faylor wrote:
> On Thu, Jan 18, 2001 at 06:21:18PM +0200, Eli Zaretskii wrote:
> >
> >On Thu, 18 Jan 2001, Fernando Nasser wrote:
> >
> >> if any opposition causes the rejection of a patch, any individual
> >> can make his/her preferences prevail by systematically "opposing" to patches
> >> that go against his believes.
> >
> >I assume that individuals with such attitude are absent from this fine
> >forum. I have yet to see any sign of such an approach from anyone here.
> >
> >Therefore, I don't think we need to consider such a possibility as a
> >real one.
>
> I agree. I was really thinking of this as a special case situation where
> we could get patches into gdb when the patch maintainer is inexplicably
> absent.
>
> If *anyone* disagrees with the patch then it shouldn't go in.
>
Of course. But you have to admit, the situation we just had, as Jim
pointed out, makes GDB look *really* bad.
Maybe some rule about checking "obvious" bug fixes in that relate to
*your* earlier patches?
That way, you ccan fix something that your patch may have broke
accidently, as long as the fix is obvious?
I'm assuming you waited a week, and heard no response from a maintainer at
all, but no opposition from anyone else, either.
I'm not trying to handle large patches here, just 2 or 3 line fixes that
can have a major effect.
--Dan
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [patch] fix for infinite recursion in lookup_symbol
[not found] ` <6480-Fri19Jan2001122012+0200-eliz@is.elta.co.il>
@ 2001-01-19 8:25 ` Chris Faylor
0 siblings, 0 replies; 6+ messages in thread
From: Chris Faylor @ 2001-01-19 8:25 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: sjohnson, fnasser, gdb-patches
On Fri, Jan 19, 2001 at 12:20:12PM +0200, Eli Zaretskii wrote:
>> Date: Fri, 19 Jan 2001 09:03:47 +1000
>> From: Steven Johnson <sjohnson@neurizon.net>
>>
>> If there are "NO" votes, then they should be qualified with reasons.
>
>Yes, of course. I think everybody here already does that anyway.
Right. I really don't think we have to worry about the "jerk" scenario.
Everyone here is pretty reasonable.
cgf
From fnasser@cygnus.com Fri Jan 19 09:20:00 2001
From: Fernando Nasser <fnasser@cygnus.com>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: matthew green <mrg@cygnus.com>, Fernando Nasser <fnasser@redhat.com>, gdb-patches@sources.redhat.com
Subject: Re: patch for compilers that don't define "unix"
Date: Fri, 19 Jan 2001 09:20:00 -0000
Message-id: <3A68773E.208C140C@cygnus.com>
References: <8062.979583347@cygnus.com> <3A671A63.68AD4A22@cygnus.com>
X-SW-Source: 2001-01/msg00198.html
Content-length: 2658
Andrew Cagney wrote:
>
> matthew green wrote:
> >
> >
> > This is not the proper fix though. The rdi-share subdirectory is supposed to
> > contain code shared with ARM, so we shouldn't make local modifications in there
> > (unless absolutely necessary).
> >
> > how about this then? tested on netbsd/i386 and solaris 2.6. you'll need to
> > regenerate `configure' after applying this patch.
> >
> > thanks.
> >
> > 2001-01-15 matthew green <mrg@redhat.com>
> >
> > * configure.in: Define missing `__unix' if `__unix__' is present.
> > * configure: Regenerate.
>
> I think this is wrong (I actually prefered the original patch).
> GDB's build process should not be defining symbols that polute the
> system name space (anything with a leading double ``__'').
>
FYI, the original patch did the same thing: defined the same symbol, just
in a more restricted scope. So your argument would apply to it as well.
But you misunderstood Matthew's intention. He is not inventing a new symbol.
He is defining a symbol that newer versions of netbsd do not define any longer.
The naming at least is correct. He is defining exactly the same symbol that
used to be defined by previous versions and it is a system symbol, that
belongs in the system space, with a leading "__".
Anyway, I will work with Matthew to keep the change restricted to the
rdi-share subdirectory so we leave gdb/configure.in alone.
> enjoy,
> Andrew
>
> > Index: configure.in
> > ===================================================================
> > RCS file: /cvs/src/src/gdb/configure.in,v
> > retrieving revision 1.53
> > diff -p -r1.53 configure.in
> > *** configure.in 2000/12/21 16:16:17 1.53
> > --- configure.in 2001/01/15 18:21:54
> > *************** if test x${want_included_regex} = xtrue;
> > *** 703,708 ****
> > --- 703,718 ----
> > AC_DEFINE(USE_INCLUDED_REGEX)
> > fi
> > AC_SUBST(REGEX)
> > +
> > + # NetBSD compiler defines __unix__ only; rdi-share needs __unix.
> > + AC_CACHE_CHECK([for NetBSD [__unix__]], gdb_cv_missing_netbsd___unix,
> > + [AC_EGREP_CPP(lose, [
> > + #if defined (__unix__) || !defined (__unix)
> > + lose
> > + #endif],[gdb_cv_missing_netbsd___unix=yes],[gdb_cv_missing_netbsd___unix=no])])
> > + if test x$gdb_cv_missing_netbsd___unix = xyes; then
> > + CFLAGS="$CFLAGS -D__unix"
> > + fi
> >
> > # In the Cygwin environment, we need some additional flags.
> > AC_CACHE_CHECK([for cygwin], gdb_cv_os_cygwin,
--
Fernando Nasser
Red Hat - Toronto E-Mail: fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario M4P 2C9
From jingham@apple.com Fri Jan 19 10:50:00 2001
From: Jim Ingham <jingham@apple.com>
To: gdb-patches@sources.redhat.com
Subject: Re: gdb-patches Digest 19 Jan 2001 14:34:08 -0000 Issue 519
Date: Fri, 19 Jan 2001 10:50:00 -0000
Message-id: <200101191849.KAA25663@scv1.apple.com>
References: <979914848.9079.ezmlm@sources.redhat.com>
X-SW-Source: 2001-01/msg00199.html
Content-length: 2627
Eli,
I think the situation was a little different than you are percieving.
Some patches were checked in. I also didn't follow the discussion
closely at the time. Apparently the patches were controversial, and
there was some contention about whether they should stay in or not. But
for the nonce they were in. And given that we mostly know that JimB is
working on another very important and cool project right now (how is
subversions going by the way) it was clear that it would take a little
while to sort this out.
HOWEVER, the patch (and thus the current state of gdb) had an obvious
gaffe that caused gdb to crash in a pretty common usage. Moreover,
apparently both the bug and the fix were known pretty soon after the
original patch was checked in. To make matters worse, the fix for the
crashing bug was a no-brainer - probably just a cut & paste error.
So it was important to decouple the discussion of whether the overall
patch should be reverted or not from the decision to check in a fix that
kept gdb as it stood in the CVS repository from crashing on people.
This sort of case may very well arise again, since it was not the result
of bad will on anybody's part, as far as I can tell. And regardless of
larger design concerns we really should have a way to expedite fixes in
this context, so that gdb stays pretty reliable most of the time. It
was unreliable for C++ debugging for two or three months. This is bad...
Jim
>> Date: Thu, 18 Jan 2001 13:32:30 -0500 (EST)
>> From: Daniel Berlin <dberlin@redhat.com>
>>>
>>> I agree. I was really thinking of this as a special case situation
>>> where
>>> we could get patches into gdb when the patch maintainer is
>>> inexplicably
>>> absent.
>>>
>>> If *anyone* disagrees with the patch then it shouldn't go in.
>>
>> Of course. But you have to admit, the situation we just had, as Jim
>> pointed out, makes GDB look *really* bad.
>
> I don't agree. I didn't follow the discussion about this particular
> problem, but if the relevant maintainer goes off-line, and some of the
> other maintainers have reservations about a suggested patch in the
> absent maintainer's area, refraining from committing that patch is
> IMHO a prudent thing to do.
>
> In such a situation, you have several possible alternatives:
>
> - talk the opposition into agreeing to the patch;
> - suggest an alternative patch which avoids the problems which
> triggered the opposition;
> - wait for the maintainer to reappear and decide what to do.
--
Jim Ingham jingham@apple.com
Developer Tools - gdb
Apple Computer
From eliz@is.elta.co.il Fri Jan 19 11:29:00 2001
From: "Eli Zaretskii" <eliz@is.elta.co.il>
To: jingham@apple.com
Cc: gdb-patches@sources.redhat.com
Subject: Re: gdb-patches Digest 19 Jan 2001 14:34:08 -0000 Issue 519
Date: Fri, 19 Jan 2001 11:29:00 -0000
Message-id: <968-Fri19Jan2001212516+0200-eliz@is.elta.co.il>
References: <200101191849.KAA25663@scv1.apple.com>
X-SW-Source: 2001-01/msg00200.html
Content-length: 1591
> Date: Fri, 19 Jan 2001 10:49:56 -0800
> From: Jim Ingham <jingham@apple.com>
>
> HOWEVER, the patch (and thus the current state of gdb) had an obvious
> gaffe that caused gdb to crash in a pretty common usage. Moreover,
> apparently both the bug and the fix were known pretty soon after the
> original patch was checked in. To make matters worse, the fix for the
> crashing bug was a no-brainer - probably just a cut & paste error.
>
> So it was important to decouple the discussion of whether the overall
> patch should be reverted or not from the decision to check in a fix that
> kept gdb as it stood in the CVS repository from crashing on people.
Was someone opposed to get this fixed in the way suggested by whoever
proposed the fix?
If there was no opposition, I don't see how the situation you
described contradicts a principle I was proposing.
> This sort of case may very well arise again, since it was not the result
> of bad will on anybody's part, as far as I can tell. And regardless of
> larger design concerns we really should have a way to expedite fixes in
> this context, so that gdb stays pretty reliable most of the time.
I agree that we must have a way to take action when the responsible
maintainer is unavailable. I just think that when considering changes
in areas that aren't areas of our immediate expertise, we should
exercise more cautious approach.
If there are people who are experts in some area, they can step
forward as back-up maintainers, so that, shall the main maintainer
become unavailable, changes can still be quickly committed.
From ac131313@cygnus.com Fri Jan 19 14:54:00 2001
From: Andrew Cagney <ac131313@cygnus.com>
To: rearnsha@arm.com
Cc: Nick Clifton <nickc@cygnus.com>, GDB Patches <gdb-patches@sourceware.cygnus.com>, SID Discussion <sid@sources.redhat.com>
Subject: Re: dejagnu hang from target.exp (prune_warnings)
Date: Fri, 19 Jan 2001 14:54:00 -0000
Message-id: <3A68C4FA.BA8FF50A@cygnus.com>
References: <200101191458.OAA06282@cam-mail2.cambridge.arm.com>
X-SW-Source: 2001-01/msg00201.html
Content-length: 312
Richard Earnshaw wrote:
>
> Fri Jan 19 18:37:19 2001 Andrew Cagney <cagney@b1.cygnus.com>
>
> * lib/target.exp (prune_warnings): Avoid ``.*'' in NetBSD warnings
> pattern.
>
> OK. Still filters out the relevant warnings from the g77 regression suite.
Thanks! I've checked it in.
Andrew
From ac131313@cygnus.com Fri Jan 19 15:52:00 2001
From: Andrew Cagney <ac131313@cygnus.com>
To: DJBARROW@de.ibm.com
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: question
Date: Fri, 19 Jan 2001 15:52:00 -0000
Message-id: <3A68D2BA.7268D4DF@cygnus.com>
References: <C12569D9.004FF453.00@d12mta09.de.ibm.com>
X-SW-Source: 2001-01/msg00202.html
Content-length: 391
DJBARROW@de.ibm.com wrote:
>
> Hi,
> Do we now have to check out gdb bfd binutils readline etc separately as
> they are no longer appear to be in the gdb
> repository ? & if so could someone of you please update the getting.html.
Hmm, GDB lives in the unified SRC repository with bfd and binutils. See:
http://sources.redhat.com/gdb/#download
Do you have a URL for getting.html?
Andrew
From bje@redhat.com Sat Jan 20 04:28:00 2001
From: Ben Elliston <bje@redhat.com>
To: <gdb-patches@sources.redhat.com>, <sid@sources.redhat.com>
Subject: [DejaGNU patch] Re-document --mail
Date: Sat, 20 Jan 2001 04:28:00 -0000
Message-id: <Pine.LNX.4.31.0101202327010.25471-100000@moshpit.cygnus.com>
X-SW-Source: 2001-01/msg00203.html
Content-length: 1625
Over the years, the --mail option has been slowly disappearing from
documentation. Okay to commit?
2001-01-20 Ben Elliston <bje@redhat.com>
* runtest.exp (usage): Replace --mail in usage output.
* doc/runtest.1: Re-document --mail option, which was erroneously
removed from this man page in 1994.
Index: runtest.exp
===================================================================
RCS file: /cvs/cvsfiles/devo/dejagnu/runtest.exp,v
retrieving revision 1.153
diff -u -r1.153 runtest.exp
--- runtest.exp 1999/12/02 18:51:54 1.153
+++ runtest.exp 2001/01/20 12:24:47
@@ -372,6 +372,7 @@
send_user "\t--target \[string\]\tThe canonical config name of the target board\n"
send_user "\t--debug (-de)\t\tSet expect debugging ON\n"
send_user "\t--help (-he)\t\tPrint help text\n"
+ send_user "\t--mail \[name(s)\]\tWho to mail the results to\n"
send_user "\t--ignore \[name(s)\]\tThe names of specific tests to ignore\n"
send_user "\t--objdir \[name\]\t\tThe test suite binary directory\n"
send_user "\t--outdir \[name\]\t\tThe directory to put logs in\n"
Index: doc/runtest.1
===================================================================
RCS file: /cvs/cvsfiles/devo/dejagnu/doc/runtest.1,v
retrieving revision 1.7
diff -u -r1.7 runtest.1
--- runtest.1 1998/12/30 20:36:57 1.7
+++ runtest.1 2001/01/20 12:24:48
@@ -53,8 +53,9 @@
.TP
.BI --ignore \ test1.exp\ test2.exp\ ...
Do not run the specified tests.
+.BI --mail \ \'name1\ name2\ ...\'
Electronic mail addresses to receive test results.
-.TP
+.TP
.BI --name \ hostname
The network hostname of the target board.
.TP
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [patch] fix for infinite recursion in lookup_symbol
[not found] ` <14950.6503.362049.921003@kwikemart.cygnus.com>
@ 2001-01-18 15:35 ` Jim Blandy
0 siblings, 0 replies; 6+ messages in thread
From: Jim Blandy @ 2001-01-18 15:35 UTC (permalink / raw)
To: Elena Zannoni; +Cc: David Taylor, Christopher Faylor, gdb-patches
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 13276 bytes --]
I've committed Jim Ingham's fix.
Folks, I do apologize. For partly personal reasons, I've been very
much in the ozone regarding almost every GDB-related matter for quite
some time. I'll try to shape up.
Ideally, I'd be ready to pass judgement on whether the famous October
12 changes should be reverted, but I don't feel like I have a handle
on the situation at the moment. I'll try to make a real judgement on
the issue tomorrow. In the meantime, Jim I's patch seems perfectly
safe.
From fnasser@redhat.com Thu Jan 18 15:58:00 2001
From: Fernando Nasser <fnasser@redhat.com>
To: Jim Blandy <jimb@cygnus.com>
Cc: Elena Zannoni <ezannoni@cygnus.com>, David Taylor <taylor@cygnus.com>, Christopher Faylor <cgf@redhat.com>, gdb-patches@sources.redhat.com
Subject: Re: [patch] fix for infinite recursion in lookup_symbol
Date: Thu, 18 Jan 2001 15:58:00 -0000
Message-id: <3A6782C9.8DA3BB4B@redhat.com>
References: <200101172157.QAA21576@texas.cygnus.com> <14950.6503.362049.921003@kwikemart.cygnus.com> <np1yu0tow1.fsf@zwingli.cygnus.com>
X-SW-Source: 2001-01/msg00186.html
Content-length: 218
Jim Blandy wrote:
>
> I've committed Jim Ingham's fix.
>
Thank you.
--
Fernando Nasser
Red Hat Canada Ltd. E-Mail: fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario M4P 2C9
From nickc@redhat.com Thu Jan 18 20:07:00 2001
From: Nick Clifton <nickc@redhat.com>
To: ac131313@cygnus.com
Cc: peter.targett@arccores.com, gdb-patches@sources.redhat.com
Subject: Re: RFA: Fix to build arc-tdep.c with new ARC machine numbers
Date: Thu, 18 Jan 2001 20:07:00 -0000
Message-id: <200101190407.UAA01868@elmo.cygnus.com>
X-SW-Source: 2001-01/msg00187.html
Content-length: 2755
Hi Andrew,
I am forwarding your message to Peter Taggert, who contributed the
ARC rewrite. I will check in the current GDB patch, since it at
least allows the toolchain to build for now.
Cheers
Nick
------- Start of forwarded message -------
From: Andrew Cagney <ac131313@cygnus.com>
To: Nick Clifton <nickc@redhat.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: RFA: Fix to build arc-tdep.c with new ARC machine numbers
Nick Clifton wrote:
>
> Hi Guys,
>
> The ARC port in binutils was recently changes by a submission from
> Peter Taggert at arccores.com. This change introduced some new
> machine numbers for the ARC and also changed how the disassembler is
> invoked. The patch below makes adjustments to arc-tdep.c for both
> of these changes.
>
> OK to apply ?
Approved (but with reservations).
If the ARC target is going to have a long term future then it needs to
move away from this arc_cpu_type[] table and onto multi-arch. If there
is any intention to extend the ARC target support beyond this simple
patch then, again, it will need to first be multi-arched.
Andrew
> Cheers
> Nick
>
> 2001-01-11 Nick Clifton <nickc@redhat.com>
>
> * arc-tdep.c (arc_cpu_type_table): Add new arc core numbers.
> (arc_print_insn): No bfd available, so pass NULL to
> arc_get_disassembler.
>
> Index: gdb/arc-tdep.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/arc-tdep.c,v
> retrieving revision 1.3
> diff -p -r1.3 arc-tdep.c
> *** arc-tdep.c 2000/07/30 01:48:24 1.3
> --- arc-tdep.c 2001/01/11 21:27:27
> *************** struct
> *** 44,56 ****
> }
> arc_cpu_type_table[] =
> {
> ! {
> ! "base", bfd_mach_arc_base
> ! }
> ! ,
> ! {
> ! NULL, 0
> ! }
> };
>
> /* Used by simulator. */
> --- 44,54 ----
> }
> arc_cpu_type_table[] =
> {
> ! { "arc5", bfd_mach_arc_5 },
> ! { "arc6", bfd_mach_arc_6 },
> ! { "arc7", bfd_mach_arc_7 },
> ! { "arc8", bfd_mach_arc_8 },
> ! { NULL, 0 }
> };
>
> /* Used by simulator. */
> *************** arc_print_insn (bfd_vma vma, disassemble
> *** 618,625 ****
> {
> current_mach = arc_bfd_mach_type;
> current_endian = TARGET_BYTE_ORDER;
> ! current_disasm = arc_get_disassembler (current_mach,
> ! current_endian == BIG_ENDIAN);
> }
>
> return (*current_disasm) (vma, info);
> --- 616,622 ----
> {
> current_mach = arc_bfd_mach_type;
> current_endian = TARGET_BYTE_ORDER;
> ! current_disasm = arc_get_disassembler (NULL);
> }
>
> return (*current_disasm) (vma, info);
------- End of forwarded message -------
From ac131313@cygnus.com Thu Jan 18 21:41:00 2001
From: Andrew Cagney <ac131313@cygnus.com>
To: GDB Patches <gdb-patches@sourceware.cygnus.com>
Subject: Re: [rfc] FREEIF -> xfree()
Date: Thu, 18 Jan 2001 21:41:00 -0000
Message-id: <3A67D303.3B04683A@cygnus.com>
References: <3A6646C0.CDAFD1A4@cygnus.com>
X-SW-Source: 2001-01/msg00188.html
Content-length: 259
Andrew Cagney wrote:
> Thu Jan 18 12:25:06 2001 Andrew Cagney <cagney@b1.cygnus.com>
>
> * varobj.c (FREEIF): Delete macro.
> (varobj_set_value, free_variable): Replace FREEIF with ``xfree''
> call.
I've checked this in.
Andrew
From ac131313@cygnus.com Thu Jan 18 23:50:00 2001
From: Andrew Cagney <ac131313@cygnus.com>
To: Nick Clifton <nickc@cygnus.com>, Richard Earnshaw <rearnsha@arm.com>
Cc: GDB Patches <gdb-patches@sourceware.cygnus.com>, SID Discussion <sid@sources.redhat.com>
Subject: dejagnu hang from target.exp (prune_warnings)
Date: Thu, 18 Jan 2001 23:50:00 -0000
Message-id: <3A67F120.30D17FF6@cygnus.com>
X-SW-Source: 2001-01/msg00189.html
Content-length: 2276
The change:
< 2001-01-12 Richard Earnshaw <rearnsha@arm.com>
<
< * target.exp (prune_warnings): Prune warnings from NetBSD
linker.
<
checked in by NickC causes dejagnu to hang (or to at least take a very
very very very very long walk) when the compiler generates lots of
output. Looking at the patch:
- # Or the NetBSD ones.
- regsub -all "(^|\n)(.*:\[0-9\]+: warning: \[^\n\]* possibly used
unsafely, use \[^\n\]*\n?)" $text "\\1" text
- regsub -all "(^|\n)(.*: warning: reference to compatibility
glob\[^\n\]*\n?)" $text "\\1" text
that leading ``.*'' is just too generous :-(
The attatched stops the problem for me. Can someone please confirm this
doesn't break on NetBSD.
enjoy,
Andrew
Fri Jan 19 18:37:19 2001 Andrew Cagney <cagney@b1.cygnus.com>
* lib/target.exp (prune_warnings): Avoid ``.*'' in NetBSD warnings
pattern.
Index: lib/target.exp
===================================================================
RCS file: /cvs/src/src/dejagnu/lib/target.exp,v
retrieving revision 1.7
diff -p -r1.7 target.exp
*** target.exp 2001/01/12 18:13:40 1.7
--- target.exp 2001/01/19 07:39:47
*************** proc prune_warnings { text } {
*** 262,269 ****
regsub -all "(^|\n)(ld(|32|64): Giving up.*Use -wall\[^\n\]*\n?)+" $text "\\1" text
# Or the NetBSD ones.
! regsub -all "(^|\n)(.*:\[0-9\]+: warning: \[^\n\]* possibly used unsafely, use \[^\n\]*\n?)" $text "\\1" text
! regsub -all "(^|\n)(.*: warning: reference to compatibility glob\[^\n\]*\n?)" $text "\\1" text
# GNU ld warns about functions marked as dangerous in GNU libc.
regsub -all "(^|\n)\[^\n\]*: In function\[^\n\]*\n\[^\n\]\[^\n\]*function is dangerous\[^\n\]*" $text "" text
--- 262,269 ----
regsub -all "(^|\n)(ld(|32|64): Giving up.*Use -wall\[^\n\]*\n?)+" $text "\\1" text
# Or the NetBSD ones.
! regsub -all "(^|\n)(\[^\n\]*:\[0-9\]+: warning: \[^\n\]* possibly used unsafely, use \[^\n\]*\n?)" $text "\\1" text
! regsub -all "(^|\n)(\[^\n\]*: warning: reference to compatibility glob\[^\n\]*\n?)" $text "\\1" text
# GNU ld warns about functions marked as dangerous in GNU libc.
regsub -all "(^|\n)\[^\n\]*: In function\[^\n\]*\n\[^\n\]\[^\n\]*function is dangerous\[^\n\]*" $text "" text
From ac131313@cygnus.com Fri Jan 19 00:01:00 2001
From: Andrew Cagney <ac131313@cygnus.com>
To: GDB Patches <gdb-patches@sourceware.cygnus.com>
Subject: Re: [rfc] Replace STRCMP() with strcmp()
Date: Fri, 19 Jan 2001 00:01:00 -0000
Message-id: <3A67F3C5.A9B5C392@cygnus.com>
References: <3A664D3D.62952710@cygnus.com>
X-SW-Source: 2001-01/msg00190.html
Content-length: 622
Andrew Cagney wrote:
> Thu Jan 18 12:48:04 2001 Andrew Cagney <cagney@b1.cygnus.com>
>
> * defs.h (STRCMP): Delete macro.
>
> * objfiles.c (objfile_relocate): Replace STRCMP with call to
> strcmp.
> * symtab.c (lookup_partial_symbol, lookup_block_symbol): Ditto.
> * symfile.c (compare_symbols): Ditto.
> * standalone.c (open): Ditto.
> * remote-es.c (verify_break): Ditto.
> * cli/cli-decode.c (add_cmd, add_show_from_set): Ditto.
>
> * symfile.c (compare_psymbols): Delete comment refering to STRCMP.
FYI,
I've checked this in.
Andrew
From eliz@is.elta.co.il Fri Jan 19 01:46:00 2001
From: "Eli Zaretskii" <eliz@is.elta.co.il>
To: cgf@redhat.com
Cc: fnasser@cygnus.com, gdb-patches@sources.redhat.com
Subject: Re: [patch] fix for infinite recursion in lookup_symbol
Date: Fri, 19 Jan 2001 01:46:00 -0000
Message-id: <2110-Fri19Jan2001114250+0200-eliz@is.elta.co.il>
References: <3A671351.3C33ADFF@cygnus.com> <Pine.SUN.3.91.1010118181831.8466B-100000@is> <20010118122723.A31930@redhat.com>
X-SW-Source: 2001-01/msg00191.html
Content-length: 238
> Date: Thu, 18 Jan 2001 12:27:23 -0500
> From: Christopher Faylor <cgf@redhat.com>
>
> If *anyone* disagrees with the patch then it shouldn't go in.
Well, there is, of course, the possibility of talking the opposition
into agreeing...
From eliz@is.elta.co.il Fri Jan 19 02:03:00 2001
From: "Eli Zaretskii" <eliz@is.elta.co.il>
To: dberlin@redhat.com
Cc: cgf@redhat.com, fnasser@cygnus.com, gdb-patches@sources.redhat.com
Subject: Re: [patch] fix for infinite recursion in lookup_symbol
Date: Fri, 19 Jan 2001 02:03:00 -0000
Message-id: <2950-Fri19Jan2001120038+0200-eliz@is.elta.co.il>
References: <Pine.LNX.4.31.0101181329510.15385-100000@www.cgsoftware.com>
X-SW-Source: 2001-01/msg00192.html
Content-length: 1022
> Date: Thu, 18 Jan 2001 13:32:30 -0500 (EST)
> From: Daniel Berlin <dberlin@redhat.com>
> >
> > I agree. I was really thinking of this as a special case situation where
> > we could get patches into gdb when the patch maintainer is inexplicably
> > absent.
> >
> > If *anyone* disagrees with the patch then it shouldn't go in.
>
> Of course. But you have to admit, the situation we just had, as Jim
> pointed out, makes GDB look *really* bad.
I don't agree. I didn't follow the discussion about this particular
problem, but if the relevant maintainer goes off-line, and some of the
other maintainers have reservations about a suggested patch in the
absent maintainer's area, refraining from committing that patch is
IMHO a prudent thing to do.
In such a situation, you have several possible alternatives:
- talk the opposition into agreeing to the patch;
- suggest an alternative patch which avoids the problems which
triggered the opposition;
- wait for the maintainer to reappear and decide what to do.
From eliz@is.elta.co.il Fri Jan 19 02:23:00 2001
From: "Eli Zaretskii" <eliz@is.elta.co.il>
To: sjohnson@neurizon.net
Cc: fnasser@cygnus.com, cgf@redhat.com, gdb-patches@sources.redhat.com
Subject: Re: [patch] fix for infinite recursion in lookup_symbol
Date: Fri, 19 Jan 2001 02:23:00 -0000
Message-id: <6480-Fri19Jan2001122012+0200-eliz@is.elta.co.il>
References: <Pine.SUN.3.91.1010118181831.8466B-100000@is> <3A677652.FA74EAD0@neurizon.net>
X-SW-Source: 2001-01/msg00193.html
Content-length: 228
> Date: Fri, 19 Jan 2001 09:03:47 +1000
> From: Steven Johnson <sjohnson@neurizon.net>
>
> If there are "NO" votes, then they should be qualified with reasons.
Yes, of course. I think everybody here already does that anyway.
From ac131313@cygnus.com Fri Jan 19 02:29:00 2001
From: Andrew Cagney <ac131313@cygnus.com>
To: GDB Patches <gdb-patches@sourceware.cygnus.com>
Subject: Re: [rfc] MAINTAINERS target buildable list and configure.in wind-back
Date: Fri, 19 Jan 2001 02:29:00 -0000
Message-id: <3A681667.A2734973@cygnus.com>
References: <3A66E90C.3162F8B5@cygnus.com>
X-SW-Source: 2001-01/msg00194.html
Content-length: 431
FYI,
I've checked this in. It allows me to check a multi-arch patch I'm
about to post. If you fix a build problem please please feel free to up
date it.
Andrew
Thu Jan 18 12:08:57 2001 Andrew Cagney <cagney@b1.cygnus.com>
* configure.in (build_warnings): Disable -Wuninitialized until
GDB
compiles with -Wuninitialized,-Werror.
* configure: Regenerate.
* MAINTAINERS: Add list of targets.
From DJBARROW@de.ibm.com Fri Jan 19 06:34:00 2001
From: DJBARROW@de.ibm.com
To: gdb-patches@sourceware.cygnus.com
Subject: question
Date: Fri, 19 Jan 2001 06:34:00 -0000
Message-id: <C12569D9.004FF453.00@d12mta09.de.ibm.com>
X-SW-Source: 2001-01/msg00195.html
Content-length: 371
Hi,
Do we now have to check out gdb bfd binutils readline etc separately as
they are no longer appear to be in the gdb
repository ? & if so could someone of you please update the getting.html.
D.J. Barrow Linux for S/390 kernel developer
eMail: djbarrow@de.ibm.com,barrow_dj@yahoo.com
Phone: +49-(0)7031-16-2583
IBM Germany Lab, Schönaicherstr. 220, 71032 Böblingen
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [patch] fix for infinite recursion in lookup_symbol
[not found] <B6889200.268C%jingham@apple.com>
@ 2001-01-15 12:14 ` Fernando Nasser
0 siblings, 0 replies; 6+ messages in thread
From: Fernando Nasser @ 2001-01-15 12:14 UTC (permalink / raw)
To: Jim Ingham; +Cc: Daniel Berlin, gdb-patches
I just would like to add my 2cents to a few of Jim's remarks:
Jim Ingham wrote:
>
> Daniel,
>
> >> I understand that there is some argument over whether the current
> >> implementation of C++ symbol lookup is the right one, but while it is in
> >> place, simple fixes to it need to get into the sources quickly.
> >
> > I'd happily check them in under an obvious bugfix rule, but I don't want
> > to step on any toes.
> > I had enough fun doing that trying to figure out what exact areas of code
> > C++ maintainer covers, and I still couldn't tell you.
> > If someone with definite maintainership over the symbol tables says I can
> > check in the fixes, i'll do it. Otherwise, i won't.
> > Sorry.
>
> I sympathize, but in this case the fix really is trivial... This one really
> does fall under the obvious bugfix rule if any fix does...
>
People were questioning earlier today if such rule really exists.
If it does not we are doomed. Specially with the current maintainers
response
time (including me -- we all have our hands full).
We need a way to fix things quickly. If it needs a better fix it should
be properly
documented so people get to it as soon as they can.
We cannot just leave things broken!!!
If this is an attempt to force volunteers to make extra work and do code
improvements
and cleanups is not working. People are just giving up and leaving
things broken.
They are probably adding the fixes to their own copies and many other
developers/users
are suffering unnecessarily.
> >
> > Which explains why you keep mentioning users, when the bug only exists in
> > CVS.
> > This is a very bad idea to be doing.
>
> I really don't understand this. What else are we supposed to be basing our
> sources on? There are two options here, apply patches from the Patches list
> in advance of their acceptance, or just stick with "official" releases (i.e.
> 5.0)
>
> There are lots of good patches, and lots of bad ones, in the patches mailing
> list. It is better, I think, for us to let the "experts" in the Maintainers
> group sort them out, and then use the results of this vetting process. That
> IS what the whole Maintainer's (or Helpers??) structure is for. Seems like
> subverting this process will just cause us more trouble.
>
> On the other hand, does anyone think an unmodified 5.0 is a good release to
> base our efforts on? It has been around for a while now, and has its own
> share of bugs that HAVE been fixed. In any case, you don't really WANT most
> of your gdb users to stick with the 5.0 release, do you? That would mean
> that the CVS changes are being tested by some set of Red Hat customers, and
> that is about all. That would not be a very good idea.
>
GDB 5.0 is so old and so broken (at least Insight is) that it is useless
to many
people. If you look at the insight mailing list archives, people have
been forced
to download newer snapshots or even the CVS version because they just
can't use
the 5.0.
If we had created a way to have a set of patches to 5.0 available, or
even created
some updated 5.0 releases with just bug fixes (no new feature -- bug
fixes applied
to the old 5.0 code base) this situation could be better. Even though,
there would
be things that the fixes would be to extensive to retrofit, and still
people
would have to resort to newer sources.
And developers also waste many hours because of known bugs with minor
fixes that just
werent comitted.
No matter how I look at it I can't find a good reason to leave bugs
laying around
when a fix is known.
--
Fernando Nasser
Red Hat Canada Ltd. E-Mail: fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario M4P 2C9
From kevinb@cygnus.com Mon Jan 15 12:34:00 2001
From: Kevin Buettner <kevinb@cygnus.com>
To: Fernando Nasser <fnasser@redhat.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: RFA: [infrun.c] Fix to "nexti".
Date: Mon, 15 Jan 2001 12:34:00 -0000
Message-id: <1010115203401.ZM6558@ocotillo.lan>
References: <3A54D5D2.CCA3E45E@redhat.com> <3A59DE42.5295C9A5@cygnus.com> <3A6318BF.A9A43A10@redhat.com> <20010115113635.B26739@redhat.com> <1010115175046.ZM6315@ocotillo.lan> <3A63418D.513E833@redhat.com> <fnasser@redhat.com>
X-SW-Source: 2001-01/msg00130.html
Content-length: 2437
On Jan 15, 1:29pm, Fernando Nasser wrote:
> Kevin Buettner wrote:
> >
> > On Jan 15, 11:36am, Christopher Faylor wrote:
> >
> > > On Mon, Jan 15, 2001 at 10:35:27AM -0500, Fernando Nasser wrote:
> > > >If there is a maintainer for this code please speak up.
> > > >
> > > >Otherwise I will check this in under the "obvious fix" rule.
> > >
> > > Do we really have an "obvious fix" rule? It seems that there is
> > > some confusion on this issue.
> >
> > We do not have an "obvious fix" rule. See
> >
> > http://sources.redhat.com/ml/gdb-patches/2000-04/msg00468.html
> >
>
> If you go throughout the list you'll find that it has been mentioned and
> invoked several times in other messages. It is not well defined though,
> and it does not seem to be written anywhere either.
Would you mind pointing a few of these out? I've searched for
"obvious" in the gdb-patches archive, but it generates a lot of hits.
(I'm curious about whether it's "blanket write privs" maintainers
who are invoking this rule.)
> As it is not written what to do when the maintainers do not respond and
> something is broken. Do we keep downloading rotten code? These bugs
> are very costly in that people waste hours of work because of them.
I don't know what the right answer is.
With regard to the infrun.c patch, however, I did take a look at it
and it wasn't clear to me that it was "obviously" right. I'm not
saying it's wrong either, but that code is complicated and requires
some study.
> The message above mentions a problem with regards to small fixes in
> codes outside one's maintainership that go wrong. Sometimes
> the original problem is fixed but some other is created.
> That is why we use CVS. The change can be reversed and the maintainer
> (when he/she shows up) has a complete record of what has been changed
> and
> why (in addition to the list archives).
>
> I don't know what is the better/right solution to the problem, but we do
> have a problem now with regarding to bug fixes, specially small fix to
> harmful ones. We do need a fast track to them and even consider
> temporary
> fixes (properly marked with FIXME and entries in the TODO file).
If those of us working on gdb could have some of their time freed up
to spend on our maintainership duties, that will clearly be a step in
the right direction. But I agree that we ought to have a process in
place to deal with the situations you describe.
From geoffk@geoffk.org Mon Jan 15 15:29:00 2001
From: Geoff Keating <geoffk@geoffk.org>
To: gdb-patches@sources.redhat.com
Subject: patch for ppc sim to fix open()
Date: Mon, 15 Jan 2001 15:29:00 -0000
Message-id: <200101152329.PAA00837@geoffk.org>
X-SW-Source: 2001-01/msg00131.html
Content-length: 1960
This makes the sim's emulation of the open() syscall match NetBSD,
even on hosts where the constants are different. I wanted this so
that Perennial tests could create temporary files.
(It's also dangerous to call open() with random flag values.)
--
- Geoffrey Keating <geoffk@geoffk.org>
===File ~/patches/cygnus/sim-ppcopen.patch==================
2000-12-29 Geoffrey Keating <geoffk@redhat.com>
* emul_netbsd.c (do_open): Translate the flag parameter to the
open syscall to the numbers supported by the host.
Index: emul_netbsd.c
===================================================================
RCS file: /cvs/cvsfiles/devo/sim/ppc/emul_netbsd.c,v
retrieving revision 1.30
diff -u -p -r1.30 emul_netbsd.c
--- emul_netbsd.c 2000/03/02 09:22:28 1.30
+++ emul_netbsd.c 2001/01/09 22:51:06
@@ -386,6 +386,7 @@ do_open(os_emul_data *emul,
char *path = emul_read_string(path_buf, path_addr, PATH_MAX, processor, cia);
int flags = (int)cpu_registers(processor)->gpr[arg0+1];
int mode = (int)cpu_registers(processor)->gpr[arg0+2];
+ int hostflags;
int status;
if (WITH_TRACE && ppc_trace[trace_os_emul])
@@ -393,8 +394,25 @@ do_open(os_emul_data *emul,
SYS(open);
+ /* Do some translation on 'flags' to match it to the host's version. */
+ /* These flag values were taken from the NetBSD 1.4 header files. */
+ if ((flags & 3) == 0)
+ hostflags = O_RDONLY;
+ else if ((flags & 3) == 1)
+ hostflags = O_WRONLY;
+ else
+ hostflags = O_RDWR;
+ if (flags & 0x00000008)
+ hostflags |= O_APPEND;
+ if (flags & 0x00000200)
+ hostflags |= O_CREAT;
+ if (flags & 0x00000400)
+ hostflags |= O_TRUNC;
+ if (flags & 0x00000800)
+ hostflags |= O_EXCL;
+
/* Can't combine these statements, cuz open sets errno. */
- status = open(path, flags, mode);
+ status = open(path, hostflags, mode);
emul_write_status(processor, status, errno);
}
============================================================
From jtc@redback.com Mon Jan 15 18:08:00 2001
From: jtc@redback.com (J.T. Conklin)
To: gdb-patches@sourceware.cygnus.com
Subject: patch to split embedded and linux sh targets
Date: Mon, 15 Jan 2001 18:08:00 -0000
Message-id: <5mzogss0zd.fsf@jtc.redback.com>
X-SW-Source: 2001-01/msg00132.html
Content-length: 2976
I submit the enclosed patch for a approval. The current sh target,
which was once a embedded only target has been made gnu/linux-specific
by the inclusion of shared library support.
This patch creates a embedded target (sh-*-coff*, sh-*-elf*) by moving
the linux bits to its own configuration (sh-*-linux*). I haven't
changed the linux config other than by renaming sh.mt to linux.mt,
although I believe that support for the SH3 ROM monitor, the e7000
ICE, and perhaps the SH simulator can be removed.
--jtc
2001-01-15 J.T. Conklin <jtc@redback.com>
* configure/sh/embed.mt: New file.
* configure/sh/linux.mt: New file.
* configure/sh/sh.mt: Removed.
* configure.tgt (sh-*-coff*, sh-*-elf*, sh-*-linux): New targets.
(sh-*-*): Removed.
Index: configure.tgt
===================================================================
RCS file: /cvs/src/src/gdb/configure.tgt,v
retrieving revision 1.16
diff -c -r1.16 configure.tgt
*** configure.tgt 2000/12/14 20:15:45 1.16
--- configure.tgt 2001/01/16 02:01:57
***************
*** 263,269 ****
rs6000-*-*) gdb_target=rs6000 ;;
sh*-*-pe) gdb_target=wince ;;
! sh-*-*) gdb_target=sh ;;
sparc-*-aout*) gdb_target=sparc-em ;;
sparc-*-coff*) gdb_target=sparc-em ;;
--- 263,271 ----
rs6000-*-*) gdb_target=rs6000 ;;
sh*-*-pe) gdb_target=wince ;;
! sh-*-coff*) gdb_target=embed ;;
! sh-*-elf*) gdb_target=embed ;;
! sh-*-linux*) gdb_target=linux ;;
sparc-*-aout*) gdb_target=sparc-em ;;
sparc-*-coff*) gdb_target=sparc-em ;;
Index: config/sh/embed.mt
===================================================================
RCS file: embed.mt
diff -N embed.mt
*** /dev/null Tue May 5 13:32:27 1998
--- embed.mt Mon Jan 15 18:01:57 2001
***************
*** 0 ****
--- 1,6 ----
+ # Target: Embedded Hitachi Super-H with ICE and simulator
+ TDEPFILES= sh-tdep.o monitor.o sh3-rom.o remote-e7000.o ser-e7kpc.o dsrec.o
+ TM_FILE= tm-sh.h
+
+ SIM_OBS = remote-sim.o
+ SIM = ../sim/sh/libsim.a
Index: config/sh/linux.mt
===================================================================
RCS file: linux.mt
diff -N linux.mt
*** /dev/null Tue May 5 13:32:27 1998
--- linux.mt Mon Jan 15 18:01:57 2001
***************
*** 0 ****
--- 1,6 ----
+ # Target: Hitachi Super-H running GNU/Linux
+ TDEPFILES= sh-tdep.o monitor.o sh3-rom.o remote-e7000.o ser-e7kpc.o dsrec.o solib.o solib-svr4.o
+ TM_FILE= tm-linux.h
+
+ SIM_OBS = remote-sim.o
+ SIM = ../sim/sh/libsim.a
Index: config/sh/sh.mt
===================================================================
RCS file: sh.mt
diff -N sh.mt
*** /sourceware/cvs-tmp/cvsiq6IWP Mon Jan 15 18:01:58 2001
--- /dev/null Tue May 5 13:32:27 1998
***************
*** 1,6 ****
- # Target: Hitachi Super-H with ICE and simulator
- TDEPFILES= sh-tdep.o monitor.o sh3-rom.o remote-e7000.o ser-e7kpc.o dsrec.o solib.o solib-svr4.o
- TM_FILE= tm-linux.h
-
- SIM_OBS = remote-sim.o
- SIM = ../sim/sh/libsim.a
--- 0 ----
--
J.T. Conklin
RedBack Networks
From ac131313@cygnus.com Mon Jan 15 19:39:00 2001
From: Andrew Cagney <ac131313@cygnus.com>
To: Nick Duffek <nsd@redhat.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [RFA] New register definition interface
Date: Mon, 15 Jan 2001 19:39:00 -0000
Message-id: <3A63C202.F418E4ED@cygnus.com>
References: <3A62408E.A745B2D6@cygnus.com> <200101151859.f0FIxqG05555@rtl.cygnus.com>
X-SW-Source: 2001-01/msg00133.html
Content-length: 2999
Nick Duffek wrote:
> The same issue applies to cli-regs.c: cliregs_init() attaches memory to
> each architecture even if the architecture hasn't set cliregs_info() as
> its do_registers_info callback.
>
> Some possible solutions:
>
> 1. Each competing module implementation introduces a gdbarch variable
> USE_<module-implementation> that architectures must set to 1 if
> they're using that implementation. For example:
I don't think it will scale. It is a bit like those
GDB_ARCHITECTURE_IS_D10V et.al. we'd all like to get rid of. The tests
should be for functionality not implementation.
However, a hack of yes/no ``register_module_installed_p'' flag might be
useful so that the default case (regcache) knows to not install its
self.
> 2. Each module introduces a gdbarch variable MODULE_<module-name> that
> architectures must set to an implementation-unique value.
Definitly not this one. Look at the spaghetti found in sim/common (yes
I'm in part to blame for that one :-)
> 3. Introduce a gdbarch interface to query function pointers. Competing
> module implementations can use these to check whether they're being
> used by the current architecture. For example:
>
> if (GET_DO_REGISTERS_INFO () != cliregs_info)
> return;
I don't think it should be necessary. Module implementations shouldn't
be competing - once a module, for a given architecture, is selected the
competing modules should never be seen again. Did I mention sim/common
:-)
The only exception would be where gdbarch asks the question ``has any
module been installed?'' If no - install the default.
> /* allocate memory */
>
> To avoid the footprint of a GET_*() function for every gdbarch.sh
> entry, a per-entry flag could be added that controls whether that
> function is needed.
4. Add a function like:
set_gdbarch_data (struct gdbarch *gdbarch,
struct gdbarch_data *handle,
void *value);
so that instead of waiting for gdbarch to call your
module, your module, as part of its set-up, calls
gdbarch vis:
gdbarch calls ..._gdbarch_init()
-> calls your_module's_init_or_setup_or_something()
-> calls set_gdbarch_data (gdbarch, your_modules_handle,
your_modules_data);
-> calls set_various_other_methods (...);
(mumble something about fine print, memory leaks and deleting
architectures :-)
I wouldn't be too worried if it for the short term (for GDB that is
about a year :-) build_regcache() still allocated a buffer - that is an
implementation issue (like using bubble sort :-). I'm worried about
interfaces not implementations :-). Just document the problem in the
code and TODO files.
Alternativly, like you were outlining, some sort of check to see if
a competing module hasn't already been installed.
Long long term, the register stuff could be combined into a group so
that it are installed as a block - instead of the N separate register
methods. Again, that is a separate problem.
Andrew
From ac131313@cygnus.com Mon Jan 15 19:44:00 2001
From: Andrew Cagney <ac131313@cygnus.com>
To: Nick Duffek <nsd@redhat.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [RFA] New register definition interface
Date: Mon, 15 Jan 2001 19:44:00 -0000
Message-id: <3A63C32F.5031F1FB@cygnus.com>
References: <3A62408E.A745B2D6@cygnus.com> <200101151859.f0FIxqG05555@rtl.cygnus.com>
X-SW-Source: 2001-01/msg00134.html
Content-length: 653
Nick Duffek wrote:
> Speaking of gdbarch.sh changes, what do you think about the idea of
> translating gdbarch.sh into C and automatically generating gdbarch.[ch] as
> transient compile-time entities? Running gdbarch.sh takes about 25
> seconds on my 650MHz Pentium, and I often forget to run it after applying
> or reverting patches that change it.
I wish :-)
The plan is to eventually have things autogenerated when GDB is
configured with --enable-maintainer-mode. Unfortunatly it can't be made
the default as you can bet your bottom dollar that gdbarch.sh will break
on some critical platform shell :-(
I'll add this to the TODO file.
Andrew
From bje@redhat.com Mon Jan 15 22:33:00 2001
From: Ben Elliston <bje@redhat.com>
To: gdb-patches@sources.redhat.com
Cc: bje@redhat.com
Subject: [testsuite] Contribution to testsuite/config
Date: Mon, 15 Jan 2001 22:33:00 -0000
Message-id: <200101160633.f0G6X4N19524@scooby.cygnus.com>
X-SW-Source: 2001-01/msg00135.html
Content-length: 4961
Attached is a copy of `sid.exp' -- a config file for DejaGNU to permit
GDB testing on simulators in the SID framework. Okay to commit?
2001-01-16 Ben Elliston <bje@redhat.com>
* config/sid.exp: New file.
# Test Framework Driver for GDB driving an external simulator
# Copyright 1999 Free Software Foundation, Inc. ?
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program; if not, write to the Free Software
# Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
load_lib gdb.exp
proc sid_start {} {
global sid_spawn_id
global verbose
set port [lindex [split [target_info netport] ":"] 1]
# Set a default endianness
case [target_info multilib_flags] in {
{ *big-endian* *-EB* *-meb* } { set sidendian "-EB" }
{ *little-endian* *-EL* *-mel* } { set sidendian "-EL" }
default {
if {[target_info exists sim,defaultendian]} then {
set sidendian [target_info sim,defaultendian]
} else {
warning "Unknown target endianness - assuming -EB"
set sidendian "-EB"
}
}
}
# set verbosity conditionally
if {$verbose > 0} then { set sidverbose "--verbose" } else { set sidverbose "" }
# test to see whether to use use sid in build or install tree
set use_build_tree [file exists ../../sid]
if {$use_build_tree} then {
set pre_spawn {
global env
set env(SID_LIBRARY_PATH) [join [glob "../../sid/component/*"] ":"]
set env(SID) "../../sid/main/dynamic/sid"
set env(MKSID) "../../sid/main/static/mksid"
if {! [file exists $env(SID)]} then { error "Cannot find sid in build tree" }
}
set spawncmd "../../sid/bsp/[target_info sim] $sidverbose $sidendian --persistent --gdb=$port [target_info sim,options]"
set post_spawn {
global env
unset env(SID_LIBRARY_PATH)
unset env(MKSID)
unset env(SID)
}
} else {
set pre_spawn {}
set spawncmd "[target_info sim] $sidverbose $sidendian --persistent --gdb=$port [target_info sim,options]"
set post_spawn {}
}
eval $pre_spawn
if {[catch "spawn $spawncmd" msg]} {
perror $msg
exit 1
}
eval $post_spawn
expect_background {
-re \[^\n\]*\n {
regsub "\n" $expect_out(buffer) {} msg
verbose "SID: $msg" 2
}
}
# There should be no need to sleep to give SID time to start;
# GDB would wait for a fair while for the stub to respond.
sleep 4
set sid_spawn_id $spawn_id
}
#
# Handle GDB talking to SID
#
proc gdb_start {} {
sid_start
return [default_gdb_start]
}
proc sid_exit {} {
global sid_spawn_id
if {[info exists sid_spawn_id]} {
catch {exec kill [exp_pid -i $sid_spawn_id]}
catch {wait -i $sid_spawn_id}
unset sid_spawn_id
sleep 4
}
}
proc gdb_exit {} {
set result [default_gdb_exit]
sid_exit
return $result
}
#
# gdb_target_sid
# Set gdb to target the simulator
#
proc send_target_sid { } {
# wait a little while, giving sid time to shut down & restart its
# gdb socket
sleep 4
send_gdb "target [target_info gdb_protocol] [target_info netport]\n"
}
proc gdb_target_sid { } {
global gdb_prompt
global exit_status
send_target_sid
global timeout
set prev_timeout $timeout
set timeout 60
verbose "Timeout is now $timeout seconds" 2
gdb_expect {
-re "Remote debugging using.*$gdb_prompt" {
verbose "Set target to sid"
}
timeout {
perror "Couldn't set target for remote simulator."
cleanup
exit $exit_status
}
}
set timeout $prev_timeout
verbose "Timeout is now $timeout seconds" 2
}
#
# gdb_load -- load a file into the debugger.
# return a -1 if anything goes wrong.
#
proc gdb_load { arg } {
global verbose
global loadpath
global loadfile
global GDB
global gdb_prompt
gdb_unload
if [gdb_file_cmd $arg] then { return -1 }
gdb_target_sid
send_gdb "load\n"
global timeout
set prev_timeout $timeout
set timeout 2400
verbose "Timeout is now $timeout seconds" 2
gdb_expect {
-re ".*$gdb_prompt $" {
if $verbose>1 then {
send_user "Loaded $arg into $GDB\n"
}
set timeout 30
verbose "Timeout is now $timeout seconds" 2
return 1
}
-re "$gdb_prompt $" {
if $verbose>1 then {
perror "GDB couldn't load."
}
}
timeout {
if $verbose>1 then {
perror "Timed out trying to load $arg."
}
}
}
set timeout $prev_timeout
}
From fnasser@cygnus.com Tue Jan 16 08:56:00 2001
From: Fernando Nasser <fnasser@cygnus.com>
To: Ben Elliston <bje@redhat.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [testsuite] Contribution to testsuite/config
Date: Tue, 16 Jan 2001 08:56:00 -0000
Message-id: <3A647D4B.4B343299@cygnus.com>
References: <200101160633.f0G6X4N19524@scooby.cygnus.com>
X-SW-Source: 2001-01/msg00136.html
Content-length: 6022
Ben Elliston wrote:
>
> Attached is a copy of `sid.exp' -- a config file for DejaGNU to permit
> GDB testing on simulators in the SID framework. Okay to commit?
>
Sure thanks.
Fernando
> 2001-01-16 Ben Elliston <bje@redhat.com>
>
> * config/sid.exp: New file.
>
> # Test Framework Driver for GDB driving an external simulator
> # Copyright 1999 Free Software Foundation, Inc. ?
> #
> # This program is free software; you can redistribute it and/or modify
> # it under the terms of the GNU General Public License as published by
> # the Free Software Foundation; either version 2 of the License, or
> # (at your option) any later version.
> #
> # This program is distributed in the hope that it will be useful,
> # but WITHOUT ANY WARRANTY; without even the implied warranty of
> # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> # GNU General Public License for more details.
> #
> # You should have received a copy of the GNU General Public License
> # along with this program; if not, write to the Free Software
> # Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
>
> load_lib gdb.exp
>
> proc sid_start {} {
> global sid_spawn_id
> global verbose
>
> set port [lindex [split [target_info netport] ":"] 1]
>
> # Set a default endianness
> case [target_info multilib_flags] in {
> { *big-endian* *-EB* *-meb* } { set sidendian "-EB" }
> { *little-endian* *-EL* *-mel* } { set sidendian "-EL" }
> default {
> if {[target_info exists sim,defaultendian]} then {
> set sidendian [target_info sim,defaultendian]
> } else {
> warning "Unknown target endianness - assuming -EB"
> set sidendian "-EB"
> }
> }
> }
> # set verbosity conditionally
> if {$verbose > 0} then { set sidverbose "--verbose" } else { set sidverbose "" }
>
> # test to see whether to use use sid in build or install tree
> set use_build_tree [file exists ../../sid]
>
> if {$use_build_tree} then {
> set pre_spawn {
> global env
> set env(SID_LIBRARY_PATH) [join [glob "../../sid/component/*"] ":"]
> set env(SID) "../../sid/main/dynamic/sid"
> set env(MKSID) "../../sid/main/static/mksid"
> if {! [file exists $env(SID)]} then { error "Cannot find sid in build tree" }
> }
> set spawncmd "../../sid/bsp/[target_info sim] $sidverbose $sidendian --persistent --gdb=$port [target_info sim,options]"
> set post_spawn {
> global env
> unset env(SID_LIBRARY_PATH)
> unset env(MKSID)
> unset env(SID)
> }
> } else {
> set pre_spawn {}
> set spawncmd "[target_info sim] $sidverbose $sidendian --persistent --gdb=$port [target_info sim,options]"
> set post_spawn {}
> }
>
> eval $pre_spawn
> if {[catch "spawn $spawncmd" msg]} {
> perror $msg
> exit 1
> }
> eval $post_spawn
>
> expect_background {
> -re \[^\n\]*\n {
> regsub "\n" $expect_out(buffer) {} msg
> verbose "SID: $msg" 2
> }
> }
>
> # There should be no need to sleep to give SID time to start;
> # GDB would wait for a fair while for the stub to respond.
> sleep 4
>
> set sid_spawn_id $spawn_id
> }
>
> #
> # Handle GDB talking to SID
> #
>
> proc gdb_start {} {
> sid_start
> return [default_gdb_start]
> }
>
> proc sid_exit {} {
> global sid_spawn_id
> if {[info exists sid_spawn_id]} {
> catch {exec kill [exp_pid -i $sid_spawn_id]}
> catch {wait -i $sid_spawn_id}
> unset sid_spawn_id
> sleep 4
> }
> }
>
> proc gdb_exit {} {
> set result [default_gdb_exit]
> sid_exit
> return $result
> }
>
> #
> # gdb_target_sid
> # Set gdb to target the simulator
> #
> proc send_target_sid { } {
> # wait a little while, giving sid time to shut down & restart its
> # gdb socket
> sleep 4
> send_gdb "target [target_info gdb_protocol] [target_info netport]\n"
> }
>
> proc gdb_target_sid { } {
> global gdb_prompt
> global exit_status
>
> send_target_sid
>
> global timeout
> set prev_timeout $timeout
> set timeout 60
> verbose "Timeout is now $timeout seconds" 2
> gdb_expect {
> -re "Remote debugging using.*$gdb_prompt" {
> verbose "Set target to sid"
> }
> timeout {
> perror "Couldn't set target for remote simulator."
> cleanup
> exit $exit_status
> }
> }
> set timeout $prev_timeout
> verbose "Timeout is now $timeout seconds" 2
> }
>
> #
> # gdb_load -- load a file into the debugger.
> # return a -1 if anything goes wrong.
> #
> proc gdb_load { arg } {
> global verbose
> global loadpath
> global loadfile
> global GDB
> global gdb_prompt
>
> gdb_unload
> if [gdb_file_cmd $arg] then { return -1 }
> gdb_target_sid
>
> send_gdb "load\n"
> global timeout
> set prev_timeout $timeout
> set timeout 2400
> verbose "Timeout is now $timeout seconds" 2
> gdb_expect {
> -re ".*$gdb_prompt $" {
> if $verbose>1 then {
> send_user "Loaded $arg into $GDB\n"
> }
> set timeout 30
> verbose "Timeout is now $timeout seconds" 2
> return 1
> }
> -re "$gdb_prompt $" {
> if $verbose>1 then {
> perror "GDB couldn't load."
> }
> }
> timeout {
> if $verbose>1 then {
> perror "Timed out trying to load $arg."
> }
> }
> }
> set timeout $prev_timeout
> }
--
Fernando Nasser
Red Hat - Toronto E-Mail: fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario M4P 2C9
From fnasser@cygnus.com Tue Jan 16 09:27:00 2001
From: Fernando Nasser <fnasser@cygnus.com>
To: Michael Snyder <msnyder@redhat.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [Fwd: RFA: [infrun.c] Fix to "nexti".]
Date: Tue, 16 Jan 2001 09:27:00 -0000
Message-id: <3A648467.8B949E89@cygnus.com>
References: <3A634581.9C1C76CD@redhat.com>
X-SW-Source: 2001-01/msg00137.html
Content-length: 2278
Michael Snyder wrote:
>
> Christopher Faylor wrote:
> >
> > On Mon, Jan 15, 2001 at 10:35:27AM -0500, Fernando Nasser wrote:
> > >If there is a maintainer for this code please speak up.
> > >
> > >Otherwise I will check this in under the "obvious fix" rule.
> >
> > Do we really have an "obvious fix" rule? It seems that there is
> > some confusion on this issue.
>
> We do (I think), but when you're discussing infrun.c, I'm not
> sure that any change can be regarded as "obviously correct".
> At least not in the wait_for_inferior/handle_event area.
>
Well, someone must be able to evaluate it and make a decision.
This thing has no specific maintainer (I could not find in the
MAINTAINERS file) and people keep avoiding it. But it is broken
and has to be fixed. What are we going to to about it?
Or will we add in the Users manual that a "nexti" command should
not be used inside a function prologue or it will work as a "continue"?
> By eyeball, this change looks correct to me, or at least
> "not obviously incorrect". I would like to see it tested,
> and perhaps the best way to do that is to apply it and then
> notice if there's a sudden uptick in testsuite failures.
>
Well, of course I run the testsuite on it on a couple of targets and
with a couple of versions of gcc. This means little with this code
as it is used by all targets but what else can I do?
When the code that was originally there was removed years ago and
replaced with a very simplified test, all the knowledge that was
accumulated over the years about different situations that can arise
was lost. All that we can do know is to start accumulating that
knowledge again by adding the appropriate tests for the cases where
it fails.
But if the bug fixes are just ignored and remain as a lost message in the
list archives we will never evolve from where we are now.
We could have a page with known bugs and patches that fix them, with some
mechanism for feedback. But at the moment, all we can do is to install
the fix and see if there is some hidden condition that was not accounted for
and either revert it or refine it further.
--
Fernando Nasser
Red Hat - Toronto E-Mail: fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario M4P 2C9
From msnyder@cygnus.com Tue Jan 16 09:36:00 2001
From: Michael Snyder <msnyder@cygnus.com>
To: gdb-patches@sources.redhat.com
Subject: [PATCH] Fix typo in comment.
Date: Tue, 16 Jan 2001 09:36:00 -0000
Message-id: <200101161736.JAA18782@cleaver.cygnus.com>
X-SW-Source: 2001-01/msg00138.html
Content-length: 1324
2001-01-16 Michael Snyder <msnyder@cleaver.cygnus.com>
* source.c (openp): Fix typo in comment.
Index: source.c
===================================================================
RCS file: /cvs/src/src/gdb/source.c,v
retrieving revision 1.6
diff -c -3 -p -r1.6 source.c
*** source.c 2000/12/15 01:01:49 1.6
--- source.c 2001/01/16 17:34:51
*************** source_info (char *ignore, int from_tty)
*** 500,506 ****
so that "exec-file ./foo" or "symbol-file ./foo" insures that you
get that particular version of foo or an error message).
! If FILENAMED_OPENED is non-null, set it to a newly allocated string naming
the actual file opened (this string will always start with a "/". We
have to take special pains to avoid doubling the "/" between the directory
and the file, sigh! Emacs gets confuzzed by this when we print the
--- 500,506 ----
so that "exec-file ./foo" or "symbol-file ./foo" insures that you
get that particular version of foo or an error message).
! If FILENAME_OPENED is non-null, set it to a newly allocated string naming
the actual file opened (this string will always start with a "/". We
have to take special pains to avoid doubling the "/" between the directory
and the file, sigh! Emacs gets confuzzed by this when we print the
From msnyder@cygnus.com Tue Jan 16 09:41:00 2001
From: Michael Snyder <msnyder@cygnus.com>
To: gdb-patches@sources.redhat.com
Subject: [PATCH]: minor fix to procfs_stopped_by_watchpoint
Date: Tue, 16 Jan 2001 09:41:00 -0000
Message-id: <200101161741.JAA18804@cleaver.cygnus.com>
X-SW-Source: 2001-01/msg00139.html
Content-length: 1054
2001-01-16 Michael Snyder <msnyder@cleaver.cygnus.com>
* procfs.c (procfs_stopped_by_watchpoint): Don't die if process
goes away -- just return false (ie. not stopped by watchpoint).
Index: procfs.c
===================================================================
RCS file: /cvs/src/src/gdb/procfs.c,v
retrieving revision 1.21
diff -c -3 -p -r1.21 procfs.c
*** procfs.c 2000/12/15 01:01:48 1.21
--- procfs.c 2001/01/16 17:39:47
*************** procfs_stopped_by_watchpoint (int pid)
*** 4793,4800 ****
{
procinfo *pi;
! pi = find_procinfo_or_die (pid == -1 ?
! PIDGET (inferior_pid) : PIDGET (pid), 0);
if (proc_flags (pi) & (PR_STOPPED | PR_ISTOP))
{
if (proc_why (pi) == PR_FAULTED)
--- 4793,4804 ----
{
procinfo *pi;
! pi = find_procinfo (pid == -1 ?
! PIDGET (inferior_pid) : PIDGET (pid), 0);
!
! if (!pi) /* If no process, then not stopped by watchpoint! */
! return 0;
!
if (proc_flags (pi) & (PR_STOPPED | PR_ISTOP))
{
if (proc_why (pi) == PR_FAULTED)
From nsd@redhat.com Tue Jan 16 12:17:00 2001
From: Nick Duffek <nsd@redhat.com>
To: ac131313@cygnus.com
Cc: gdb-patches@sources.redhat.com
Subject: Re: [RFA] New register definition interface
Date: Tue, 16 Jan 2001 12:17:00 -0000
Message-id: <200101162018.PAA27643@nog.bosbc.com>
References: <3A63C202.F418E4ED@cygnus.com>
X-SW-Source: 2001-01/msg00140.html
Content-length: 1564
On 16-Jan-2001, Andrew Cagney wrote:
>4. Add a function like:
>
> set_gdbarch_data (struct gdbarch *gdbarch,
> struct gdbarch_data *handle,
> void *value);
[...]
> gdbarch calls ..._gdbarch_init()
> -> calls your_module's_init_or_setup_or_something()
> -> calls set_gdbarch_data (gdbarch, your_modules_handle,
>your_modules_data);
> -> calls set_various_other_methods (...);
That looks good to me. It's very similar to what regs.c does, except that
it calls set_gdbarch_register_list() instead of set_gdbarch_data().
Specifically:
1. <arch>_gdbarch_init() in <arch>-tdep.c calls regs_init_finish().
2. regs_init_finish() calls set_gdbarch_register_list().
3. regs_init_finish() also calls set_gdbarch_num_regs() and various
other set_gdbarch_*() functions.
For regs.c, I really need to do the above or something similar, because
the information collected between regs_init_start(<gdbarch>) and
regs_init_finish() must be attached to <gdbarch>.
For cli-regs.c, I can use register_gdbarch_data() if I'm willing to waste
memory. I can deal with the memory waste by:
1. ignoring it;
2. using regs.c's approach with e.g. CLIREGS_INTERNAL instead of
REGISTER_LIST;
3. implementing set_gdbarch_data().
I'd prefer 2 or 3. Do you have a preference?
>However, a hack of yes/no ``register_module_installed_p'' flag might be
>useful so that the default case (regcache) knows to not install its
>self.
Since we're talking hacks, I think I might as well use REGISTER_LIST
rather than adding a new REGISTER_MODULE_INSTALLED_P method.
Nick
From ac131313@cygnus.com Tue Jan 16 14:33:00 2001
From: Andrew Cagney <ac131313@cygnus.com>
To: Nick Duffek <nsd@redhat.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [RFA] New register definition interface
Date: Tue, 16 Jan 2001 14:33:00 -0000
Message-id: <3A64CBAE.D480ADB7@cygnus.com>
References: <3A63C202.F418E4ED@cygnus.com> <200101162018.PAA27643@nog.bosbc.com>
X-SW-Source: 2001-01/msg00141.html
Content-length: 1164
Nick Duffek wrote:
>
> On 16-Jan-2001, Andrew Cagney wrote:
>
> >4. Add a function like:
> >
> > set_gdbarch_data (struct gdbarch *gdbarch,
> > struct gdbarch_data *handle,
> > void *value);
> [...]
> > gdbarch calls ..._gdbarch_init()
> > -> calls your_module's_init_or_setup_or_something()
> > -> calls set_gdbarch_data (gdbarch, your_modules_handle,
> >your_modules_data);
> > -> calls set_various_other_methods (...);
>
> That looks good to me. It's very similar to what regs.c does, except that
> it calls set_gdbarch_register_list() instead of set_gdbarch_data().
The difference is that the data is kept private to the regs.c file
(those interfaces again). It isn't possible for external code to go
grubbing around in internals when you're not looking.
> Since we're talking hacks, I think I might as well use REGISTER_LIST
> rather than adding a new REGISTER_MODULE_INSTALLED_P method.
The nice thing about REGISTER_MODULE_INSTALLED_P() is that it is so
informative that the caller can conclude nothing about the actual
module. This is a good thing :-)
Andrew
From jtc@redback.com Tue Jan 16 14:59:00 2001
From: jtc@redback.com (J.T. Conklin)
To: Fernando Nasser <fnasser@redhat.com>
Cc: matthew green <mrg@cygnus.com>, gdb-patches@sources.redhat.com
Subject: Re: patch for compiles that don't define "unix"
Date: Tue, 16 Jan 2001 14:59:00 -0000
Message-id: <5mvgrf6r3a.fsf@jtc.redback.com>
References: <22097.979473536@cygnus.com> <3A61CF62.34A9FFE2@redhat.com>
X-SW-Source: 2001-01/msg00142.html
Content-length: 1814
>>>>> "Fernando" == Fernando Nasser <fnasser@redhat.com> writes:
Fernando> This is not the proper fix though. The rdi-share
Fernando> subdirectory is supposed to contain code shared with ARM, so
Fernando> we shouldn't make local modifications in there (unless
Fernando> absolutely necessary).
Doesn't "sharing" imply something more than just importing third party
code? There should be a mechanism where we can at least advocate that
a change be made to shared source.
I note that there are a lot of __CYGWIN32__ conditionals. How did they
get into rdi-share? Unfortunately there is no documentation within rdi-
share that says how to obtain the master copy so I can compare, but it
ultimately doesn't matter. Either there is a mechanism to get these
changes incorporated, or the rule about making local changes is flexible.
Fernando> In this case we are better off with a more general fix that
Fernando> will solve all possible occurrences of the lack of "unix"
Fernando> problem.
While mrg came up with an alternate patch, I'm not convinced it's
better than his original. The original patch made defined __unix if
either "unix" or "__unix__" is defined. IMO, this makes a lot more
sense than the alternate solution where __unix is defined if unix is
defined in host.h, but __unix is defined if __unix__ is defined via
autoconf & makefiles.
But if you take a look at how __unix is used, you'll see that it is
used to determine whether the host is a "fairly recent" UN*X-ish host.
It's used to determine whether to use sigaction() or signal(), whether
the host has gettimeofday(), etc. IMO, these are should be replaced
by specific feature tests. I suspect that a lot of older UN*X systems
that define unix will not build rdi-share sources as is.
--jtc
--
J.T. Conklin
RedBack Networks
From msnyder@redhat.com Tue Jan 16 15:02:00 2001
From: Michael Snyder <msnyder@redhat.com>
To: jtc@redback.com
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: patch to split embedded and linux sh targets
Date: Tue, 16 Jan 2001 15:02:00 -0000
Message-id: <3A64D310.6A39F1D7@redhat.com>
References: <5mzogss0zd.fsf@jtc.redback.com>
X-SW-Source: 2001-01/msg00143.html
Content-length: 3504
JT,
What exactly is broken? What are you fixing?
As far as I know, "sh-elf" builds, and so does "sh-linux-elf".
"J.T. Conklin" wrote:
>
> I submit the enclosed patch for a approval. The current sh target,
> which was once a embedded only target has been made gnu/linux-specific
> by the inclusion of shared library support.
>
> This patch creates a embedded target (sh-*-coff*, sh-*-elf*) by moving
> the linux bits to its own configuration (sh-*-linux*). I haven't
> changed the linux config other than by renaming sh.mt to linux.mt,
> although I believe that support for the SH3 ROM monitor, the e7000
> ICE, and perhaps the SH simulator can be removed.
>
> --jtc
>
> 2001-01-15 J.T. Conklin <jtc@redback.com>
>
> * configure/sh/embed.mt: New file.
> * configure/sh/linux.mt: New file.
> * configure/sh/sh.mt: Removed.
> * configure.tgt (sh-*-coff*, sh-*-elf*, sh-*-linux): New targets.
> (sh-*-*): Removed.
>
> Index: configure.tgt
> ===================================================================
> RCS file: /cvs/src/src/gdb/configure.tgt,v
> retrieving revision 1.16
> diff -c -r1.16 configure.tgt
> *** configure.tgt 2000/12/14 20:15:45 1.16
> --- configure.tgt 2001/01/16 02:01:57
> ***************
> *** 263,269 ****
> rs6000-*-*) gdb_target=rs6000 ;;
>
> sh*-*-pe) gdb_target=wince ;;
> ! sh-*-*) gdb_target=sh ;;
>
> sparc-*-aout*) gdb_target=sparc-em ;;
> sparc-*-coff*) gdb_target=sparc-em ;;
> --- 263,271 ----
> rs6000-*-*) gdb_target=rs6000 ;;
>
> sh*-*-pe) gdb_target=wince ;;
> ! sh-*-coff*) gdb_target=embed ;;
> ! sh-*-elf*) gdb_target=embed ;;
> ! sh-*-linux*) gdb_target=linux ;;
>
> sparc-*-aout*) gdb_target=sparc-em ;;
> sparc-*-coff*) gdb_target=sparc-em ;;
> Index: config/sh/embed.mt
> ===================================================================
> RCS file: embed.mt
> diff -N embed.mt
> *** /dev/null Tue May 5 13:32:27 1998
> --- embed.mt Mon Jan 15 18:01:57 2001
> ***************
> *** 0 ****
> --- 1,6 ----
> + # Target: Embedded Hitachi Super-H with ICE and simulator
> + TDEPFILES= sh-tdep.o monitor.o sh3-rom.o remote-e7000.o ser-e7kpc.o dsrec.o
> + TM_FILE= tm-sh.h
> +
> + SIM_OBS = remote-sim.o
> + SIM = ../sim/sh/libsim.a
> Index: config/sh/linux.mt
> ===================================================================
> RCS file: linux.mt
> diff -N linux.mt
> *** /dev/null Tue May 5 13:32:27 1998
> --- linux.mt Mon Jan 15 18:01:57 2001
> ***************
> *** 0 ****
> --- 1,6 ----
> + # Target: Hitachi Super-H running GNU/Linux
> + TDEPFILES= sh-tdep.o monitor.o sh3-rom.o remote-e7000.o ser-e7kpc.o dsrec.o solib.o solib-svr4.o
> + TM_FILE= tm-linux.h
> +
> + SIM_OBS = remote-sim.o
> + SIM = ../sim/sh/libsim.a
> Index: config/sh/sh.mt
> ===================================================================
> RCS file: sh.mt
> diff -N sh.mt
> *** /sourceware/cvs-tmp/cvsiq6IWP Mon Jan 15 18:01:58 2001
> --- /dev/null Tue May 5 13:32:27 1998
> ***************
> *** 1,6 ****
> - # Target: Hitachi Super-H with ICE and simulator
> - TDEPFILES= sh-tdep.o monitor.o sh3-rom.o remote-e7000.o ser-e7kpc.o dsrec.o solib.o solib-svr4.o
> - TM_FILE= tm-linux.h
> -
> - SIM_OBS = remote-sim.o
> - SIM = ../sim/sh/libsim.a
> --- 0 ----
>
> --
> J.T. Conklin
> RedBack Networks
From bje@redhat.com Tue Jan 16 15:02:00 2001
From: Ben Elliston <bje@redhat.com>
To: Fernando Nasser <fnasser@cygnus.com>
Cc: <gdb-patches@sources.redhat.com>
Subject: Re: [testsuite] Contribution to testsuite/config
Date: Tue, 16 Jan 2001 15:02:00 -0000
Message-id: <Pine.LNX.4.31.0101170948510.26663-100000@moshpit.cygnus.com>
References: <3A647D4B.4B343299@cygnus.com>
X-SW-Source: 2001-01/msg00144.html
Content-length: 44
Sure thanks.
Commited. Thanks,
Ben
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2001-01-19 8:25 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <200101121935.LAA03678@scv2.apple.com>
2001-01-12 12:13 ` [patch] fix for infinite recursion in lookup_symbol Fernando Nasser
2001-01-17 13:09 ` Elena Zannoni
[not found] ` <20010117161229.B15404@redhat.com>
2001-01-17 13:55 ` Fernando Nasser
[not found] <B6889200.268C%jingham@apple.com>
2001-01-15 12:14 ` Fernando Nasser
[not found] <200101172157.QAA21576@texas.cygnus.com>
[not found] ` <14950.6503.362049.921003@kwikemart.cygnus.com>
2001-01-18 15:35 ` Jim Blandy
[not found] <Pine.SUN.3.91.1010118181831.8466B-100000@is>
[not found] ` <3A677652.FA74EAD0@neurizon.net>
[not found] ` <6480-Fri19Jan2001122012+0200-eliz@is.elta.co.il>
2001-01-19 8:25 ` Chris Faylor
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox