Re: PATCH BFD section load page support

[Timothy Wall <twall at tiac dot net>]

See comments interspersed.

Ian Lance Taylor wrote:

>    Date: Fri, 14 Jan 2000 17:15:46 -0500
>    From: Timothy Wall <twall@tiac.net>
>
> I still don't fully understand this load page stuff.  I will make
> series of statements.  Please tell me if any are false:
>
> * Each section in a fully linked file has a VMA, and LMA, and a load
>   page number.

Yes.  Implicit is a "run" page number, which is assumed to be handled entirely by
the running program.  The linker uses the "run" page number when allocating VMAs
for output sections, but doesn't otherwise store it.

>
> * The VMA is 32 bits.
> * The LMA is 32 bits.

The address may be 16 or more bits (16, 23, and 32 are known to exist; some chip
variants have differently sized address spaces).  Actual storage conventions may
vary with the specific target, but this is usually handled in the target-specific
relocations.

>
> * The load page number is 8 bits.

Yes.  The TI COFF description defines it as such.

>
> * Object files do not have an LMA or a load page number.  They only
>   have a VMA.  The load page number field in the object file is always
>   0.

Object files in TI COFF store the load page number.  It is assumed that the VMA
page value ("run" page) is handled entirely by run-time code, and is not stored
anywhere.

>
> * You have changed the linker MEMORY command.  You have changed it to
>   add a load page number for each memory region.  The effect of the
>   change is that each output section which is placed in a specific
>   memory region inherits the load page number of that memory region.
>   Sections which are not placed in a memory region (which is all
>   sections if the MEMORY command is not used) get a load page number
>   of 0.

Yes.

>
> Now, here's something I don't understand.  How does the chip address
> physical memory?  Does it send out a 32 bit address along with an 8
> bit load page?  That is, does it effectively have a 40 bit physical
> address?

Page zero corresponds to program memory; most chips have special instructions to
access this space.  Page 1 corresponds to data memory, and most other instructions
address this memory.

If additional paging is implemented on the target to extend the address space of
either program or data memory, the actual paging method is target-specific.  Of
course, if the paged memory maps to program space, the special program space
instructions must be used in addition to any special paging method.

>
> You seem to be describing a system in which the load page is
> effectively part of the physical memory address--the LMA.

Effectively the load (lma) and run (vma) pages are part of the address.
Unfortunately, encoding the page as part of the address is not as simple as it
first sounds.

>
>
>    Typical usage has page 0 correspond to PROG space on TI devices, and page 1
>    to DATA space (the 'c54x and several other chips have a dual, orthogonal
>    address space).  Up to 256 distinct pages are allowed;  typically target
>    designs provide a method for switching among pages.
>
> Switching between pages makes it sound like overlays.  What happens if
> an object loaded into 1 page refers to an object loaded in another
> page?  How does the linker handle such a relocation?  How does the
> chip implement it?

Switching between pages in this sense does correspond fairly well to overlays; the
primary usage of pages in the TI devices, however, is to split between program and
data space.  I don't actually know what the TI linker does with inter-page
references.  I would guess nothing, since my past experience has shown that
run-time page references are assumed to be explicitly coded into the program and
not actually saved in the object file.

All symbol/address references are assumed to be run-time addresses (vma) unless the
".label" directive is used (corresponds to storage class 20) which indicates a
load-time address (lma).


>
>
>    The TI COFF output stores a "memory page" field in the section header; there
>    is no documentation and the interpretation as the "load-time page" of the
>    section comes from examining how it is actually used by TI's tools
>
> Is the memory page field used in object files?  In files produced by
> ld -r?  Or only in fully linked files?

The memory page field is used in all object files in TI COFF, though it's always (I
think) zero until the final link.  My port mimics the TI behavior.

>
>
> I note that include/coff/tic80.h has a s_mempage field in
> external_scnhdr.  However, it is not used by the code.  It is actually
> zeroed out, because coffswap.h assumes that the s_flags field is 4
> bytes long, not 2 bytes as in tic80.h.

The tic80 port wasn't ever completely finished, which is probably why it's never
used by the code.  As for coffswap.h, I used PRE/POST macros to assure everything
in the header was set properly.

>
>
>    Date: Fri, 14 Jan 2000 17:29:32 -0500
>    From: Timothy Wall <twall@tiac.net>
>
>    As a "memory page", it is indeed "general" information (there are many DSPs
>    which use multiple memory pages).  In the linker, I simply called the field
>    "page" where it was added to the output section structures.
>
> I guess I don't understand what a memory page means in an input file.

In the simplest case, it indicates whether the section is destined for program or
data memory.  On an input file, it may not have any more meaning than the lma and
vma in the section header of that same input file.

>
>
> In an output file, it might mean something, in an environment which
> used an unusual object file format (such as yours) which could
> represent it.  I suspect that most environment for which this is
> meaningful simply use bits in the LMA.  Otherwise, you can not
> generate S-record or binary files, and it generally becomes more
> difficult to use common tools.

S-records and binary files for TI devices typically require that the entire image
reside in the default program memory space; the program must unpack and relocate
itself if some other configuration is required.

Using bits in the LMA requires that you have those bits available.  Defining the
target address size to be bigger than it actually is (in order to encode the page
bits therein) can be problematic.

>
>
>    Date: Fri, 14 Jan 2000 21:54:20 -0500
>    From: Timothy Wall <twall@tiac.net>
>
>    Program memory (PAGE 0)
>    0x0000-0x007F external
>    0x0080-0x13FF on-chip DARAM
>    0x1400-0x8FFF external
>    0x9000-0xFF7F ROM
>    0xFF80-0xFFFF interrupt vectors
>
>    Data memory (PAGE 1)
>    0x0000-0x005F memory-mapped registers
>    0x0060-0x007F scratch-pad DARAM
>    0x0080-0x13FF on-chip DARAM
>    0x1400-0xDFFF external
>    0xE000-0xFEFF on-chip ROM
>    0xFF00-0xFFFF reserved
>
> This makes it seem as though the LMA is only 16 bits, implying that
> the physical address is 24 bits.  In this case, we can simply use the
> upper bits of BFDs lma field to hold the load page.
>
> But I somehow doubt it's that simple.

In this case, the LMA *is* only 16 bits.  Some variants use 23 bits.  The c3x/c4x
uses 32 bits.  All have similarly orthogonal program/data address spaces.

I initially started this work for GDB support, and I did encode the page number in
the address itself (it's important for GDB to know whether a given address
corresponds to program or data memory when dumping or changing it).  This worked
for the c25/c5x/c54x b/c I could use 32 bits of address and make the stub ignore
the excess bits.  This may not work for the c3x/c4x, which has 32-bit addresses.

  After porting the assembler, binutils, and linker, I found that nothing really
cares about the page number (as far as TI compatibility is concerned) except for
the linker when allocating output sections.  TI devices themselves are actually
ignorant of any explicit "page" setting; there are a set of instructions for
accessing program memory and everything else assumes to refer to data memory.  If
the program behavior depends on specific memory pages, it is up to the logic of the
program to keep track of those pages.


Tim