Re: [PATCH] GDB command-line switches and annotations docs

[Elena Zannoni <ezannoni@cygnus.com>]

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 <ac131313@cygnus.com>
To: Fernando Nasser <fnasser@cygnus.com>
Cc: David Whedon <davidw@gordian.com>, 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: <Pine.BSF.3.96.1000215205325.23431p-100000@ares.gordian.com> <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 <john@feith.com>
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  |                         |
-------------------------------------------------------------------------