* Re: Proposal: convert function definitions to prototyped form [not found] <1000602075018.ZM29997@ocotillo.lan> @ 2000-06-02 5:26 ` Mark Kettenis [not found] ` <1000602151553.ZM30578@ocotillo.lan> [not found] ` <3937816C.E66B9AE0@cygnus.com> 2000-06-12 18:10 ` Andrew Cagney 2 siblings, 1 reply; 5+ messages in thread From: Mark Kettenis @ 2000-06-02 5:26 UTC (permalink / raw) To: kevinb; +Cc: gdb Date: Fri, 2 Jun 2000 00:50:19 -0700 From: Kevin Buettner <kevinb@cygnus.com> Comma separated list with differing number of stars on the parameter names (sparc-tdep.c): static branch_type -isbranch (instruction, addr, target) - long instruction; - CORE_ADDR addr, *target; +isbranch (long instruction, CORE_ADDR addr, CORE_ADDR * target) { I guess you should tweak it some more such that it outputs CORE_ADDR *target instead of CORE_ADDR * target (note the spurious space between * and target). Mark From kevinb@cygnus.com Fri Jun 02 08:16:00 2000 From: Kevin Buettner <kevinb@cygnus.com> To: Mark Kettenis <kettenis@wins.uva.nl> Cc: gdb@sourceware.cygnus.com Subject: Re: Proposal: convert function definitions to prototyped form Date: Fri, 02 Jun 2000 08:16:00 -0000 Message-id: <1000602151553.ZM30578@ocotillo.lan> References: <1000602075018.ZM29997@ocotillo.lan> <200006021226.e52CQ2I01239@delius.kettenis.local> <kettenis@wins.uva.nl> X-SW-Source: 2000-06/msg00016.html Content-length: 997 On Jun 2, 2:26pm, Mark Kettenis wrote: > Date: Fri, 2 Jun 2000 00:50:19 -0700 > From: Kevin Buettner <kevinb@cygnus.com> > > Comma separated list with differing number of stars on the parameter > names (sparc-tdep.c): > > static branch_type > -isbranch (instruction, addr, target) > - long instruction; > - CORE_ADDR addr, *target; > +isbranch (long instruction, CORE_ADDR addr, CORE_ADDR * target) > { > > I guess you should tweak it some more such that it outputs > > CORE_ADDR *target > > instead of > > CORE_ADDR * target > > (note the spurious space between * and target). I noticed that. The space was put there by ``indent''. I would very much like to get rid of that space and it would be easy to make the perl script postprocess the ``indent'' output. But in doing so, we (obviously) generate different output than that of ``indent''. I suppose the other solution is to fix indent. :-) FYI, I'm using GNU indent 2.2.5. Kevin From taylor@cygnus.com Fri Jun 02 08:40:00 2000 From: David Taylor <taylor@cygnus.com> To: Kevin Buettner <kevinb@cygnus.com> Cc: gdb@sourceware.cygnus.com Subject: Re: Proposal: convert function definitions to prototyped form Date: Fri, 02 Jun 2000 08:40:00 -0000 Message-id: <200006021539.LAA25912@texas.cygnus.com> X-SW-Source: 2000-06/msg00017.html Content-length: 4312 Date: Fri, 2 Jun 2000 00:50:19 -0700 From: Kevin Buettner <kevinb@cygnus.com> [...] 2) ``protoize'' fails to convert functions disabled by ifdefs for the given platform. OTOH, on some other platform(s), these functions might not be disabled and would be converted. E.g, in breakpoint.c, on my GNU/Linux/x86 machine, protoize failed to convert create_longjmp_breakpoint() which is protected by an "#ifdef GET_LONGJMP_TARGET". With any solution, either you're going to have to check the results or you're going to have to hand convert some of the stuff. It's a tradeoff. From what you say below, your script also requires some later hand conversions. Does your script produce substantially less that needs to be hand converted? 3) ``protoize'' screws up on PTR types. E.g, in breakpoint.c, it converted static int cover_target_enable_exception_callback (arg) PTR arg; to static int cover_target_enable_exception_callback (__builtin_va_list arg) I consider this to be a more serious problem than the other complaints you have. 4) ``protoize'' does not reformat long argument lists. The lists end up entirely contained on one line. So... adopt the same solution for it that you chose to adopt for your script -- run indent on the output! For more information on protoize, see the "Running protoize" page: http://gcc.gnu.org/onlinedocs/gcc_2.html#SEC48 and the "Caveats of using protoize" page: http://gcc.gnu.org/onlinedocs/gcc_7.html#SEC135 I've used protoize before with good results. It was a fairly substantial project, though not as big as gdb. Two of my goals in creating the scripts for the PARAMS purging activities was that the scripts should be 1) easy to invoke and 2) require no hand editing of the output when done. I.e, you shouldn't have to edit any of the files that these scripts touch in order to fix I trust that "3)" is: "be conservative; not convert something if it can't be sure of getting it right". I'd much rather hand convert more of the code than have it make a subtle but incorrect change. errors so that you can build again. OTOH, the script may leave certain portions of the file alone that could possibly have be converted had the script been a little smarter. The things that the script fails to convert *will* have to be fixed later on (in order to complete the cleanup activity), either by another script, or by hand. For the PARAMS purging activity, I have spent a fair amount of time examining the diffs to make sure that this is indeed the case. (And I intend to do the same for the activity in this proposal.) Good. The reason that it is so important to avoid any hand edits is that we want people who have local repositories or checked out source trees to be able to run these conversion scripts against them so that merges will be less painful. (Even easy.) Agreed. With that said, keeping in mind the problems I noted above, I conclude that ``protoize'' is not the appropriate tool for us to use to convert function definitions in the gdb sources to their prototyped form. I only consider 3) -- screwing up on PTR types -- to be serious; the others seem minor enough. [...] Finally, I should note that I've done a test build on GNU/Linux/x86 and had no build problems, nor did I see any regressions when I ran the testsuite. The fix-decls script is below. I'd be interested in finding out if anyone else has a favorite script for doing this sort of thing. Other comments welcome too. I'd be tempted to do a build before running your script; stash away the object files; run the script; do another build; compare the object files... I consider the lack of (prototyped) function declarations to be more serious "problem" than the use of old style function definitions in old code. I'd like to see: . declarations near the top of every file (i.e., before the first function definition) for every static function in the file. . a declaration in an included header file for every non static function definition and for every non static function used. . changes to the default configuration to "encourage" developers to include the above declarations. From davea@quasar.engr.sgi.com Fri Jun 02 09:17:00 2000 From: davea@quasar.engr.sgi.com (David B Anderson) To: gdb@sourceware.cygnus.com Subject: Re: does GDB support IRIX 64 bit executables? Date: Fri, 02 Jun 2000 09:17:00 -0000 Message-id: <200006021622.JAA05620@quasar.engr.sgi.com> X-SW-Source: 2000-06/msg00018.html Content-length: 952 On: irix 64 bit pointer apps and dwarf2 and gdb robert somerville <somervil@cadvision.com> writes: >i got this patch from : > Benjamin Gamsa <ben@eecg.toronto.edu> The patch makes no distinction between address-size and offset-size in the dwarf2, but that is an essential distinction, I think. I think the patch as written will break alpha-64-bit-pointers-using-dwarf2 in dwarf2read.c That is, it will break any non-sgi target with 64bit pointers and dwarf2, as *only* SGI extended offsets/lengths in dwarf2 to 64bits for 64bit pointer apps. And the patch makes no provision for the coming dwarf2 revision with its compatible allowance of 32-bit-offset and 64-bit-offset dwarf2 in a single object file. I believe this is very easily dealt with. I hope to get to this to suggest a revised patch soon, but of course, promises are worthless :-) Regards, David B. Anderson davea@sgi.com danderson@acm.org http://reality.sgi.com/davea/ From Will_Lentz@Trimble.COM Fri Jun 02 10:34:00 2000 From: Will Lentz <Will_Lentz@Trimble.COM> To: Peter Reilley <micrio@mv.com>, gdb@sourceware.cygnus.com Subject: RE: Questions on GDB Date: Fri, 02 Jun 2000 10:34:00 -0000 Message-id: <8B0BE50D6F9AD01185A300A0C92BF455088393EE@US01XCH01.Trimble.COM> X-SW-Source: 2000-06/msg00019.html Content-length: 1327 Hi Pete, For a remote PPC target (through rproxy), I use: file xyz.elf target remote ip.addr:port load run It's really cool that you ported the Macraigor DLL to Linux! I think more people would use the Wiggler if your port was made available :-). Will > -----Original Message----- > From: Peter Reilley [ mailto:micrio@mv.com ] > Sent: Thursday, June 01, 2000 2:24 PM > To: gdb@sourceware.cygnus.com > Subject: Questions on GDB > > > I have a few questions on the operation of GDB with the Wiggler > and a PowerPC target. > > I have ported the Macraigor DLL from MS Windows to Linux and > am attempting to get GDB working. I can read and write registers > and memory in the PPC target. I have a small test program that > I compiled with GCC configured as a cross compiler for the PPC. > I can use the "load" command and have the binary load properly > in the target memory. I can use the "symbol-file" command to > load the symbols. The "file" command will load the binary but > it seems to have a base address in the host and not the target. > The "run" and "step" commands do not seem to work. > > Anyway, what are the commands that you used to load and execute > a binary in a target under Windows. The documentation that I found > on the internet is conflicting. > > Thanks, > Pete. > > > > > From jtc@redback.com Fri Jun 02 10:44:00 2000 From: jtc@redback.com (J.T. Conklin) To: Kevin Buettner <kevinb@cygnus.com> Cc: Mark Kettenis <kettenis@wins.uva.nl>, gdb@sourceware.cygnus.com Subject: Re: Proposal: convert function definitions to prototyped form Date: Fri, 02 Jun 2000 10:44:00 -0000 Message-id: <5mya4om115.fsf@jtc.redback.com> References: <1000602075018.ZM29997@ocotillo.lan> <200006021226.e52CQ2I01239@delius.kettenis.local> <1000602151553.ZM30578@ocotillo.lan> X-SW-Source: 2000-06/msg00020.html Content-length: 799 >>>>> "Kevin" == Kevin Buettner <kevinb@cygnus.com> writes: Kevin> I noticed that. The space was put there by ``indent''. I Kevin> would very much like to get rid of that space and it would be Kevin> easy to make the perl script postprocess the ``indent'' output. Kevin> But in doing so, we (obviously) generate different output than Kevin> that of ``indent''. Kevin> Kevin> I suppose the other solution is to fix indent. :-) You can tell indent about all the types defined by typedef with -T option, and then it won't add the extra space. It shouldn't be too difficult to identify all the types. It might be useful for us to maintain an indent.pro file that has these definitions so that additional runs of indent don't add back the space. --jtc -- J.T. Conklin RedBack Networks From kevinb@cygnus.com Fri Jun 02 12:10:00 2000 From: Kevin Buettner <kevinb@cygnus.com> To: David Taylor <taylor@cygnus.com> Cc: gdb@sourceware.cygnus.com Subject: Re: Proposal: convert function definitions to prototyped form Date: Fri, 02 Jun 2000 12:10:00 -0000 Message-id: <1000602191042.ZM30936@ocotillo.lan> References: <200006021539.LAA25912@texas.cygnus.com> <taylor@cygnus.com> X-SW-Source: 2000-06/msg00021.html Content-length: 7094 On Jun 2, 11:39am, David Taylor wrote: > With any solution, either you're going to have to check the results or > you're going to have to hand convert some of the stuff. It's a > tradeoff. From what you say below, your script also requires some > later hand conversions. Yes. But, it's conservative in that it won't break your builds. (Or at least that's the intent.) > Does your script produce substantially less that needs to be hand > converted? I only ran protoize on breakpoint.c to see what the problems were. This was the file that required the most conversion, however, so hopefully it's a good representative sample. For this file, protoize converted 126 function declarations and fix-decls converted 138. In addition, not counting reformatting, the protoized version of breakpoint.c would require 5 hand edits in order to fix problems introduced in the conversion. The fix-decls version requires 0 hand edits. After conversion, the protoized version of breakpoint.c still had 15 functions which would need to be converted by hand (or some other tool) whereas the fix-decls version had only 3. Here's a table to summarizing the above: breakpoint.c conversion | protoize | fix-decls | ----------------------------------------------+----------+-----------+ Functions converted | 126 | 138 | ----------------------------------------------+----------+-----------+ Hand edits needed afterwards to fix problems | | | in the conversion process | 5 | 0 | ----------------------------------------------+----------+-----------+ Functions remaining to be converted | 15 | 3 | ----------------------------------------------+----------+-----------+ Total number of hand edits required | 20 | 3 | ----------------------------------------------+----------+-----------+ Recall that over all of the gdb sources, fix-decls converted slightly over 5200 declarations. I believe that there are only around 140 left to consider. This is somewhat higher than I would like and I may be able to reduce it somewhat by making the script a little bit smarter. But I also want to be certain that no errors are introduced in the process. I should note that there are many settings where protoize is a completely acceptable (and probably better) tool. With gdb, however, we have a lot of developers scattered across the globe who need to be able to deterministically apply the same transformations to their sources in order to make merges and checkins easier. With protoize, I think it's going be be difficult to guarantee determinism since the results will vary depending upon which platform you use to do the transformation. > 3) ``protoize'' screws up on PTR types. E.g, in breakpoint.c, it > converted > > static int > cover_target_enable_exception_callback (arg) > PTR arg; > > to > > static int > cover_target_enable_exception_callback (__builtin_va_list arg) > > I consider this to be a more serious problem than the other complaints > you have. I think the setup issue is important too. (I don't know if it's more serious though.) As I mentioned in my first point (which is no longer quoted), you have to do a configure in the source directory above gdb in order to to properly run protoize or else it complains that it can't find certain header files. Also, you need to make sure that the bfd header files are generated before you start. None of these problems are insurmountable, but to do things safely with protoize, and in order to avoid polluting your sources with files that belong in a build tree, it would be necessary for a script using protoize to make a complete copy of the source tree somewhere else in order to do the work. > 4) ``protoize'' does not reformat long argument lists. The lists > end up entirely contained on one line. > > So... adopt the same solution for it that you chose to adopt for your > script -- run indent on the output! Granted. A suitably imaginative script could identify just the lines that protoize touched and reformat those. I don't think we want to run indent on entire files however, at least not for this activity. > For more information on protoize, see the "Running protoize" page: > > http://gcc.gnu.org/onlinedocs/gcc_2.html#SEC48 > > and the "Caveats of using protoize" page: > > http://gcc.gnu.org/onlinedocs/gcc_7.html#SEC135 > > I've used protoize before with good results. It was a fairly > substantial project, though not as big as gdb. Okay. Out of curiousity, did the project in question have a large number of active developers? (This doesn't necessarily matter, but I think it's probably easier to manage this kind of thing when only a handful of developers are affected.) > Two of my goals in creating the scripts for the PARAMS purging > activities was that the scripts should be 1) easy to invoke and 2) > require no hand editing of the output when done. I.e, you shouldn't > have to edit any of the files that these scripts touch in order to fix > > I trust that "3)" is: > > "be conservative; not convert something if it can't be sure > of getting it right". You're right. I should have mentioned this. > I'd much rather hand convert more of the code than have it make a > subtle but incorrect change. I agree completely. [...] > Finally, I should note that I've done a test build on GNU/Linux/x86 > and had no build problems, nor did I see any regressions when I ran > the testsuite. > > The fix-decls script is below. I'd be interested in finding out if > anyone else has a favorite script for doing this sort of thing. Other > comments welcome too. > > I'd be tempted to do a build before running your script; stash away the > object files; run the script; do another build; compare the object > files... Good idea. I'll have to see what gcc does to compare object files. (I don't think a simple cmp works for ELF files.) > I consider the lack of (prototyped) function declarations to be more > serious "problem" than the use of old style function definitions in > old code. I'd like to see: > > . declarations near the top of every file (i.e., before the first > function definition) for every static function in the file. > > . a declaration in an included header file for every non static > function definition and for every non static function used. > > . changes to the default configuration to "encourage" developers to > include the above declarations. I don't disagree, but I think that adding prototypes for everything should be a separate activity. The question is whether it should occur before the activity covered by my proposal. And if it should occur before, once again, we'll need to find a way to help automate the process because if we attempt to do it incrementally by hand over a period of time, it is likely that it'll never get done. Kevin From taylor@cygnus.com Fri Jun 02 13:11:00 2000 From: David Taylor <taylor@cygnus.com> To: Kevin Buettner <kevinb@cygnus.com> Cc: gdb@sourceware.cygnus.com Subject: Re: Proposal: convert function definitions to prototyped form Date: Fri, 02 Jun 2000 13:11:00 -0000 Message-id: <200006022010.QAA25997@texas.cygnus.com> X-SW-Source: 2000-06/msg00022.html Content-length: 4318 Date: Fri, 2 Jun 2000 12:10:42 -0700 From: Kevin Buettner <kevinb@cygnus.com> On Jun 2, 11:39am, David Taylor wrote: > 3) ``protoize'' screws up on PTR types. E.g, in breakpoint.c, it > converted > > static int > cover_target_enable_exception_callback (arg) > PTR arg; > > to > > static int > cover_target_enable_exception_callback (__builtin_va_list arg) > > I consider this to be a more serious problem than the other complaints > you have. I think the setup issue is important too. (I don't know if it's more serious though.) As I mentioned in my first point (which is no longer quoted), you have to do a configure in the source directory above gdb Sorry, I didn't consider it relevant to what I was replying to. in order to to properly run protoize or else it complains that it can't find certain header files. Also, you need to make sure that the bfd header files are generated before you start. None of these problems are insurmountable, but to do things safely with protoize, and in order to avoid polluting your sources with files that belong in a build tree, it would be necessary for a script using protoize to make a complete copy of the source tree somewhere else in order to do the work. I don't consider the setup issue to be a big issue. It requires some time, but it doesn't require much human time. Configure in the source tree, then build. Setup done. During the commit phase, you don't commit anything that is new -- you only commit files that existed prior to doing the configure. No separate tree needed. > 4) ``protoize'' does not reformat long argument lists. The lists > end up entirely contained on one line. > > So... adopt the same solution for it that you chose to adopt for your > script -- run indent on the output! Granted. A suitably imaginative script could identify just the lines that protoize touched and reformat those. I don't think we want to run indent on entire files however, at least not for this activity. Since Stan previously ran indent on all of the files, re-running it *should* produce no change for stuff that hasn't changed. Should produce no change. I'm not saying it won't. If it changes its own output when presented with it as input, I would consider that a bug. > I've used protoize before with good results. It was a fairly > substantial project, though not as big as gdb. Okay. Out of curiousity, did the project in question have a large number of active developers? (This doesn't necessarily matter, but I think it's probably easier to manage this kind of thing when only a handful of developers are affected.) It was at a former company. There were a small number of active developers all within the company. The total project was around 200-250K lines of code. There was a great deal less use of #if within the sources than there is in GDB... [...] I don't disagree, but I think that adding prototypes for everything should be a separate activity. The question is whether it should occur before the activity covered by my proposal. And if it should occur before, once again, we'll need to find a way to help automate the process because if we attempt to do it incrementally by hand over a period of time, it is likely that it'll never get done. I agree that it should be a separate activity. I think that your script is a good thing. And due to the amount of hand editing that appears to be necessary with protoize vs the amount that appears to be necessary with your script, I think we should use your script. Ultimately, though, since you're doing the work, you get to select the tool. So long as it is fairly reliable and reasonably quick (quick in terms of *your time*, not in terms of *elapsed time*), it doesn't ultimately matter to me what tool you use. (Which is not to say that I am not interested in knowing what tool you use -- I am interested.) Like I said, I think your script is a good thing. And I look forward to you using it to protoize the bulk of the GDB sources. Kevin David From kettenis@wins.uva.nl Fri Jun 02 13:58:00 2000 From: Mark Kettenis <kettenis@wins.uva.nl> To: gdb@sourceware.cygnus.com Subject: handling unexpected debugging unformation Date: Fri, 02 Jun 2000 13:58:00 -0000 Message-id: <200006022058.e52KwS213519@delius.kettenis.local> X-SW-Source: 2000-06/msg00023.html Content-length: 1842 Struggling with the misconfigured GCC 2.95.2 used by FreeBSD/Alpha as its system compiler revealed some weaknesses in GDB with respect to unexpected debugging information. Some extra stabs present in the stabs-in-ecoff .mdebug section of an Alpha ELF executable caused GDB to crash. The problematic stabs in question are: * N_BINCL stabs: These cause add_new_header_files to be called, but since init_header_files() hasn't been called for stabs-in-ecoff, GDB tries to dereference a null pointer. There are several possible solutions, and I'll need some help choosing between them :-). Hence a few questions: - Should N_BINCL stabs be supported in stabs-in-ecoff? - Is it acceptable to export free_header_files() and init_header_files() from dbxread.c? - Shouldn't mdebugread.c:elfmdebug_build_psymtabs() call stabsread_new_init() and buildsym_new_init()? - What about mdebug_build_psymtabs()? * An extra blank N_SO stab (emitted by GCC for normal stabs-in-ELF): mdebugread.c:psymtab_to_symtab_1() iterates over all stabs symbols, calling dbxread.c:process_one_symbol() for them. If process_one_symbol() sees an N_SO stab it will call end_symtab() if we've seen an N_SO before, and then calls start_symtab() if the N_SO stab isn't blank. After the iteration psymtab_to_symtab_1() also calls end_symtab() and uses its return value. The problem is that the blank N_SO stab already finishes creating the symbol table. The end_symtab() in psymtab_to_symtab_1() tries to do that again, freeing already freed memory blocks, which again crashed GDB. (The extra blank N_SO stab in normal ELF objects seems never to be passed to process_one_symbal()). Is there a way we can make this a bit more robust? Would setting subfiles to NULL in buildsymtab.c:end_symtab() be sufficient? Mark ^ permalink raw reply [flat|nested] 5+ messages in thread
[parent not found: <1000602151553.ZM30578@ocotillo.lan>]
[parent not found: <5mya4om115.fsf@jtc.redback.com>]
[parent not found: <3938F700.509FD4AA@cygnus.com>]
* Re: Proposal: convert function definitions to prototyped form [not found] ` <3938F700.509FD4AA@cygnus.com> @ 2000-06-05 11:05 ` J.T. Conklin 0 siblings, 0 replies; 5+ messages in thread From: J.T. Conklin @ 2000-06-05 11:05 UTC (permalink / raw) To: Andrew Cagney; +Cc: Kevin Buettner, Mark Kettenis, gdb >>>>> "Andrew" == Andrew Cagney <ac131313@cygnus.com> writes: Andrew> Given that people are currently editing headers to remove Andrew> spaces by hand this sounds like a good idea. One thing, how Andrew> does one pass ``indent.pro'' rather than have it pick up Andrew> ``.indent.pro''? I suspect it can be maintained largely by Andrew> hand (please not another perl script to maintain it - we can't Andrew> make perl a requirement on developers :-) For what we want to do, indent needs an option to disable processing the .indent.pro files located in the current or home directories, and another to process an arbitrary file. I examined the latest revision of the indent sources, 2.2.5, and I can not find an option to process a file containing options. It appears that indent is being actively maintained. Perhaps someone with a bit of time on their hands can work with the indent maintainer to get such an option in a future revesion. --jtc -- J.T. Conklin RedBack Networks From kettenis@wins.uva.nl Mon Jun 05 11:54:00 2000 From: Mark Kettenis <kettenis@wins.uva.nl> To: ac131313@cygnus.com Cc: gdb@sourceware.cygnus.com, shebs@apple.com, fnasser@cygnus.com Subject: Re: 5.0 post mortem Date: Mon, 05 Jun 2000 11:54:00 -0000 Message-id: <200006051853.e55IriS09643@delius.kettenis.local> References: <393B16D9.E217DAA1@cygnus.com> X-SW-Source: 2000-06/msg00043.html Content-length: 548 Date: Mon, 05 Jun 2000 12:56:25 +1000 From: Andrew Cagney <ac131313@cygnus.com> Well before a 5.0.1 or 5.1 release is started its probably worth having a bit of a post-mortem (where the vultures can pick over the bones of what happened :-) Here are my random thoughts: [snip] o we need more tests Here's a test for the x86 SIGALRM problem that's still listed in the TODO file to remind us of adding it. Looks like it's falling through the cracks: http://sourceware.cygnus.com/ml/gdb-patches/2000-05/msg00309.html Mark From dan@cgsoftware.com Mon Jun 05 13:51:00 2000 From: Daniel Berlin <dan@cgsoftware.com> To: gdb-patches@sourcware.cygnus.com Cc: gdb@sourceware.cygnus.com Subject: [FYI]: Incoming C++ changes Date: Mon, 05 Jun 2000 13:51:00 -0000 Message-id: <Pine.LNX.4.10.10006051338440.29861-100000@propylaea.anduin.com> X-SW-Source: 2000-06/msg00044.html Content-length: 1002 I made quite a bunch of C++ improvements over the weekend (i was gone until 3pm today), i'll be committing in a moment. In no particular order: 1. Symbol table performance is vastly improved. No longer do we need to force a linear search for C++, ever. This required simply changing STREQ(SYMBOL_NAME,name)) to SYMBOL_MATCHES_NAME. Once that was done, the issues that required doing the linear search in the first place no longer occurred. This change causes no regressions. 2. Template handling improvements. Should be as good as it is on HP now. Required removing some code in the expression parser that was dupicating, but doing less, than something that could already do it. 3. Test suite improvements: Tests we previously skipped on g++, we now don't skip, and pass (particularly, template tests). I also added a namespace test from the gdb.hp dir. This requirred changing a few tests to accept valid output. This actually exposes what appears to be a bug in demangling when you use stabs. ^ permalink raw reply [flat|nested] 5+ messages in thread
[parent not found: <3937816C.E66B9AE0@cygnus.com>]
* Re: Proposal: convert function definitions to prototyped form [not found] ` <3937816C.E66B9AE0@cygnus.com> @ 2000-06-03 0:13 ` Kevin Buettner 0 siblings, 0 replies; 5+ messages in thread From: Kevin Buettner @ 2000-06-03 0:13 UTC (permalink / raw) To: Andrew Cagney; +Cc: gdb On Jun 2, 7:42pm, Andrew Cagney wrote: > The only concern I have is, given the slightly more complex nature of > the script (compared to PARAMS) there is a possibility that the > conversion re-orders or re-types the argument list. With that in mind, > should a pre-cursor to this be to least have prototypes for all > (global?) functions (-Wmissing-prototypes?) or only do the conversion > when there is a prototype visible? I've given this matter a lot of thought. I agree that it would be desirable to have prototypes for all functions. Unfortunately, while it is easy to generate prototypes, it's not so easy to know where to stick them. Also, even if we had prototypes in place, there's no guarantee that we'd catch the errors after a few builds because I think there's some code in gdb (though I don't know how much) that never gets built! (Due to ifdefs and near obsolete ports.) What we really need is a method for vetting all of the changes immediately after running the script. I.e, we need to make sure that the conversion does no reordering or retyping of any argument list. Also, we need to make sure that the rewritten function declaration is syntactically correct. While examining the diffs (made with the -u switch) an idea occurred to me. Consider the following example: diff -ur ../../orig/gdb-sourceware/wrapper.c ./wrapper.c --- ../../orig/gdb-sourceware/wrapper.c Sat May 27 17:10:27 2000 +++ ./wrapper.c Thu Jun 1 23:33:16 2000 @@ -57,11 +57,8 @@ static int wrap_parse_and_eval_type (char *); int -gdb_parse_exp_1 (stringptr, block, comma, expression) - char **stringptr; - struct block *block; - int comma; - struct expression **expression; +gdb_parse_exp_1 (char **stringptr, struct block *block, int comma, + struct expression **expression) { struct gdb_wrapper_arguments args; args.args[0].pointer = stringptr; In the above diff, the lines prepended with `-' represent the original K&R definition. And the lines prepended with `+' represent the transformed code. Moreover, the diff is extremely regular in this respect. So... If you take the lines which begin with `+', prepend the type on the line before the `-' lines and tack a semicolon onto the end, you end up with a prototype declaration. And, if you take the lines beginning with `-', again tack the type onto the front and put a function body underneath it, you have a K&R style (traditional) function definition. Now if you put these into a file with the prototype first and the K&R definition later on, you can run "gcc -Wall" on it to see if any warnings are produced. Obviously, if we get warnings, we need to look closer to see if something went wrong with the fix-decls conversion. Of course, there are other details to consider, like making sure that all of the types, structs, unions, and enums are declared. Also, in a source tree as big as gdb, we'll likely wind up with a number of functions with the same name, so some method of disambiguating these will be necessary. And then of course, there's the matter of no declared return type and other oddments. I've written a script called ``check-decls'' which performs these transformations on the diff output. When I run it on the above diff, it produces the following output (indented by four spaces by me for readability) struct block { int f0; }; struct expression { int f1; }; #define INLINE #define private #define CONST const #define NORETURN void init___ (void *); int gdb_parse_exp_1 (char **stringptr, struct block *block, int comma, struct expression **expression); int gdb_parse_exp_1 (stringptr, block, comma, expression) char **stringptr; struct block *block; int comma; struct expression **expression; { int ret; init___ (&ret); return ret; } void use___ (void) { } The use___ () function isn't interesting in this example, but it would be if there had been a static declaration. Here's what happens when I run it on *all* of the diffs: ocotillo:ptests$ ./check-decls <declsdiff >prog.c ocotillo:ptests$ wc prog.c 50235 112228 960827 prog.c ocotillo:ptests$ gcc -c -Wall prog.c prog.c: In function `exit': prog.c:39303: warning: function declared `noreturn' has a `return' statement prog.c: At top level: prog.c:45903: parse error before `arg_type' prog.c: In function `value_primitive_field': prog.c:45907: declaration for parameter `arg_type' but no such parameter prog.c:45906: declaration for parameter `fieldno' but no such parameter prog.c:45905: declaration for parameter `offset' but no such parameter prog.c:45904: declaration for parameter `arg1' but no such parameter prog.c:45908: argument `arg_type' doesn't match prototype prog.c:5886: prototype declaration prog.c:45908: argument `arg1' doesn't match prototype prog.c:5886: prototype declaration The `exit' warning is due to the fact that there's a declaration and definition of exit() from standalone.c. It is of no concern. The error following this warning looks more serious. Here's the declaration and the definition of the function involved: value_ptr value_primitive_field (register value_ptr arg1, int offset, register int fieldno, register struct type *arg_type); value_ptr value_primitive_field (arg1, offset, fieldno, arg_type) register value_ptr arg1; int offset; register int fieldno; register struct type *arg_type; { value_ptr ret; init___ (&ret); return ret; } I looked at this for a long, long time and didn't see anything wrong. Finally, I realized that arg_type was a type from a different file. (Which is one of the problems with throwing everything into one big pot.) Anyway, here's the type that the script declared: typedef struct t44 { int f44; } arg_type; And here's the (transformed) definition which caused it to be defined: bool_t xdr_arg_type(xdrs, objp) XDR *xdrs; arg_type *objp; { bool_t ret; init___ (&ret); return ret; } So it turns out that it's nothing to worry about. And that's it. There are no other warnings or errors. Which means that the transformation was successful and didn't mess up any of the parameter types. The check-decls script is below. One might argue that it is about as complex as the fix-decls script. This is true, but the code which actually extracts the `-' and `+' lines is fairly simple. Also, after being extracted, there are no transformations made to these lines aside from appending ___<num> to the function name if the script detects that the function name has already been seen. Most importantly, the parameter lists are not rewritten in any way. Most of the complexity is in the analysis and generation of the type, struct, enum, and union declarations. But uniqueness of these is easy to verify. Plus, if something is screwed up, the compiler complains. --- check-decls --- #!/usr/bin/perl -w # Feed this script a unidiff after running fix-decls and it generates # (on stdout) a program which may be used to test the validity of the # conversion. Just run the result through gcc -Wall and if it # generates any warnings, there's a problem... undef $/; # slurp mode my $diff = <>; # read entire diff in $diff; my $decls = ''; my $defns = ''; my %userstructs = (); my %userenums = (); my %usertypes = (); my %funcnames = (); my $funcname_gensym = 0; # for names that clash my @needuse; while ($diff =~ / ( ^ # beginning of line [^\n]+ # everything til the end of line ) \n # newline ( (?: ^ # beginning of line - # minus sign (?: \n # either just a newline | # -- or -- [^-\n] # any character but minus and newline [^\n]* # the rest of the line \n # including the newline ) )+ # one or more of the above ) ( (?: ^ # beginning of line \+ # plus sign [^+] # any character but plus [^\n]* # the rest of the line \n # including the newline )+ # one or more of the above ) /mgx) { my ($rettype, $traddecl, $isodecl) = ($1, $2, $3); # Remove leading diff character from the lines extracted foreach ($rettype, $traddecl, $isodecl) { s/^.//mg; } # Find type names in parameter list my $parmdecls = $traddecl; $parmdecls =~ s/^\w+\s*\([^)]*\)//; foreach my $parm (split /\s*;\s*/, $parmdecls) { $parm =~ s/\s*\**\w+(,|$).*$//; analyze_type($parm); } # Resolve collisions between function name (either due to statics # or due to the names being in different branches of an ifdef) my ($funcname) = $traddecl =~ /^(\w+)/; if (defined $funcnames{$funcname}) { foreach ($traddecl, $isodecl) { s/\b$funcname\b/${funcname}___$funcname_gensym/; } $funcname .= "___$funcname_gensym"; $funcname_gensym++; } $funcnames{$funcname} = $funcname; # Nuke comments in the return type $rettype =~ s#/\*.*?\*/##g; # Nuke partial comment in return type $rettype =~ s#^.*?\*/##; # Eliminate ``CALLBACK'' from return type $rettype =~ s/\bCALLBACK\b//; # Eliminate ``extern'' from return type $rettype =~ s/\bextern\b//; # Eliminate leading and trailing spaces from return type $rettype =~ s/^\s*//; $rettype =~ s/\s*$//; if (($rettype =~ /^#/) || ($rettype eq '')) { # preprocessor line or empty string $rettype = 'int'; } elsif ($rettype eq "static") { $rettype = 'static int'; } elsif ($rettype eq "private") { $rettype = 'static int'; } else { analyze_type($rettype); } $isodecl =~ s/\n\Z/;\n/; $decls .= "$rettype $isodecl"; if ($rettype =~ /\bvoid$/) { $defns .= "$rettype\n$traddecl\{\n}\n\n"; } else { $defns .= "$rettype\n$traddecl\{\n $rettype ret;\n" . " init___ (&ret);\n return ret;\n}\n\n"; } if ($rettype =~/\bstatic\b/) { push @needuse, $funcname; } } my $typeidx = 0; foreach $key (sort keys %usertypes) { print "typedef struct t$typeidx { int f$typeidx; } $key;\n"; $typeidx++; } foreach $key (sort keys %userstructs) { print "$key { int f$typeidx; };\n"; $typeidx++; } foreach $key (sort keys %userenums) { print "$key { e$typeidx };\n"; $typeidx++; } print "#define INLINE\n"; print "#define private\n"; print "#define CONST const\n"; print "#define NORETURN\n"; print "void init___ (void *);\n"; print $decls; print "\n"; print $defns; print "void\nuse___ (void)\n{\n"; foreach (@needuse) { print " init___ ($_);\n"; } print "}\n"; sub analyze_type { my ($parm) = @_; $parm =~ s/\s*\**\s*$//; my $type; if ($parm =~ /\b(struct|union)\b/) { $parm =~ s/\A.*\b(struct|union)\b/$1/s; $parm =~ s/\s*\**\s*\Z//s; $userstructs{$parm} = $parm; } elsif ($parm =~ /\b(enum)\b/) { $parm =~ s/\A.*\b(enum)\b/$1/s; $parm =~ s/\s*\**\s*\Z//s; $userenums{$parm} = $parm; } elsif ((($type) = $parm =~ /(\w+)$/) && ($type !~ /^(int|char|long|short|unsigned|double |register|void|const|static)$/x)) { $usertypes{$type} = $type; } } --- end check-decls --- From kevinb@cygnus.com Sat Jun 03 00:21:00 2000 From: Kevin Buettner <kevinb@cygnus.com> To: Andrew Cagney <ac131313@cygnus.com> Cc: gdb@sourceware.cygnus.com Subject: Re: Proposal: convert function definitions to prototyped form Date: Sat, 03 Jun 2000 00:21:00 -0000 Message-id: <1000603072049.ZM32430@ocotillo.lan> References: <1000602075018.ZM29997@ocotillo.lan> <3937816C.E66B9AE0@cygnus.com> <ac131313@cygnus.com> X-SW-Source: 2000-06/msg00029.html Content-length: 198 On Jun 2, 7:42pm, Andrew Cagney wrote: > PS: You may want to add gdb/*-share to the list of directories to avoid. I can certainly do this, but I'd like to know why they shouldn't be converted... From eliz@delorie.com Sat Jun 03 03:58:00 2000 From: Eli Zaretskii <eliz@delorie.com> To: kevinb@cygnus.com Cc: taylor@cygnus.com, gdb@sourceware.cygnus.com Subject: Re: Proposal: convert function definitions to prototyped form Date: Sat, 03 Jun 2000 03:58:00 -0000 Message-id: <200006031058.GAA12885@indy.delorie.com> References: <200006021539.LAA25912@texas.cygnus.com> <1000602191042.ZM30936@ocotillo.lan> X-SW-Source: 2000-06/msg00030.html Content-length: 2307 > Date: Fri, 2 Jun 2000 12:10:42 -0700 > From: Kevin Buettner <kevinb@cygnus.com> > > > I've used protoize before with good results. It was a fairly > > substantial project, though not as big as gdb. > > Okay. Out of curiousity, did the project in question have a large > number of active developers? I think the real problem is not the number of developers, but the number of different configurations, and also different data types and functions concealed behind macros. `protoize' needs everything to be explicit, so it is not easy to run it on multi-platform project that uses macros to hide system dependencies (since you want the same macros back in the reformatted sources). This is a disadvantage of `protoize'. Its significant advantage is that its output is *always* correct, because it takes the info ``from the horse's mouth'': the compiler itself. In contrast, a script is simply a text-processing tool: it really doesn't understand the semantics of the source. In fact, it doesn't really understand the syntax very well. So with a script, we will always need a verification tool that can be trusted to find any potential bugs introduced by reformatting. > > I'd be tempted to do a build before running your script; stash away the > > object files; run the script; do another build; compare the object > > files... > > Good idea. I'll have to see what gcc does to compare object files. > (I don't think a simple cmp works for ELF files.) Comparing object files generally doesn't work. COFF (at least the variety used by DJGPP) is another case: if I compile the same source twice in a row, I get different object files (IIRC, the time stamp is recorded inside). One method I can suggest is to compile the source without optimizations, then run "objdump --disassemble" and compare the output of `objdump' for the two source files (original and reformatted). (I suggest to disable optimizations because it's possible that ANSI source allows the compiler to produce more optimal code that the K&R source.) Note that, since you need to compile the source to make sure reformatting didn't screw up anything, you essentially get the same problems you had with `protoize', albeit through the back door: you need to build for all supported configurations to make sure nothing's broken. From ac131313@cygnus.com Sat Jun 03 04:48:00 2000 From: Andrew Cagney <ac131313@cygnus.com> To: Kevin Buettner <kevinb@cygnus.com> Cc: gdb@sourceware.cygnus.com Subject: Re: Proposal: convert function definitions to prototyped form Date: Sat, 03 Jun 2000 04:48:00 -0000 Message-id: <3938F055.42A9FEA3@cygnus.com> References: <1000602075018.ZM29997@ocotillo.lan> X-SW-Source: 2000-06/msg00031.html Content-length: 747 Kevin Buettner wrote: > > As many of you know, I'm in the midst of purging the use of ``PARAMS'' > in prototyped function declarations from the gdb sources. After this > activity is concluded, I'd like to begin converting function > definitions whose parameters are declared using the traditional C > style to the ISO C prototyped form. I.e, I'd like to convert > functions of the form Something to consider with the timing. There are Pascal, ObjectiveC.* and random other Apple files pending. It might be good to wait until the buil of the work is in the repository so that we reduce the number of contributors / maintainers that get hit for six by this one :-) Unlike params, this one will really hurt people with private diffs. Andrew From ac131313@cygnus.com Sat Jun 03 04:52:00 2000 From: Andrew Cagney <ac131313@cygnus.com> To: Kevin Buettner <kevinb@cygnus.com> Cc: gdb@sourceware.cygnus.com Subject: Re: Proposal: convert function definitions to prototyped form Date: Sat, 03 Jun 2000 04:52:00 -0000 Message-id: <3938F161.943C45F2@cygnus.com> References: <1000602075018.ZM29997@ocotillo.lan> <3937816C.E66B9AE0@cygnus.com> <1000603072049.ZM32430@ocotillo.lan> X-SW-Source: 2000-06/msg00032.html Content-length: 511 Kevin Buettner wrote: > > On Jun 2, 7:42pm, Andrew Cagney wrote: > > > PS: You may want to add gdb/*-share to the list of directories to avoid. > > I can certainly do this, but I'd like to know why they shouldn't be > converted... Some of the *-share files are based on code from third parties. We should probably try to avoid munging that code - it will make it harder for us merge back patches. rdi-share comes to mind. As you note, the TUI which will be cleaned up, can be handed separatly. Andrew From ac131313@cygnus.com Sat Jun 03 05:17:00 2000 From: Andrew Cagney <ac131313@cygnus.com> To: jtc@redback.com Cc: Kevin Buettner <kevinb@cygnus.com>, Mark Kettenis <kettenis@wins.uva.nl>, gdb@sourceware.cygnus.com Subject: Re: Proposal: convert function definitions to prototyped form Date: Sat, 03 Jun 2000 05:17:00 -0000 Message-id: <3938F700.509FD4AA@cygnus.com> References: <1000602075018.ZM29997@ocotillo.lan> <200006021226.e52CQ2I01239@delius.kettenis.local> <1000602151553.ZM30578@ocotillo.lan> <5mya4om115.fsf@jtc.redback.com> X-SW-Source: 2000-06/msg00033.html Content-length: 1164 "J.T. Conklin" wrote: > > >>>>> "Kevin" == Kevin Buettner <kevinb@cygnus.com> writes: > Kevin> I noticed that. The space was put there by ``indent''. I > Kevin> would very much like to get rid of that space and it would be > Kevin> easy to make the perl script postprocess the ``indent'' output. > Kevin> But in doing so, we (obviously) generate different output than > Kevin> that of ``indent''. > Kevin> > Kevin> I suppose the other solution is to fix indent. :-) > > You can tell indent about all the types defined by typedef with -T > option, and then it won't add the extra space. It shouldn't be too > difficult to identify all the types. > > It might be useful for us to maintain an indent.pro file that has > these definitions so that additional runs of indent don't add back > the space. Given that people are currently editing headers to remove spaces by hand this sounds like a good idea. One thing, how does one pass ``indent.pro'' rather than have it pick up ``.indent.pro''? I suspect it can be maintained largely by hand (please not another perl script to maintain it - we can't make perl a requirement on developers :-) enjoy, Andrew From kevinb@cygnus.com Sat Jun 03 10:50:00 2000 From: Kevin Buettner <kevinb@cygnus.com> To: Eli Zaretskii <eliz@is.elta.co.il> Cc: gdb@sourceware.cygnus.com Subject: Re: Proposal: convert function definitions to prototyped form Date: Sat, 03 Jun 2000 10:50:00 -0000 Message-id: <1000603175039.ZM738@ocotillo.lan> References: <200006021539.LAA25912@texas.cygnus.com> <1000602191042.ZM30936@ocotillo.lan> <200006031058.GAA12885@indy.delorie.com> <eliz@delorie.com> X-SW-Source: 2000-06/msg00034.html Content-length: 1970 On Jun 3, 6:58am, Eli Zaretskii wrote: > So with a script, we will always need a verification tool that can be > trusted to find any potential bugs introduced by reformatting. Right. That's why I wrote check-decls (see http://sourceware.cygnus.com/ml/gdb/2000-06/msg00028.html ) which takes the result of comparing (via diff -u) the original sources with the protoized sources and produces a C source file in which the portions from the protoized sources are used to construct prototypes and the portions from the original sources are used to construct (potentially?) corresponding function definitions. We can then invoke the C compiler (gcc -c -Wall) on the result and see what kinds of warnings and errors are produced. E.g, in an earlier (than the one I posted) version of fix-decls, I hadn't yet handled comma separated parameter lists and so the following: foo (a, b, c) int a; char *b, *c; was getting transformed into foo (int a, int b, char *b, *c) This type of mistake would've been quickly caught by check-decls + gcc. (As it was, I caught it myself because I was looking for it.) Also, since my fix-decls script merely looks for patterns which appear to be function definitions, it was finding if (overload_debug) { in find_overload_match() in valops.c and turning this into if (int overload_debug) { (Note that the ``if'' is at the beginning of the line in this function.) I found this one when I did a test build, but check-decls + the C compiler would have caught this one too. (fix-decls was quickly changed so that it no longer gets tripped up by this code.) Also, note that check-decls would've caught this mistake even if the the construct in question had appeared in some #if 0'd code whereas doing a build wouldn't have. I think it could still happen that something might slip by that won't work in the real code, but now that I've written check-decls, I think it is much, much less likely. Kevin From eliz@delorie.com Sat Jun 03 11:37:00 2000 From: Eli Zaretskii <eliz@delorie.com> To: kevinb@cygnus.com Cc: gdb@sourceware.cygnus.com Subject: Re: Proposal: convert function definitions to prototyped form Date: Sat, 03 Jun 2000 11:37:00 -0000 Message-id: <200006031837.OAA13278@indy.delorie.com> References: <200006021539.LAA25912@texas.cygnus.com> <1000602191042.ZM30936@ocotillo.lan> <200006031058.GAA12885@indy.delorie.com> <1000603175039.ZM738@ocotillo.lan> X-SW-Source: 2000-06/msg00035.html Content-length: 870 > Date: Sat, 3 Jun 2000 10:50:39 -0700 > From: Kevin Buettner <kevinb@cygnus.com> > > That's why I wrote check-decls (see > http://sourceware.cygnus.com/ml/gdb/2000-06/msg00028.html > ) which takes the result of comparing (via diff -u) the original > sources with the protoized sources and produces a C source file in > which the portions from the protoized sources are used to construct > prototypes and the portions from the original sources are used to > construct (potentially?) corresponding function definitions. We can > then invoke the C compiler (gcc -c -Wall) on the result and see what > kinds of warnings and errors are produced. I saw that script, but I don't like the idea to depend on a human to judge what GCC warnings are okay to ignore and what aren't. I'd prefer an automated tool that would give a definite yes/no answer, if that's possible. From pavenis@latnet.lv Sat Jun 03 11:47:00 2000 From: Andris Pavenis <pavenis@latnet.lv> To: gdb@sourceware.cygnus.com Cc: linux-kernel@vger.rutgers.edu Subject: Problems with GDB-5.0 and recent Linux kernels (2.4.0-test1-ac[47]) Date: Sat, 03 Jun 2000 11:47:00 -0000 Message-id: <00060320465900.00261@hal> X-SW-Source: 2000-06/msg00036.html Content-length: 2559 Have somebody tried GDB commands 'info float' and 'info reg' on a system running latest ac kernels. I'm getting coredump from gdb-5.0 on these commands. 2.4.0-test1 - seems that all works, no such problem 2.4.0-test1-ac4 and 2.4.0-test1-ac7 - gdb coredumps on these commands It seems to be some stack corruption. Andris hal:/usr/src/build/gdb$ gdb gdb GNU gdb 5.0 Copyright 2000 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-slackware-linux"... Setting up the environment for debugging gdb. Breakpoint 1 at 0x80bf9cd: file ../../gdb-5.0/gdb/utils.c, line 723. Breakpoint 2 at 0x80bd3af: file ../../gdb-5.0/gdb/top.c, line 2953. Breakpoint 3 at 0x80a0563: file ../../gdb-5.0/gdb/i386-linux-nat.c, line 522. (top-gdb) r Starting program: /usr/src/build/gdb/gdb GNU gdb 5.0 Copyright 2000 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i586-pc-linux-gnu". Setting up the environment for debugging gdb. .gdbinit:5: Error in sourced command file: No symbol table is loaded. Use the "file" command. (gdb) file test1 Reading symbols from test1...done. (gdb) tb main Breakpoint 1 at 0x80485d6: file test1.c, line 10. (gdb) r Starting program: /usr/src/build/gdb/test1 main () at test1.c:10 10 rc = system ("ls -l"); (gdb) info float Breakpoint 3, fetch_fpregs (tid=319) at ../../gdb-5.0/gdb/i386-linux-nat.c:522 522 if (ret < 0) (top-gdb) n 528 supply_fpregset (&fpregs); (top-gdb) n 529 } (top-gdb) fetch_inferior_registers (regno=Cannot access memory at address 0xffff0008 ) at ../../gdb-5.0/gdb/i386-linux-nat.c:824 824 dummy_sse_values (); (top-gdb) 825 return; (top-gdb) 830 } (top-gdb) Program received signal SIGSEGV, Segmentation fault. 0x80a06c9 in fetch_inferior_registers (regno=Cannot access memory at address 0xffff0008 ) at ../../gdb-5.0/gdb/i386-linux-nat.c:830 830 } ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Proposal: convert function definitions to prototyped form [not found] <1000602075018.ZM29997@ocotillo.lan> 2000-06-02 5:26 ` Proposal: convert function definitions to prototyped form Mark Kettenis [not found] ` <3937816C.E66B9AE0@cygnus.com> @ 2000-06-12 18:10 ` Andrew Cagney 2000-06-12 19:48 ` Kevin Buettner 2 siblings, 1 reply; 5+ messages in thread From: Andrew Cagney @ 2000-06-12 18:10 UTC (permalink / raw) To: Kevin Buettner; +Cc: gdb Kevin Buettner wrote: > > As many of you know, I'm in the midst of purging the use of ``PARAMS'' > in prototyped function declarations from the gdb sources. After this > activity is concluded, I'd like to begin converting function > definitions whose parameters are declared using the traditional C > style to the ISO C prototyped form. I.e, I'd like to convert > functions of the form Kevin, Would a fair summary of this be that you've encountered the following road blocks: o indent.pro So that indent gives better results o a drain of some of the backlog of patches (pascal I believe is now going in). Apple and HP? No one has objected to the principal (well not on gdb-patches :-) and the tool would be based on perl rather than the the gcc thing. Once those blockages are cleared, it can be scheduled and can go through? Andrew From shebs@apple.com Mon Jun 12 18:15:00 2000 From: Stan Shebs <shebs@apple.com> To: Daniel Berlin <dan@cgsoftware.com> Cc: Andrew Cagney <ac131313@cygnus.com>, Eric Bachalo <ebachalo@redhat.com>, gdb@sourceware.cygnus.com Subject: Re: Proposal: convert function definitions to prototyped form Date: Mon, 12 Jun 2000 18:15:00 -0000 Message-id: <39458A9E.239C8A81@apple.com> References: <Pine.LNX.4.10.10006121802590.29924-100000@propylaea.anduin.com> X-SW-Source: 2000-06/msg00103.html Content-length: 374 Daniel Berlin wrote: > > Funny you guys bring up the number of types in GDB. > According to the debug info, there are >82,000. > How exactly are we counting them, again? Since GDB sources are around 400K lines or so, it's highly unlikely that there is a type definition for every five lines in the C sources. You're seeing duplicates in the debug info, presumably. Stan From dan@cgsoftware.com Mon Jun 12 18:23:00 2000 From: Daniel Berlin <dan@cgsoftware.com> To: Stan Shebs <shebs@apple.com> Cc: Andrew Cagney <ac131313@cygnus.com>, Eric Bachalo <ebachalo@redhat.com>, gdb@sourceware.cygnus.com Subject: Re: Proposal: convert function definitions to prototyped form Date: Mon, 12 Jun 2000 18:23:00 -0000 Message-id: <Pine.LNX.4.10.10006121815430.29924-100000@propylaea.anduin.com> References: <39458A9E.239C8A81@apple.com> X-SW-Source: 2000-06/msg00104.html Content-length: 643 Before my patches to eliminate duplicate dwarf2 info, it said there were 120k. So something isn't adding up here. I find it hard to believe we duplicate that much info. It's pretty much absurd. --Dan On Mon, 12 Jun 2000, Stan Shebs wrote: > Daniel Berlin wrote: > > > > Funny you guys bring up the number of types in GDB. > > According to the debug info, there are >82,000. > > How exactly are we counting them, again? > > Since GDB sources are around 400K lines or so, it's highly unlikely > that there is a type definition for every five lines in the > C sources. You're seeing duplicates in the debug info, presumably. > > Stan > ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Proposal: convert function definitions to prototyped form 2000-06-12 18:10 ` Andrew Cagney @ 2000-06-12 19:48 ` Kevin Buettner 0 siblings, 0 replies; 5+ messages in thread From: Kevin Buettner @ 2000-06-12 19:48 UTC (permalink / raw) To: Andrew Cagney; +Cc: gdb On Jun 13, 11:09am, Andrew Cagney wrote: > Kevin Buettner wrote: > > > > As many of you know, I'm in the midst of purging the use of ``PARAMS'' > > in prototyped function declarations from the gdb sources. After this > > activity is concluded, I'd like to begin converting function > > definitions whose parameters are declared using the traditional C > > style to the ISO C prototyped form. I.e, I'd like to convert > > functions of the form > > Kevin, > > Would a fair summary of this be that you've encountered the following > road blocks: > > o indent.pro > > So that indent gives better results I don't think this is a serious road block. While it would be nice to be able to specify an indent.pro file (e.g., "indent --options-file gdbtypes.pro"), it's not absolutely necessary for the task at hand. As I noted in my reply to Eric, I already know the complete list of types which indent has to know about in order to complete the protoization task. It is easy to put this list in the script which does the conversion. I.e, @typelist = qw(ADDR32 B_TYPE ... value_ptr xdrproc_t); $indentoptions = '-T ' . join(' -T ', @typelist); > o a drain of some of the backlog of > patches (pascal I believe is now > going in). > > Apple and HP? I think the patch backlog is the real road block. However, even for this road block, the only reason for delaying the protoization activity is to make it easier on the people doing the patch integration. Perhaps setting a date for the protoization activity would help motivate the patch integrators to clear some of the backlog? > No one has objected to the principal (well not on gdb-patches :-) and > the tool would be based on perl rather than the the gcc thing. > > Once those blockages are cleared, it can be scheduled and can go > through? I still have a little over a week to go on the PARAMS elimination activity, so any time after then is good for me. How does midnight GMT of Sunday July 9 sound? That's about four weeks away. Is that enough time for the patch integrators to clear the patch backlog? From eliz@delorie.com Tue Jun 13 03:34:00 2000 From: Eli Zaretskii <eliz@delorie.com> To: ebachalo@redhat.com Cc: jtc@redback.com, kevinb@cygnus.com, kettenis@wins.uva.nl, gdb@sourceware.cygnus.com Subject: Re: Proposal: convert function definitions to prototyped form Date: Tue, 13 Jun 2000 03:34:00 -0000 Message-id: <200006131034.GAA25579@indy.delorie.com> References: <1000602075018.ZM29997@ocotillo.lan> <200006021226.e52CQ2I01239@delius.kettenis.local> <1000602151553.ZM30578@ocotillo.lan> <5mya4om115.fsf@jtc.redback.com> <394572A4.EF8646F2@redhat.com> X-SW-Source: 2000-06/msg00117.html Content-length: 209 > Date: Mon, 12 Jun 2000 16:30:44 -0700 > From: Eric Bachalo <ebachalo@redhat.com> > > Not sure how ported etags and python are for all the hosts that > compile GDB though. What platforms cause your concern? From dcroyle@telerama.com Tue Jun 13 09:06:00 2000 From: David J Croyle <dcroyle@telerama.com> To: gdb@sourceware.cygnus.com Subject: Using GDB with standalone assembly code questions Date: Tue, 13 Jun 2000 09:06:00 -0000 Message-id: <39466A96.E7B022BD@telerama.com> X-SW-Source: 2000-06/msg00118.html Content-length: 3164 Hello all! We are trying to debug/verify a very simple ARM assembly language program and we hoped to use the gdb ARM simulator w/ddd as the frontend though we have encountered a few issues. Our goal is to single step through the code and watch the registers change (and perhaps observe memory locations/memory mapped registers) but gdb seems some what intent on not simulating our code. We use the following sequence to "get gdb going": (Load an ARM executable into gdb via DDD Open Program under File): (gdb) file testarmasm.exec warning: arm architecture file may be incompatible with armv4 target. Reading symbols from testarmasm.exec (no debugging symbols found)...done. We then issued these commands to gdb by hand: (gdb) target sim Connected to the simulator. (gdb) set language asm (gdb) load Loading section .text, size 0x124 vma 0x0 Start address 0x0 Transfer rate: 2336 bits in <1 sec. However when we issue the step command the response is: (gdb) step Single stepping until exit from function _start, which has no line number information. The program is not being run Our registers don't change and neither does the program counter. When we issue "run" gdb seems to get stuck in a never ending loop (the registers which we have told ddd to display do not change) and the green light just keeps blinking. If we interrupt gdb and start the whole process over (reload the executable, issue target sim, etc.) and use the "go" command and specify a label from our code such as ledon23(a valid label) our response is: (gdb) go ledon23 Breakpoint 1 at 0xa8 Continuing at 0xa8. The program is not being run. (gdb) We then see the program counter pointing to 0xa8 but issuing "run" either locks gdb or if we stop the run almost imediatly with control-c, we can see that a few registers changed though the run/interruption cannot be done with any hopes of reliability. It is interesting to note that while gdb mentions it did not find any debug symbols, it does know of the labels we used in our ASM program meaning it has read that information successfully from our executable. In addition to the run/control-c, we can issue a "b <label>" and gdb will set the breakpoint at the correct label (the address was verified by looking out our .lst file). However we still do not have the ability to single step/step into the next instruction. An "info watchpoints" shows all our breakpoints with the correct labels. Are there any suggestions on how we can single step through our code or execute our "pure ASM" program and observe registers and such? We've built gdb for target=strongarm-elf on a i686-pc-linux-gnu host. We've told ddd to use our strongarm built gdb by using the --debugger switch on ddd start-up. Our ARM executable was built on this same machine, cross-compiled by using a cross toolchain we built to produce standalone ARM executables (we used newlib headers instead of glibc but since this is "pure ASM" program that should not matter). Thanks in advance, Dave & Vasant. David J. Croyle EE / Software Developer Foerster Instruments, Inc. Windows e-mail: dcroyle@foerstergroup.com Linux e-mail: dcroyle@telerama.com From fnasser@cygnus.com Tue Jun 13 10:02:00 2000 From: Fernando Nasser <fnasser@cygnus.com> To: David J Croyle <dcroyle@telerama.com> Cc: gdb@sourceware.cygnus.com Subject: Re: Using GDB with standalone assembly code questions Date: Tue, 13 Jun 2000 10:02:00 -0000 Message-id: <394668A0.7C8B3DA2@cygnus.com> References: <39466A96.E7B022BD@telerama.com> X-SW-Source: 2000-06/msg00119.html Content-length: 3829 David, First of all, which compiler and which version of it have you used? The exact compile line, with all switches is also necessary. Then you should tell us which gdb (version, where did you get it etc.) you are using. Fernando David J Croyle wrote: > > Hello all! > > We are trying to debug/verify a very simple ARM assembly language > program > and we hoped to use the gdb ARM simulator w/ddd as the frontend though > we > have encountered a few issues. > > Our goal is to single step through the code and watch the registers > change > (and perhaps observe memory locations/memory mapped registers) but gdb > seems some what intent on not simulating our code. > > We use the following sequence to "get gdb going": > > (Load an ARM executable into gdb via DDD Open Program under File): > > (gdb) file testarmasm.exec > warning: arm architecture file may be incompatible with armv4 target. > Reading symbols from > testarmasm.exec > (no debugging symbols found)...done. > > We then issued these commands to gdb by hand: > > (gdb) target sim > Connected to the simulator. > (gdb) set language asm > (gdb) load > Loading section .text, size 0x124 vma 0x0 > Start address 0x0 > Transfer rate: 2336 bits in <1 sec. > > However when we issue the step command the response is: > > (gdb) step > Single stepping until exit from function _start, > which has no line number information. > The program is not being run > > Our registers don't change and neither does the program counter. > > When we issue "run" gdb seems to get stuck in a never ending loop (the > registers which we have told ddd to display do not change) and the green > light just keeps blinking. > > If we interrupt gdb and start the whole process over (reload the > executable, issue target sim, etc.) and use the "go" command and specify > a > label from our code such as ledon23(a valid label) our response is: > > (gdb) go ledon23 > Breakpoint 1 at 0xa8 > Continuing at 0xa8. > The program is not being run. > (gdb) > > We then see the program counter pointing to 0xa8 but issuing "run" > either > locks gdb or if we stop the run almost imediatly with control-c, we can > see that a few registers changed though the run/interruption cannot be > done with any hopes of reliability. > > It is interesting to note that while gdb mentions it did not find any > debug symbols, it does know of the labels we used in our ASM program > meaning it has read that information successfully from our executable. > > In addition to the run/control-c, we can issue a "b <label>" and gdb > will > set the breakpoint at the correct label (the address was verified by > looking out our .lst file). However we still do not have the ability to > single step/step into the next instruction. > > An "info watchpoints" shows all our breakpoints with the correct labels. > > Are there any suggestions on how we can single step through our code or > execute our "pure ASM" program and observe registers and such? > > We've built gdb for target=strongarm-elf on a i686-pc-linux-gnu host. > We've told ddd to use our strongarm built gdb by using the --debugger > switch on ddd start-up. > > Our ARM executable was built on this same machine, cross-compiled by > using > a cross toolchain we built to produce standalone ARM executables (we > used > newlib headers instead of glibc but since this is "pure ASM" program > that > should not matter). > > Thanks in advance, > Dave & Vasant. > > David J. Croyle > EE / Software Developer > Foerster Instruments, Inc. > Windows e-mail: dcroyle@foerstergroup.com > Linux e-mail: dcroyle@telerama.com -- Fernando Nasser Red Hat Canada Ltd. E-Mail: fnasser@cygnus.com 2323 Yonge Street, Suite #300 Tel: 416-482-2661 ext. 311 Toronto, Ontario M4P 2C9 Fax: 416-482-6299 From jtc@redback.com Tue Jun 13 15:19:00 2000 From: jtc@redback.com (J.T. Conklin) To: gdb@sourceware.cygnus.com Subject: nindy protocol Date: Tue, 13 Jun 2000 15:19:00 -0000 Message-id: <5mbt155ino.fsf@jtc.redback.com> X-SW-Source: 2000-06/msg00120.html Content-length: 1697 Does anyone have a copy of the Nindy protocol specification or an old Intel gnu960 (aka CTOOLS) distribution that contains Nindy source? I checked developer.intel.com, but the CTOOLS distributions currently available all have mon960 instead of Nindy. The reason I ask is because I'd like to get rid of the dcache_fetch() and dcache_poke() functions which are only used by remote-nindy.c and remote-bug.c. Unlike most remote targets, the nindy_xfer_inferior_memory() function breaks the transfer into multiple word-aligned word-sized transfers. These word-sized transfers are performed through dcache_fetch() and dcache_poke(). The header comment for nindy_xfer_inferior_memory() states: "This is stolen almost directly from infptrace.c's child_xfer_memory, which also deals with a word-oriented memory interface. Sometime, FIXME, rewrite this to not use the word-oriented routines." I'm not sure whether this means that nindy protocol supports non-word- aligned, non-word-sized transfers, and the code just needs to be fixed to use them, or if something more substantial must be done. I checked the code in nindy-share/nindy.c, which seems to indicate that the protocol supports arbitrary sized/aligned transfers, but it's not explicitly stated. I'd like to confirm this before submitting a patch. In case anyones wondering, the primary reason I'd like to get rid of these functions is that otherwise I'd have to adapt them to take a mem_attrib parameter. They also seem to be poorly specified. They read and write a host word, when I'd think they would be defined in terms of the target's word size. --jtc -- J.T. Conklin RedBack Networks From shebs@apple.com Tue Jun 13 16:25:00 2000 From: Stan Shebs <shebs@apple.com> To: jtc@redback.com Cc: gdb@sourceware.cygnus.com Subject: Re: nindy protocol Date: Tue, 13 Jun 2000 16:25:00 -0000 Message-id: <3946C259.3F4C058A@apple.com> References: <5mbt155ino.fsf@jtc.redback.com> X-SW-Source: 2000-06/msg00121.html Content-length: 1124 "J.T. Conklin" wrote: > > Does anyone have a copy of the Nindy protocol specification or an old > Intel gnu960 (aka CTOOLS) distribution that contains Nindy source? I > checked developer.intel.com, but the CTOOLS distributions currently > available all have mon960 instead of Nindy. I squirreled away a couple copies of CTOOLs when I was at Cygnus, but I don't know if any were old enough to include Nindy sources still; don't remember ever seeing actual Nindy sources. > The reason I ask is because I'd like to get rid of the dcache_fetch() > and dcache_poke() functions which are only used by remote-nindy.c and > remote-bug.c. IMHO we should officially declare Nindy support obsolete. As you observed, Intel now denies its existence :-), the last physical board I knew of (at Cygnus) died ca 1996, and the last couple of years of GDB churning probably broke the Nindy support, but nobody appears to have noticed, or cared enough to report it as a bug. I could do the research to justify obsoleting Nindy, then you'd be free to whack the dcache functions (remote-bug.c is also an obsoletion possibility BTW). Stan From ac131313@cygnus.com Tue Jun 13 18:32:00 2000 From: Andrew Cagney <ac131313@cygnus.com> To: David J Croyle <dcroyle@telerama.com> Cc: gdb@sourceware.cygnus.com Subject: Re: Using GDB with standalone assembly code questions Date: Tue, 13 Jun 2000 18:32:00 -0000 Message-id: <3946E059.266C39A3@cygnus.com> References: <39466A96.E7B022BD@telerama.com> X-SW-Source: 2000-06/msg00122.html Content-length: 339 David J Croyle wrote: > (gdb) step > Single stepping until exit from function _start, > which has no line number information. > The program is not being run FYI, several things to be careful about. Use stepi not step. You may need to do a: (gdb) break *_start or is that break *&_start? (gdb) run to get things started. Andrew From jtc@redback.com Tue Jun 13 18:54:00 2000 From: jtc@redback.com (J.T. Conklin) To: Stan Shebs <shebs@apple.com> Cc: gdb@sourceware.cygnus.com Subject: Re: nindy protocol Date: Tue, 13 Jun 2000 18:54:00 -0000 Message-id: <5mg0qh3u4o.fsf@jtc.redback.com> References: <5mbt155ino.fsf@jtc.redback.com> <3946C259.3F4C058A@apple.com> X-SW-Source: 2000-06/msg00123.html Content-length: 2235 >>>>> "Stan" == Stan Shebs <shebs@apple.com> writes: Stan> I squirreled away a couple copies of CTOOLs when I was at Cygnus, but Stan> I don't know if any were old enough to include Nindy sources still; Stan> don't remember ever seeing actual Nindy sources. Do you still have access to them? I found the CTOOLS 5.0 release notes on developer.intel.com --- it looks like Nindy was replaced then. If you have an earlier release, it should have the Nindy sources. >> The reason I ask is because I'd like to get rid of the dcache_fetch() >> and dcache_poke() functions which are only used by remote-nindy.c and >> remote-bug.c. Stan> IMHO we should officially declare Nindy support obsolete. As Stan> you observed, Intel now denies its existence :-), the last Stan> physical board I knew of (at Cygnus) died ca 1996, and the last Stan> couple of years of GDB churning probably broke the Nindy Stan> support, but nobody appears to have noticed, or cared enough to Stan> report it as a bug. Stan> I could do the research to justify obsoleting Nindy, then you'd Stan> be free to whack the dcache functions (remote-bug.c is also an Stan> obsoletion possibility BTW). Feel free. I'm not going to argue against it. However, if Nindy supports arbitrary sized and aligned memory transfers the changes necessary to remove dcache_fetch() and dcache_poke() are trivial. If we can't determine whether it's safe, and you want to wait more before obsoleting the config, I propose that we commit it anyway. If it breaks anything and anyone cares, we'll hear about it soon enough. It appears that the remote-bug.c implements read/write by downloading and uploading s-records, so there should be no problems at all removing dcache_fetch() and dcache_poke() from it (at least I've never heard of any srec reader that didn't support arbitrary addresses). If the MVME187BUG monitor is anything like the m68k, ppc, and coldfire versions of BUG, it could be rewritten to use the generic monitor code, resulting in a smaller and more robust target. Whether anyone cares to do so is another story. If remote-bug.c is obsoleted, it appears that most of remote-utils.c (all the gr_* stuff) can too. --jtc -- J.T. Conklin RedBack Networks From shebs@apple.com Tue Jun 13 20:20:00 2000 From: Stan Shebs <shebs@apple.com> To: jtc@redback.com Cc: gdb@sourceware.cygnus.com Subject: Re: nindy protocol Date: Tue, 13 Jun 2000 20:20:00 -0000 Message-id: <3946F992.4A40BA12@apple.com> References: <5mbt155ino.fsf@jtc.redback.com> <3946C259.3F4C058A@apple.com> <5mg0qh3u4o.fsf@jtc.redback.com> X-SW-Source: 2000-06/msg00124.html Content-length: 1822 "J.T. Conklin" wrote: > > >>>>> "Stan" == Stan Shebs <shebs@apple.com> writes: > Stan> I squirreled away a couple copies of CTOOLs when I was at Cygnus, but > Stan> I don't know if any were old enough to include Nindy sources still; > Stan> don't remember ever seeing actual Nindy sources. > > Do you still have access to them? I found the CTOOLS 5.0 release > notes on developer.intel.com --- it looks like Nindy was replaced > then. If you have an earlier release, it should have the Nindy > sources. Actually, I think 5.0 is the earliest I have too. > Stan> I could do the research to justify obsoleting Nindy, then you'd > Stan> be free to whack the dcache functions (remote-bug.c is also an > Stan> obsoletion possibility BTW). > > Feel free. I'm not going to argue against it. However, if Nindy > supports arbitrary sized and aligned memory transfers the changes > necessary to remove dcache_fetch() and dcache_poke() are trivial. If > we can't determine whether it's safe, and you want to wait more before > obsoleting the config, I propose that we commit it anyway. If it > breaks anything and anyone cares, we'll hear about it soon enough. Fine by me. > If the MVME187BUG monitor is anything like the m68k, ppc, and coldfire > versions of BUG, it could be rewritten to use the generic monitor code, > resulting in a smaller and more robust target. Whether anyone cares to > do so is another story. There was at least one m88k workstation alive recently, somebody on this whose name I forget (sorry) sent in some patches for it last year or so. But embedded m88k boards these days? Rather unlikely I think. > If remote-bug.c is obsoleted, it appears that > most of remote-utils.c (all the gr_* stuff) can too. Yup, an attractive side benefit. To borrow from S&W, "omit needless code". :-) Stan From qqi@world.std.com Wed Jun 14 05:50:00 2000 From: Quality Quorum <qqi@world.std.com> To: Andrew Cagney <ac131313@cygnus.com> Cc: GDB Discussion <gdb@sourceware.cygnus.com> Subject: Re: That vision thing ... Date: Wed, 14 Jun 2000 05:50:00 -0000 Message-id: <Pine.SGI.3.95.1000614084827.13939A-100000@world.std.com> References: <39457E1A.D22C6468@cygnus.com> X-SW-Source: 2000-06/msg00125.html Content-length: 390 On Tue, 13 Jun 2000, Andrew Cagney wrote: > So yes. > > Exactly how to do this is another problem entirely. Do we just > re-arange the deck chairs or look more deeply. I would say re-arranging of deck chairs will be a signficant help in the looking, especially for the guys like me who mostly uses gdb and seldom has to tweak pieces here and there. > > Andrew > Thanks, Aleksey ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2000-06-12 19:48 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <1000602075018.ZM29997@ocotillo.lan>
2000-06-02 5:26 ` Proposal: convert function definitions to prototyped form Mark Kettenis
[not found] ` <1000602151553.ZM30578@ocotillo.lan>
[not found] ` <5mya4om115.fsf@jtc.redback.com>
[not found] ` <3938F700.509FD4AA@cygnus.com>
2000-06-05 11:05 ` J.T. Conklin
[not found] ` <3937816C.E66B9AE0@cygnus.com>
2000-06-03 0:13 ` Kevin Buettner
2000-06-12 18:10 ` Andrew Cagney
2000-06-12 19:48 ` Kevin Buettner
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox