From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kevin Buettner To: Andrew Cagney Cc: gdb@sourceware.cygnus.com Subject: Re: Proposal: convert function definitions to prototyped form Date: Mon, 12 Jun 2000 19:48:00 -0000 Message-id: <1000613024832.ZM16533@ocotillo.lan> References: <1000602075018.ZM29997@ocotillo.lan> <394589D8.8A61FECD@cygnus.com> X-SW-Source: 2000-06/msg00116.html 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 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 > > 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 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