From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19891 invoked by alias); 29 Jan 2002 21:58:34 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 19811 invoked from network); 29 Jan 2002 21:58:31 -0000 Received: from unknown (HELO localhost.cygnus.com) (216.138.202.10) by sources.redhat.com with SMTP; 29 Jan 2002 21:58:31 -0000 Received: from cygnus.com (localhost [127.0.0.1]) by localhost.cygnus.com (Postfix) with ESMTP id 917DE3DD0; Tue, 29 Jan 2002 16:58:24 -0500 (EST) Message-ID: <3C571B00.6070203@cygnus.com> Date: Tue, 29 Jan 2002 13:58:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:0.9.7) Gecko/20020103 X-Accept-Language: en-us MIME-Version: 1.0 To: Andrew Cagney Cc: Jim Blandy , Eli Zaretskii , gdb-patches@sources.redhat.com Subject: Re: [rfa/doco] Srink the overlay diagram References: <3C4C6FF4.7040108@cygnus.com> <3791-Tue22Jan2002111309+0200-eliz@is.elta.co.il> <3C5635C6.90409@cygnus.com> Content-Type: multipart/mixed; boundary="------------040308090205060708010203" X-SW-Source: 2002-01/txt/msg00765.txt.bz2 This is a multi-part message in MIME format. --------------040308090205060708010203 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-length: 228 > I think: > > @example @group >
> @anchor{x-spot the title} > @end end > > Diagram @xref{x-spot the title} .... would work better. The attached does this. I ended up using @pxref{}. Andrew --------------040308090205060708010203 Content-Type: text/plain; name="diffs" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="diffs" Content-length: 5333 2002-01-21 Andrew Cagney <ac131313@redhat.com> * gdb.texinfo (How Overlays Work): Srink the overlay diagram. Index: gdb.texinfo =================================================================== RCS file: /cvs/src/src/gdb/doc/gdb.texinfo,v retrieving revision 1.76 diff -p -r1.76 gdb.texinfo *** gdb.texinfo 2002/01/20 11:59:38 1.76 --- gdb.texinfo 2002/01/29 21:55:57 *************** overlay's machine code from the large me *** 6418,6461 **** for it in the instruction memory, and then jump to its entry point there. @example @group ! Data Instruction Larger ! Address Space Address Space Address Space ! +-----------+ +-----------+ +-----------+ ! | | | | | | ! +-----------+ +-----------+ +-----------+<-- overlay 1 ! | program | | main | | | load address ! | variables | | program | | overlay 1 | ! | and heap | | | ,---| | ! +-----------+ | | | | | ! | | +-----------+ | +-----------+ ! +-----------+ | | | | | ! mapped --->+-----------+ / +-----------+<-- overlay 2 ! address | overlay | <-' | overlay 2 | load address ! | area | <-----| | ! | | <---. +-----------+ ! | | | | | ! +-----------+ | | | ! | | | +-----------+<-- overlay 3 ! +-----------+ `--| | load address ! | overlay 3 | ! | | ! +-----------+ ! | | ! +-----------+ ! To map an overlay, copy its code from the larger address space ! to the instruction address space. Since the overlays shown here ! all use the same mapped address, only one may be mapped at a time. @end group @end example ! This diagram shows a system with separate data and instruction address ! spaces. For a system with a single address space for data and ! instructions, the diagram would be similar, except that the program ! variables and heap would share an address space with the main program ! and the overlay area. An overlay loaded into instruction memory and ready for use is called a @dfn{mapped} overlay; its @dfn{mapped address} is its address in the --- 6418,6465 ---- for it in the instruction memory, and then jump to its entry point there. + @c NB: In the below the mapped area's size is greater or equal to the + @c size of all overlays. This is intentional to remind the developer + @c overlays don't necessarily need to be the same size. + @example @group ! Data Instruction Larger ! Address Space Address Space Address Space ! +-----------+ +-----------+ +-----------+ ! | | | | | | ! +-----------+ +-----------+ +-----------+<-- overlay 1 ! | program | | main | .----| overlay 1 | load address ! | variables | | program | | +-----------+ ! | and heap | | | | | | ! +-----------+ | | | +-----------+<-- overlay 2 ! | | +-----------+ | | | load address ! +-----------+ | | | .-| overlay 2 | ! | | | | | | ! mapped --->+-----------+ | | +-----------+ ! address | | | | | | ! | overlay | <-' | | | ! | area | <---' +-----------+<-- overlay 3 ! | | <---. | | load address ! +-----------+ `--| overlay 3 | ! | | | | ! +-----------+ | | ! +-----------+ ! | | ! +-----------+ ! @anchor{A code overlay}A code overlay @end group @end example ! The diagram (@pxref{A code overlay}) shows a system with separate data ! and instruction address spaces. To map an overlay, the program copies ! its code from the larger address space to the instruction address space. ! Since the overlays shown here all use the same mapped address, only one ! may be mapped at a time. For a system with a single address space for ! data and instructions, the diagram would be similar, except that the ! program variables and heap would share an address space with the main ! program and the overlay area. An overlay loaded into instruction memory and ready for use is called a @dfn{mapped} overlay; its @dfn{mapped address} is its address in the --------------040308090205060708010203--