From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kevin Buettner To: GDB Discussion Subject: Re: free() vs xfree() vs FREEIF() vs ISO-C Date: Wed, 29 Nov 2000 20:15:00 -0000 Message-id: <1001130041446.ZM4806@ocotillo.lan> References: <3A25AEDA.5A57A0F2@cygnus.com> X-SW-Source: 2000-11/msg00280.html 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 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: X-SW-Source: 2000-11/msg00281.html Content-length: 1289 >>>>> "Quality" == Quality Quorum 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 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 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 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 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 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 To: "J.T. Conklin" Cc: gdb@sourceware.cygnus.com Subject: Re: telnet features to serial Date: Thu, 30 Nov 2000 14:56:00 -0000 Message-id: 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 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