From: Dmitry Sivachenko <dima@Chg.RU>
To: eliz@is.elta.co.il
Cc: jimb@zwingli.cygnus.com, gdb-patches@sourceware.cygnus.com,
law@cygnus.com
Subject: Re: RFA: distinguish between pointers and addresses
Date: Tue, 11 Apr 2000 04:37:00 -0000 [thread overview]
Message-ID: <200004111137.PAA90844@netserv1.chg.ru> (raw)
In-Reply-To: <200004111134.HAA03852@indy.delorie.com>
> + To cope with architectures like this --- the D10V is not the only one!
> + --- GDB tries to distinguish between @code{addresses}, which are byte
> + numbers, and @code{pointers}, which are the target's representation of
<snip>
> + This yields an address
> + appropriate GDB can use to read target memory, disassemble, etc.
Also consider using @value{GDBN} instead of 'GDB'. :)
--dima
From eliz@delorie.com Tue Apr 11 04:46:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: dan@cgsoftware.com
Cc: ac131313@cygnus.com, phdm@macqel.be, gdb-patches@sourceware.cygnus.com
Subject: Re: PATCH/RFA free(NULL) bomb in printcmd.c
Date: Tue, 11 Apr 2000 04:46:00 -0000
Message-id: <200004111145.HAA03863@indy.delorie.com>
References: <Pine.LNX.4.10.10004102016240.6061-100000@propylaea.anduin.com>
X-SW-Source: 2000-04/msg00215.html
Content-length: 437
> Then again, i dmallocified GDB about a week and a half ago (which was
> quite a chore, involving dmallocifying libiberty, etc. I got literally
> every call), and i stopped fixing null pointer frees after about 35th one.
> So he's really going to be fighting an uphill battle.
Do we really need to fight that battle, though?
IIRC, GDB now assumes ISO C, right? And the C89 standard clearly says
that "free(NULL);" should be a no-op.
From kettenis@wins.uva.nl Tue Apr 11 04:52:00 2000
From: Mark Kettenis <kettenis@wins.uva.nl>
To: eliz@is.elta.co.il
Cc: dan@cgsoftware.com, ac131313@cygnus.com, phdm@macqel.be, gdb-patches@sourceware.cygnus.com
Subject: Re: PATCH/RFA free(NULL) bomb in printcmd.c
Date: Tue, 11 Apr 2000 04:52:00 -0000
Message-id: <200004111152.NAA00988@landau.wins.uva.nl>
References: <Pine.LNX.4.10.10004102016240.6061-100000@propylaea.anduin.com> <200004111145.HAA03863@indy.delorie.com>
X-SW-Source: 2000-04/msg00216.html
Content-length: 762
Date: Tue, 11 Apr 2000 07:45:28 -0400 (EDT)
From: Eli Zaretskii <eliz@delorie.com>
> Then again, i dmallocified GDB about a week and a half ago (which was
> quite a chore, involving dmallocifying libiberty, etc. I got literally
> every call), and i stopped fixing null pointer frees after about 35th one.
> So he's really going to be fighting an uphill battle.
Do we really need to fight that battle, though?
IIRC, GDB now assumes ISO C, right? And the C89 standard clearly says
that "free(NULL);" should be a no-op.
The idea is that GDB assumes an ISO C *compiler*, the rationale being
that you can always use GCC. However, the C library doesn't have to
be ISO C compliant, and there isn't that much one can do abou that.
Mark
From eliz@delorie.com Tue Apr 11 06:56:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: Dmitry Sivachenko <dima@Chg.RU>
Cc: jimb@zwingli.cygnus.com, gdb-patches@sourceware.cygnus.com
Subject: Re: RFA: distinguish between pointers and addresses
Date: Tue, 11 Apr 2000 06:56:00 -0000
Message-id: <200004111356.JAA03980@indy.delorie.com>
References: <200004102022.PAA26368@zwingli.cygnus.com> <200004111134.HAA03852@indy.delorie.com> <200004111137.PAA90844@netserv1.chg.ru>
X-SW-Source: 2000-04/msg00217.html
Content-length: 292
> Also consider using @value{GDBN} instead of 'GDB'. :)
It seems that gdbint.texinfo doesn't use that convention. So there's
no need to do it in this particular fragment, IMHO.
Unless, of course, we want to convert all instances of GDB into
@value{GDBN} in gdbint.texinfo as well. Stan?
From shebs@apple.com Tue Apr 11 11:27:00 2000
From: Stan Shebs <shebs@apple.com>
To: Eli Zaretskii <eliz@is.elta.co.il>
Cc: Dmitry Sivachenko <dima@Chg.RU>, jimb@zwingli.cygnus.com, gdb-patches@sourceware.cygnus.com
Subject: Re: RFA: distinguish between pointers and addresses
Date: Tue, 11 Apr 2000 11:27:00 -0000
Message-id: <38F36E60.E9E10ED9@apple.com>
References: <200004102022.PAA26368@zwingli.cygnus.com> <200004111134.HAA03852@indy.delorie.com> <200004111137.PAA90844@netserv1.chg.ru> <200004111356.JAA03980@indy.delorie.com>
X-SW-Source: 2000-04/msg00218.html
Content-length: 854
Eli Zaretskii wrote:
>
> > Also consider using @value{GDBN} instead of 'GDB'. :)
>
> It seems that gdbint.texinfo doesn't use that convention. So there's
> no need to do it in this particular fragment, IMHO.
>
> Unless, of course, we want to convert all instances of GDB into
> @value{GDBN} in gdbint.texinfo as well. Stan?
Well, gdbint.texinfo is a less formal document, and its audience
is considerably smaller than for the regular manual. On the
other hand, it saves valuable brain cells when we can use a
consistent set of rules for all of our documents, and who knows,
perhaps one day we'll want to follow GCC's example and put our
internals info into the regular GDB manual (hmmm, maybe not :-) ).
So I'd say we should start using @value{GDBN} and our other
doc conventions in gdbint.texinfo, converting things other as
time allows.
Stan
From dan@cgsoftware.com Tue Apr 11 11:57:00 2000
From: Daniel Berlin <dan@cgsoftware.com>
To: Stan Shebs <shebs@apple.com>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: RFA: distinguish between pointers and addresses
Date: Tue, 11 Apr 2000 11:57:00 -0000
Message-id: <Pine.LNX.4.10.10004111154460.10642-200000@propylaea.anduin.com>
References: <38F36E60.E9E10ED9@apple.com>
X-SW-Source: 2000-04/msg00219.html
Content-length: 658
On Tue, 11 Apr 2000, Stan Shebs wrote:
>
> Well, gdbint.texinfo is a less formal document, and its audience
> is considerably smaller than for the regular manual. On the
> other hand, it saves valuable brain cells when we can use a
> consistent set of rules for all of our documents, and who knows,
> perhaps one day we'll want to follow GCC's example and put our
> internals info into the regular GDB manual (hmmm, maybe not :-) ).
>
> So I'd say we should start using @value{GDBN} and our other
> doc conventions in gdbint.texinfo, converting things other as
> time allows.
Here's a patch that takes care of the @value{GDBN} part of it.
>
> Stan
>
From shebs@apple.com Tue Apr 11 12:03:00 2000
From: Stan Shebs <shebs@apple.com>
To: Daniel Berlin <dan@cgsoftware.com>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: RFA: distinguish between pointers and addresses
Date: Tue, 11 Apr 2000 12:03:00 -0000
Message-id: <38F376FA.13E9F3CE@apple.com>
References: <Pine.LNX.4.10.10004111154460.10642-200000@propylaea.anduin.com>
X-SW-Source: 2000-04/msg00220.html
Content-length: 728
Daniel Berlin wrote:
>
> On Tue, 11 Apr 2000, Stan Shebs wrote:
> >
> > Well, gdbint.texinfo is a less formal document, and its audience
> > is considerably smaller than for the regular manual. On the
> > other hand, it saves valuable brain cells when we can use a
> > consistent set of rules for all of our documents, and who knows,
> > perhaps one day we'll want to follow GCC's example and put our
> > internals info into the regular GDB manual (hmmm, maybe not :-) ).
> >
> > So I'd say we should start using @value{GDBN} and our other
> > doc conventions in gdbint.texinfo, converting things other as
> > time allows.
>
> Here's a patch that takes care of the @value{GDBN} part of it.
Excellent! Commit that puppy. -s
From dan@cgsoftware.com Tue Apr 11 13:35:00 2000
From: dan@cgsoftware.com (Daniel Berlin+list.gdb-patches)
To: gdb-patches@sourceware.cygnus.com
Subject: Re: RFA: distinguish between pointers and addresses
Date: Tue, 11 Apr 2000 13:35:00 -0000
Message-id: <aej0jrzj.fsf@dan.resnet.rochester.edu>
References: <Pine.LNX.4.10.10004111154460.10642-200000@propylaea.anduin.com> <38F376FA.13E9F3CE@apple.com>
X-SW-Source: 2000-04/msg00221.html
Content-length: 301
>>>>> "Stan" == Stan Shebs <shebs@apple.com> writes:
Does this go on just the trunk, or on the 5.0 branch as well?
If you want it on the 5.0 branch, i'd appreciate if you could do that
part of the commit, i don't have the 5.0 tree checked out yet.
--Dan
Stan> Excellent! Commit that puppy. -s
From msnyder@cygnus.com Tue Apr 11 13:40:00 2000
From: Michael Snyder <msnyder@cygnus.com>
To: dan@cgsoftware.com
Cc: gdb-patches@sourceware.cygnus.com
Subject: eval.c -- ChangeLog entry?
Date: Tue, 11 Apr 2000 13:40:00 -0000
Message-id: <38F38D66.5130@cygnus.com>
X-SW-Source: 2000-04/msg00222.html
Content-length: 128
Dan,
Were you planning to make a ChangeLog entry for the C++
changes that you checked in on April 4?
Thanks,
Michael
From law@cygnus.com Tue Apr 11 13:44:00 2000
From: Jeffrey A Law <law@cygnus.com>
To: aoliva@cygnus.com
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: gdb-patches Digest 7 Apr 2000 22:38:48 -0000 Issue 245
Date: Tue, 11 Apr 2000 13:44:00 -0000
Message-id: <12574.955481811@upchuck>
References: <955147128.3461.ezmlm@sourceware.cygnus.com>
X-SW-Source: 2000-04/msg00223.html
Content-length: 898
In message <955147128.3461.ezmlm@sourceware.cygnus.com>you write:
> To: gdb-patches@sourceware.cygnus.com
> Subject: Fixes for AM33 sim
> From: Alexandre Oliva <aoliva@cygnus.com>
> Content-Type: multipart/mixed; boundary="=-=-="
> Date: 07 Apr 2000 16:10:50 -0300
> Message-ID: < orpus120cl.fsf@zecarneiro.lsd.ic.unicamp.br >
> MIME-Version: 1.0
>
> --=-=-=
>
> A few insns were not marked `*am33', and some SP-relative offsets were
> not unsigned as mandated by the specs. Ok to install?
>
>
> --=-=-=
> Content-Type: text/x-patch
> Content-Disposition: attachment; filename=am33-sim.patch
>
> Index: sim/mn10300/ChangeLog
> 2000-04-07 Alexandre Oliva <aoliva@cygnus.com>
>
> * am33.igen: Make SP-relative offsets unsigned. Add `*am33' for
> some instructions that were missing it.
This patch is fine. Please install it.
Thanks,
jeff
prev parent reply other threads:[~2000-04-11 4:37 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <200004102022.PAA26368@zwingli.cygnus.com>
2000-04-10 18:05 ` Andrew Cagney
[not found] ` <200004111134.HAA03852@indy.delorie.com>
2000-04-11 4:37 ` Dmitry Sivachenko [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200004111137.PAA90844@netserv1.chg.ru \
--to=dima@chg.ru \
--cc=eliz@is.elta.co.il \
--cc=gdb-patches@sourceware.cygnus.com \
--cc=jimb@zwingli.cygnus.com \
--cc=law@cygnus.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox