From: Kevin Buettner <kevinb@cygnus.com>
To: GDB Discussion <gdb@sourceware.cygnus.com>
Subject: Re: free() vs xfree() vs FREEIF() vs ISO-C
Date: Wed, 29 Nov 2000 20:15:00 -0000 [thread overview]
Message-ID: <1001130041446.ZM4806@ocotillo.lan> (raw)
In-Reply-To: <ac131313@cygnus.com>
On Nov 30, 12:35pm, Andrew Cagney wrote:
> o Add/use xfree() which
> would guard against NULL.
[...]
> Does anyone have any thoughts? I tend towards the first one as that is
> fairly easy to implement. If adopted, I'd beg/borrow/con someone into
> converting all free() and free((PTR)) calls into xfree() :-)
I like this approach too.
I've eyeballed the diff output from the script below and it seems to
give pretty good results. I'll do a test build, and if all is well,
I'll post an rfc patch to gdb-patches. (Note that this patch doesn't
do any reindenting, but in the diffs I've looked at it, I don't see
a need for it in our present source tree.)
To run this script, just set your current directory to the gdb directory
and then do
subst-free-xfree .
(note the dot) or do
subst-free-xfree /path/to/gdb/sources
from anywhere.
--- subst-free-xfree ---
#!/usr/bin/perl -w
use File::Find;
use FileHandle;
use IPC::Open3;
use English;
my ($root) = @ARGV;
if (!defined($root)) {
die "Usage: $0 root\n";
}
@ARGV = ();
find(
sub {
if ($_ eq 'testsuite' || (-d && /-share$/)) {
$File::Find::prune = 1;
} elsif (-f && -T && /\.c$/ && $_ ne "gnu-regex.c") {
push @ARGV, $File::Find::name;
}
},
$root
);
$INPLACE_EDIT = '';
undef $/; # slurp entire files
while (<>) {
s/\bfree \(/xfree (/g;
s/\bmake_cleanup \(free,/make_cleanup (xfree,/g;
s/\bfree\)/xfree)/g;
print;
}
--- end subst-free-xfree ---
From jtc@redback.com Thu Nov 30 12:05:00 2000
From: jtc@redback.com (J.T. Conklin)
To: Quality Quorum <qqi@world.std.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: telnet features to serial
Date: Thu, 30 Nov 2000 12:05:00 -0000
Message-id: <5melztp6nl.fsf@jtc.redback.com>
References: <Pine.SGI.3.95.1001117205636.17522A-100000@world.std.com>
X-SW-Source: 2000-11/msg00281.html
Content-length: 1289
>>>>> "Quality" == Quality Quorum <qqi@world.std.com> writes:
Quality> I am wondering about following: does it seem reasonable to
Quality> add minimal telnet option negotiation to serial debugging
Quality> over tcp connection ?
Quality> Rationale: (1) this connection is usually going to terminal
Quality> server or telnet daemon (if monitor debugging is used), both
Quality> of them do expect telnet session, I suppose it may save on
Quality> terminal server configuration, (2) it will expand
Quality> possibilities, e.g. it will allow to send breaks over tcp,
Quality> (3) it is not a big deal to add it to the picture.
1) while a tcp connection may be to a port on a terminal server doing
telnet, it could also be set up to do a raw tcp stream. I'd think
there would have to be a way for the user to select between tcp and
telnet. I don't believe you can even assume that port 23 is telnet
and everything else is raw.
2) what backends could take advantage of a serial break? the remote
debug protocol usualy uses ^C instead of break (although I would
prefer a "stop" packet). What other telnet negotiated features
could we use?
3) Perhaps, but it seems more complicated than any benifits it might
offer.
--jtc
--
J.T. Conklin
RedBack Networks
From jtc@redback.com Thu Nov 30 12:09:00 2000
From: jtc@redback.com (J.T. Conklin)
To: Eli Zaretskii <eliz@is.elta.co.il>
Cc: gdb@sourceware.cygnus.com
Subject: Re: memory region documentation
Date: Thu, 30 Nov 2000 12:09:00 -0000
Message-id: <5maeahp6i2.fsf@jtc.redback.com>
References: <5mg0ku2r9l.fsf@jtc.redback.com> <200011151126.GAA03721@indy.delorie.com> <5mpujvhh52.fsf@jtc.redback.com> <200011162001.PAA04807@indy.delorie.com> <5mem04rf23.fsf@jtc.redback.com> <200011220835.DAA12092@indy.delorie.com>
X-SW-Source: 2000-11/msg00282.html
Content-length: 889
>>>>> "Eli" == Eli Zaretskii <eliz@delorie.com> writes:
Eli> For gdb.texinfo, it looks like it should be a section in the
Eli> "Examining Data" chapter (node name "Data"), either as a section
Eli> after "Memory", or as a subsection of "Memory". I'm puzzled why
Eli> did you think it didn't fit into the "Data" chapter.
Thanks. I've got it in a separate file now, I'll merge it into one of
those places.
The reason I didn't think it fit in the Data chapter was the not yet
implemented breakpoint attribute. GDB needs to insert breakpoints for
step, next, continue, etc.; but it can't do it if the memory region is
protected (ie, image is running out of ROM, FLASH, etc.). So there
needs to be a mechanism to tell GDB to use hardware breakpoints for
those internal breakpoints. This part of the feature isn't really
"data" related.
--jtc
--
J.T. Conklin
RedBack Networks
From jtc@redback.com Thu Nov 30 12:48:00 2000
From: jtc@redback.com (J.T. Conklin)
To: Andrew Cagney <ac131313@cygnus.com>
Cc: gdb@sources.redhat.com
Subject: Re: Spec; Was: tracepoints implementation: bug in byte code generating.
Date: Thu, 30 Nov 2000 12:48:00 -0000
Message-id: <5m66l5p4og.fsf@jtc.redback.com>
References: <00c801c02c9a$fe671c90$6c219fa8@lss.emc.com> <39D8D1CE.3059@redhat.com> <004e01c039d8$774c1d50$6c219fa8@lss.emc.com> <39EF3020.3F6A@redhat.com> <005b01c039f6$f46b1390$6c219fa8@lss.emc.com> <39EF381C.7EE6@redhat.com> <006101c039f9$df09df60$6c219fa8@lss.emc.com> <5mvguo5spm.fsf@jtc.redback.com> <008501c03aad$46c9d700$6c219fa8@lss.emc.com> <5m66mncnpc.fsf@jtc.redback.com> <3A1144CC.524A555@cygnus.com>
X-SW-Source: 2000-11/msg00283.html
Content-length: 2476
>>>>> "Andrew" == Andrew Cagney <ac131313@cygnus.com> writes:
>> 4.1 REGISTER FETCH
>>
>> input:
>> context_t id;
>> int offset; offset within register data
>> int length; length of transfer
>>
>> output:
>> int status;
>> char data[];
>>
>> This command may yeild unpredicable results if context <id> has not
>> been suspended.
>>
>> issues:
>> This assumes a single flat address space for all registers.
>> It might be convienent to have separate (but potentially
>> overlapping) register files for integer registers, floating
>> point registers, system registers, miscellaneous registers,
>> etc.
>>
>> For example, one register file could contain the PC, FP, SP,
>> and whatever other registers are needed on a particular
>> architecture for GDB after a signal/exception/breakpoint
>> event. This would solve the problem of what to return in
>> those events.
Andrew> One problem with this on targets that like to switch their
Andrew> byte order (yes not very many :-). The register data is, by
Andrew> definition, target byte order dependant. Consequently, when
Andrew> GDB connects to the target it needs to know that targets byte
Andrew> order for it to correctly interpret register values.
I mentioned in the introduction that I hadn't settled on how any field
should be encoded.
At this point, I have been thinking of the low levels being binary, so
that virtual I/O, etc. is relatively efficent. This essentially pre-
cludes being able to understand what's going on by looking at the raw
packets (which has been mentioned in the past as being one of the
assets of the current remote debug protocol). I think some code that
can be bound into GDB and the debug agent that would produce annotated
output for each packet (sort of like tcpdump) might accomplish the same
thing.
If the low layers end up like this, (IMO) there is little to gained by
having the debug protocol ASCII based. So the byte order issue is not
only relevant for register and memory data, but also for simple things
like addresses, breakpoint ids, etc.
Wind River's WDB is based on Sun XDR/RPC. XDR could be used to
provide a host- and target-independent representation for the fields
in each command and response. Since rpcgen can generate the code to
encode and decode the structures, It's proabably what I'll be using
for a proof of concept implementation.
--jtc
--
J.T. Conklin
RedBack Networks
From qqi@world.std.com Thu Nov 30 14:56:00 2000
From: Quality Quorum <qqi@world.std.com>
To: "J.T. Conklin" <jtc@redback.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: telnet features to serial
Date: Thu, 30 Nov 2000 14:56:00 -0000
Message-id: <Pine.SGI.4.21.0011301748510.26114-100000@world.std.com>
References: <5melztp6nl.fsf@jtc.redback.com>
X-SW-Source: 2000-11/msg00284.html
Content-length: 1641
On 30 Nov 2000, J.T. Conklin wrote:
> >>>>> "Quality" == Quality Quorum <qqi@world.std.com> writes:
> Quality> I am wondering about following: does it seem reasonable to
> Quality> add minimal telnet option negotiation to serial debugging
> Quality> over tcp connection ?
>
> Quality> Rationale: (1) this connection is usually going to terminal
> Quality> server or telnet daemon (if monitor debugging is used), both
> Quality> of them do expect telnet session, I suppose it may save on
> Quality> terminal server configuration, (2) it will expand
> Quality> possibilities, e.g. it will allow to send breaks over tcp,
> Quality> (3) it is not a big deal to add it to the picture.
>
> 1) while a tcp connection may be to a port on a terminal server doing
> telnet, it could also be set up to do a raw tcp stream. I'd think
> there would have to be a way for the user to select between tcp and
> telnet. I don't believe you can even assume that port 23 is telnet
> and everything else is raw.
????? Most terminal servers do run telnet ????
>
> 2) what backends could take advantage of a serial break? the remote
> debug protocol usualy uses ^C instead of break (although I would
> prefer a "stop" packet). What other telnet negotiated features
> could we use?
1. We can proper escape IACs and use X packets on connections going
through terminal servers.
2. We can tell terminal server that we do not want line mode
spare on terminal server configuration,
>
> 3) Perhaps, but it seems more complicated than any benifits it might
> offer.
I am not sure myself.
> --jtc
Thanks,
Aleksey
next parent reply other threads:[~2000-11-29 20:15 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <3A25AEDA.5A57A0F2@cygnus.com>
[not found] ` <ac131313@cygnus.com>
2000-11-29 20:15 ` Kevin Buettner [this message]
2001-02-16 11:59 ` abort() to internal_error() Kevin Buettner
2001-02-16 7:09 Andrew Cagney
2001-02-16 12:08 ` J.T. Conklin
2001-02-16 12:16 ` Andrew Cagney
2001-02-16 12:39 ` Kevin Buettner
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=1001130041446.ZM4806@ocotillo.lan \
--to=kevinb@cygnus.com \
--cc=gdb@sourceware.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