From mboxrd@z Thu Jan 1 00:00:00 1970 From: Elena Zannoni To: Eli Zaretskii Cc: Elena Zannoni , gdb-patches@sourceware.cygnus.com Subject: Re: [PATCH] GDB command-line switches and annotations docs Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <14537.18119.116000.442262@kwikemart.cygnus.com> References: <14537.5048.99180.910863@kwikemart.cygnus.com> <200003101809.NAA22092@indy.delorie.com> X-SW-Source: 2000-q1/msg00647.html Eli Zaretskii writes: > > Elena Zannoni writes: > > > > (Are there plans to make gdbmi.texi be part of the manual as well?) > > > > > > > Eventually yes (Andrew?), right now it is not in prime time form yet. It is > > still very rough work in progress. > > IMHO, it is much better to link between the two right now, and make > any necessary corrections later. As far as I could see, gdbmi.texi is > in quite a good shape, it just lacks a few menus and @node lines to > make it a valid Texinfo file. Most of the work can be done in Emacs > automatically. > > The current situation, where a large part opf the package is not > documented at all, is IMHO much worse. > > I can throw together a few patches as outlined above, if that would > help. > I agree with you, but at present the contests of gdbmi.texi are out of date in a few places. Andrew or I should go through it and make it better match with the actual MI functions. It shouldn't take long, but I don't have much time at this moment. > > I was planning on removing the -async option, it is now redundant. > > It's much easier to remove part of the docs than to write it ;-) > Anyway, if -noasync stays, you will need some of what I wrote under > its description. > Yes, definitely. > > The behavior you describe is the ultimate goal, we are only > > about 50% there. > > The truth is, I still don't know enough about the event loop's > interaction with the target side to write the docs about it. But I > thought there was no better way to get attention to its being > undocumented than to throw some patches on you-all ;-). I do think > that refining the description should be the job of someone who knows > the fine details. > I admit I haven't documented the event loop machinery at all (that should actually go in the internal manual). I thoroughly commented the code though, if that's any excuse :-). I wasn't going to document the existance of target 'async' either, because that's also supposed to go away, and be absorbed into a new and improved target 'remote'. There are still a bunch of loose ends to finish before that's going to happen. So I am not sure what the best course of action is. Elena >From ac131313@cygnus.com Sat Apr 01 00:00:00 2000 From: Andrew Cagney To: Fernando Nasser Cc: David Whedon , gdb-patches@sourceware.cygnus.com Subject: Re: patch: disassembly look Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38ABB118.2CAD0498@cygnus.com> References: <38AAECC2.8439CF80@cygnus.com> X-SW-Source: 2000-q1/msg00215.html Content-length: 1093 Fernando Nasser wrote: > > Hi David, > > This is really cool. I am not sure who the maintainer is but I guess > he/she will approve (I hope). Well Fernando, you're partially on the hook. This is to do with the command line :-) > But *please*, make the default to plain asm, will you? This will make > sure that the GUIs that still use console output won't break (who knows > how many are still out there). > > Also, you should consider adding a patch to the manual as well. This is > a cool feature and if you include it in there I am certain there will be > very grateful users of you changes pretty soon :-) In terms of a change. Yes, DDD et.al. would (unfortunatly) freak out if presented with this change as it currently stands. It should default to the old style. At a more technical level, what happens if the patch as it stands, encounters re-ordered (randomly ordered) instructions. Does (should?) your code print a source line multiple times in that case? Have a look at how GDB/MI and GDBtk handled that problem (ok so you can't see gdbmi just yet). enjoy, Andrew >From john@feith.com Sat Apr 01 00:00:00 2000 From: John Wehle To: nsd@bosbc.com Cc: cgf@cygnus.com, eliz@delorie.com, gdb-patches@sourceware.cygnus.com, jimb@cygnus.com, msnyder@cygnus.com Subject: Re: GDB 4.17 Patch for stack aligned i386 code Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <200003250030.TAA14328@jwlab.FEITH.COM> X-SW-Source: 2000-q1/msg01013.html Content-length: 1281 >>Are you handling non-leaf functions even when the stack pointer is changing? > > Yes. It works by emulating instructions to figure out the stack pointer > on entry to or exit from the function. The opcodes library, with a few > minor changes, provides the instruction information in an > architecture-independent format. Cool. >>Does your patch handle functions where the prologue uses "andl" to align >>the frame? > > I don't know. Do you happen to have an example of how to generate such > code? I'd be interested in trying it. I'm not sure what I still have laying around other than a very old patch for GCC. The idea is to handle a prologue which looks like: func: pushl %ebp movl %esp,%ebp andl $-15,%esp subl $32,%esp function arguments are relative to %ebp and local variables are relative to %esp. Extra alignment has been applied to the stack pointer in order to ensure that local variables don't cross a cache boundary. -- John ------------------------------------------------------------------------- | Feith Systems | Voice: 1-215-646-8000 | Email: john@feith.com | | John Wehle | Fax: 1-215-540-5495 | | -------------------------------------------------------------------------