• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 51 subscribers
  • Views 1454 views
  • Users 0 members are here
Support feedback
Options
Options

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Linker.cmd grammar

Anonymous
Anonymous
Guru 17045 points

Hi All,

 

 

I would like to ask some questions on grammar of linker.cmd file, in particular, to Brad Griffis’s 6455 starter project example.

 

c6455.cmd said:
MEMORY
{
        L1P:     o = 00e00000h   l = 00008000h  /* 32k */
        L1D:     o = 00f00000h   l = 00008000h  /* 32k */
        L2:      o = 00800000h   l = 00200000h  /* 2MB */
}
 
SECTIONS
{
      vectors           >           0x00800000, RUN_START(_ISTP_START)
    .text       >       L2
    .stack      >       L2
    .bss        >       L2
    .cinit      >       L2
    .cio        >       L2
    .const      >       L2
    .data       >       L2
    .switch     >       L2
    .sysmem     >       L2
    .far        >       L2
}

 

First, according to SPRU186s, TMS320C6000 Assembly Language Tools v 7.0 User's Guide, page 186:

SPRU186s, p. 186 said:
 “>” is used for allocating the section into a range defined in the MEMORY directive with the specified name (like SLOW_MEM) or attributes.

 

In SECTIONS, all other sections are allocated into L2, which is a “range” properly defined in MEMORY. But for the first line in SECTIONS:

c6455.cmd, first allocation line SECTIONS said:
 
SECTIONS
{
      vectors           >           0x00800000, RUN_START(_ISTP_START)
    ……
}
 

Is 0x00800000 a range? It is a memory address alone, more close to “origin” in the “origin-length” pair in MEMORY. But if it is a single address, why the example still uses “>” here? Why it is not using

SPRU186s, p. 186 said:
 

Binding:  allocates a section at a specific address.  

 

 

The second question is for RUN_START. Description for this can be found on p.205 of the same document, which says:

 

RUN_START( sym )         Defines sym with the run-time start address of related allocation unit

 

This is quite succinct and there is no example following directly applies to this c6455.cmd example. What does

1.    sym

2.    run-time start address

3.    related allocation unit

mean, respectively?

                

                         

                             

And in main.c, the parameter of RUN_START(_ISTP_START) is referenced and used like this:

main.c beginning part said:

extern far unsigned int ISTP_START;      

extern cregister volatile unsigned int ISTP, IER, ISR, CSR;

 
void main()
{
      // set Interrupt Service Table Pointer to start of vector table
      ISTP = (unsigned int)(&ISTP_START);
……
}
 

 

Since main.c can reference ISTP_START and assign its address to ISTP, which is CPU’s internal Interrupt Service Table Pointer Register , RUN_START must have somehow associated

1.    Vectors

2.    0x00800000

3.    START

 

together. In detail, how is this achieved?

 

 

 

Sincerely,

Zheng

 

 

 

 

 

  • 0
    TI__Guru**** 173310 points

     

    Zheng Zhao said:
    But if it is a single address, why the example still uses “>” here?

    The syntax here can use either > or =. In fact the example on Page 186 shows:
       .text: > 0x4000


    Zheng Zhao said:

    What does

    1.    sym
    2.    run-time start address
    3.    related allocation unit

    mean, respectively?              

    sym is the name of the symbol defined at link time and can be anything you choose.
    run-time start address is the start address of the section that the operator is used with
    related allocation unit is the input or output section that the operator is associated with

    Section 7.5.8.7.1 contains a simple example of using these operators. These linker defined symbols can then be referenced in your C code which is what is being done in your code example.


       ISTP = (unsigned int)(&ISTP_START);
    The symbol ISTP_START is defined at link time to be the runtime start address of the section vectors. In the C code, this address is then assigned to ISTP to make it point to the start of vector table.

  • Anonymous
    0 Anonymous in reply to AartiG
    Guru 17045 points

    Dear Aarti,

     

    On page 186, paragraph 3,

    SPRU977a said:

    You control allocation by specifying one or more allocation parameters. Each parameter consists of a keyword, an optional equal sign or greater-than sign, and a value optionally enclosed in parentheses. If load and run allocation are separate, all parameters following the keyword LOAD apply to load allocation, and those following the keyword RUN apply to run allocation. The allocation parameters are:

    Does "optional" and "or" here means

    1. "=" and ">" are functionally equivalent.
    2. Both are completely optional and they can be omitted. Leaving a blank here followed by other parameters won't affect anything.

    Is this correct?

     

     

    The second question is that since according to paragraph 1 of p.186, each section has two locations in the memory (load and run). So here

    1. These two address are the same. Both the load and run address of section .sect "vectors" is 0x00800000.
    2. Specifying precisely the address (0x00800000 here) corresponds to "binding" rather than "named memory". It is more definite in the sense that the starting address for .sect "vectors" is explicitly declared and the linker would not change this, which is different from the case of allocating to a "named memory" range, in which case the linker "uses lower memory address first and avoids fragmentation when possible".
    3. RUN_START(_ISTP_START) does not interfere with the precise binding, of if used, "named memory" range specification. It does not interfere the process or change the final allocated memory address at all, but only assign the starting address of .sect "vectors" in the memory to _ISTP_START (in assembly grammar; ISTP_START in C grammar). It is a post-action after binding or "named memory".

     

    Are they correct? Could you verify each of them for me?

     

    The third question is on page 205, but actually on page 186 when either the "binding" or "named memory" is used. Is the size of a particular section determined by the linker and the user cannot interfere with that? I am asking this because in p.186

    1. "Binding", only a starting address is specified
    2. "Named memory", only a range is specified

    None of the two specified the size. But this is reasonable, since size of the object file is determined through long chain of processing by first compiler and then assembler, which the user cannot know (or can, but difficult to know) precisely beforehand. Therefore, although the user cannot (or difficult to) know the size of a particular section's object file, for example, .sect "vectors" here, the can retrieve that by symbols that are associated with these sizes. And this is indeed the purpose of provinding

    1. LOAD_SIZE( sym )  Defines sym with the load-time size of related allocation unit
    2. RUN_SIZE(sym )    Defines sym with the run-time size of related allocation unit

    to the user.

     

    Again, are they correct? Could you verify each of them for me?

     

     

    Sincerely,

    Zheng

     

     

     

  • 0 in reply to Anonymous
    TI__Guru**** 244510 points

    Zheng Zhao said:

    Does "optional" and "or" here means

    1. "=" and ">" are functionally equivalent.

    Yes.

    Zheng Zhao said:

    2. Both are completely optional and they can be omitted. Leaving a blank here followed by other parameters won't affect anything.

    No.  You need to write the '=' or '>' in most cases.  There may be a case or two where you can omit it.  But I never do.

    Zheng Zhao said:

    The second question is that since according to paragraph 1 of p.186, each section has two locations in the memory (load and run). So here

    1. These two address are the same. Both the load and run address of section .sect "vectors" is 0x00800000.

    Yes.

    Zheng Zhao said:
    Specifying precisely the address (0x00800000 here) corresponds to "binding" rather than "named memory". It is more definite in the sense that the starting address for .sect "vectors" is explicitly declared and the linker would not change this, which is different from the case of allocating to a "named memory" range, in which case the linker "uses lower memory address first and avoids fragmentation when possible".

    Yes.

    Zheng Zhao said:
    RUN_START(_ISTP_START) does not interfere with the precise binding, of if used, "named memory" range specification. It does not interfere the process or change the final allocated memory address at all, but only assign the starting address of .sect "vectors" in the memory to _ISTP_START (in assembly grammar; ISTP_START in C grammar). It is a post-action after binding or "named memory".

    Yes.

    Zheng Zhao said:
    The third question is on page 205, but actually on page 186 when either the "binding" or "named memory" is used. Is the size of a particular section determined by the linker and the user cannot interfere with that?

    Yes.

    Zheng Zhao said:

    the user cannot (or difficult to) know the size of a particular section's object file, for example, .sect "vectors" here, the can retrieve that by symbols that are associated with these sizes. And this is indeed the purpose of provinding

    1. LOAD_SIZE( sym )  Defines sym with the load-time size of related allocation unit
    2. RUN_SIZE(sym )    Defines sym with the run-time size of related allocation unit

    to the user.

    Yes.

    Thanks and regards,

    -George

  • Anonymous
    0 Anonymous in reply to George Mock
    Guru 17045 points

    Dear Aarti and George,

     

    Thanks very much for your detailed explanation. This question is now resolved.

     

     

    Sincerely,

    Zheng