Re: free() vs xfree() vs FREEIF() vs ISO-C

Re: free() vs xfree() vs FREEIF() vs ISO-C

[Kevin Buettner]

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

abort() to internal_error()

[Andrew Cagney]

Hello,

KevinB's kindly cooked up a script that will replace all instances of:

	abort ();

with

	internal_error (__FILE__, __LINE__, "function calls abort ()");

Applying and committing this script will signify the end of a very long
campain I've been waging with GDB - to significantly reduce the
likelhood that GDB dumps core.

From memory, this has been discussed several times before (and is listed
in the TODO file).  The only problem I can think of is the message. 
However, if you think about it:

	(gdb) pwd
	internal_error: /a/b/c/d/foo.c:47: function calls abort ()
	....

is still infinatly better than something like

	(gdb) pwd
	Program received SIGXYZZY, core dumped
	$

so I think is good enough,

comments?

	Andrew

Re: abort() to internal_error()

[Kevin Buettner]

On Feb 16, 10:04am, Andrew Cagney wrote:

> KevinB's kindly cooked up a script that will replace all instances of:
> 
> 	abort ();
> 
> with
> 
> 	internal_error (__FILE__, __LINE__, "function calls abort ()");
> 
> Applying and committing this script will signify the end of a very long
> campain I've been waging with GDB - to significantly reduce the
> likelhood that GDB dumps core.
> 
> >From memory, this has been discussed several times before (and is listed
> in the TODO file).  The only problem I can think of is the message. 
> However, if you think about it:
> 
> 	(gdb) pwd
> 	internal_error: /a/b/c/d/foo.c:47: function calls abort ()
> 	....
> 
> is still infinatly better than something like
> 
> 	(gdb) pwd
> 	Program received SIGXYZZY, core dumped
> 	$
> 
> so I think is good enough,
> 
> comments?

It should be noted that if the "function calls abort ()" message is
unpalatable for some reason (e.g, lack of specificity), these can be
replaced with something more suitable over time.  In each case, the
choice of a more suitable message will likely depend upon the context,
so I think that Andrew's suggestion is a reasonable first step.  It is
certainly better than what we have now...

Kevin

Re: abort() to internal_error()

[J.T. Conklin]

>>>>> "Andrew" == Andrew Cagney <ac131313@cygnus.com> writes:
Andrew> KevinB's kindly cooked up a script that will replace all instances of:
Andrew>
Andrew> 	abort ();
Andrew>
Andrew> with
Andrew>
Andrew> 	internal_error (__FILE__, __LINE__, "function calls abort ()");
Andrew>
Andrew> Applying and committing this script will signify the end of a very long
Andrew> campain I've been waging with GDB - to significantly reduce the
Andrew> likelhood that GDB dumps core.

This is good enough to go in as is, but I wonder if there is any way
can improve the message.  IMO "function calls abort ()" is wrong, or
at best misleading, since the function no longer calls abort().
Perhaps "failed internal consistancy check" is generic enough without
mentioning abort()?

Of course, these can, and I suspect will be changed to be specific to
the error condition in the fullness of time.

        --jtc

-- 
J.T. Conklin
RedBack Networks

Re: abort() to internal_error()

[Andrew Cagney]

"J.T. Conklin" wrote:

> This is good enough to go in as is, but I wonder if there is any way
> can improve the message.  IMO "function calls abort ()" is wrong, or
> at best misleading, since the function no longer calls abort().
> Perhaps "failed internal consistancy check" is generic enough without
> mentioning abort()?

Thankyou!  I couldn't think of anything sensible.

	Andrew

PS: Must not suggest ``Houston, we have a problem''....

Re: abort() to internal_error()

[Kevin Buettner]

On Feb 16,  3:11pm, Andrew Cagney wrote:

> > This is good enough to go in as is, but I wonder if there is any way
> > can improve the message.  IMO "function calls abort ()" is wrong, or
> > at best misleading, since the function no longer calls abort().
> > Perhaps "failed internal consistancy check" is generic enough without
> > mentioning abort()?
> 
> Thankyou!  I couldn't think of anything sensible.

I've adjusted my script to use "failed internal consistency check"
instead.  (I'll post a patch after the discussion dies down...)

Kevin

Re: abort() to internal_error()

[Andrew Cagney]

Michael Elizabeth Chastain wrote:
> 
> > (gdb) pwd
> > internal_error: /a/b/c/d/foo.c:47: function calls abort ()
> > ....
> 
> Fine with me.

Just FYI.  The principal was debated and agreed to months (years?) ago.
The only remaining issue (and so minor to really not be anything at all)
is the message.  Even there I don't expect people to disagree -
internal_error() regardless of the message, is infinatly better than
calling abort().

For the curious, the exact message is:

/home/scratch/GDB/src/gdb/maint.c:118: gdb-internal-error: function
calls abort ()

as in:

(gdb) maint internal-error 
/home/scratch/GDB/src/gdb/maint.c:118: gdb-internal-error: internal
maintenance
An internal GDB error was detected.  This may make further
debugging unreliable.  Continue this debugging session? (y or n) y

Create a core file containing the current state of GDB? (y or n) n
(gdb) 

	enjoy,
		Andrew

Re: abort() to internal_error()

[Michael Elizabeth Chastain]

> (gdb) pwd
> internal_error: /a/b/c/d/foo.c:47: function calls abort ()
> ....

Fine with me.

If this happens on my workstation, I don't care whether I get
internal_error or a core dump or whatever, I'm going to start debugging
gdb either way.

If this happens on a user's desktop, I prefer the "internal_error"
form, because I'll get "/a/b/c/d/foo.c:47" in the bug report.
I imagine the user either won't care, or will prefer internal_error.

I have a side comment: I've gotten two gdb core dumps in the past month.
Both of them are cycles in the type tree which lead to recursive
death in "maint print symbols".  (One was gdb/15, fixed, and the other
is in gdb/7, not analyzed yet).  So you are still going to get core
dumps even after this change.

But that is a separate issue.

Michael