This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Grouping all string Literals in one pool in the binary image

Note: This was originally posted on 20th June 2013 at http://forums.arm.com

I am currently ramping up on ARM DS-5. I want to know if it is possible to ensure that all string literals and constants in the entire binary output image, can be grouped/pooled in one single contiguous location, so that I have a clear distinction between the location of Code and the location of String literals (and constants) in my binary image.


I have read about Literal pooling in ARM tools. But what I understood is that each section will have its own literal pool. And if a section is larger than 4KB, more Literal pools will be needed for the same section.
I want to know if it is possible to have only one literal pool for the entire binary image.
Alternatively, is it possible to group all literal pools together so that they are contiguous in memory?

Thanks.
Parents
  • Note: This was originally posted on 4th July 2013 at http://forums.arm.com

    I don't really understand how you are going to switch the access on and off, but ignoring that...

    The short answer is "in general, no".  The longer answer is "in some cases, yes".

    There are a number of cases where armcc places literals in the .text section, e.g.


    int f1(int i) { return i +42; }
    const char *f2() { return "hello world\n"; }
    extern int x;
    void f3() { return x; } // literal generated for '&x'
    // ... other cases including floating point literals

    In these cases you can't place the literals separately from the code.

    There are some cases where armcc places literals in .constdata areas


    const char *f4() { return "a string literal that is a quite substantially longer string literal"; }
    struct T { int x, y; };
    void f5(struct T*p) { *p = (struct T){5, 7}; }


    These .constdata sections can be placed separately using the linker's "scatter loading" mechanism http://infocenter.ar...i/BABDDHBF.html

    In cases where the literals are globals variables, you can use __attribute__((section("..."))) to place them in separate sections and then scatter load them where you want, e.g.


    struct T2 { int x; const char s[10];  };
    extern const struct T2 a[] [/size][size=2]__attribute__((section("my_consts"))) = {
      { 11, "hi" },
      { 19, "there" },
    };


    (Of course there are many (an arbitrarily large number of) cases I haven't covered above.)
Reply
  • Note: This was originally posted on 4th July 2013 at http://forums.arm.com

    I don't really understand how you are going to switch the access on and off, but ignoring that...

    The short answer is "in general, no".  The longer answer is "in some cases, yes".

    There are a number of cases where armcc places literals in the .text section, e.g.


    int f1(int i) { return i +42; }
    const char *f2() { return "hello world\n"; }
    extern int x;
    void f3() { return x; } // literal generated for '&x'
    // ... other cases including floating point literals

    In these cases you can't place the literals separately from the code.

    There are some cases where armcc places literals in .constdata areas


    const char *f4() { return "a string literal that is a quite substantially longer string literal"; }
    struct T { int x, y; };
    void f5(struct T*p) { *p = (struct T){5, 7}; }


    These .constdata sections can be placed separately using the linker's "scatter loading" mechanism http://infocenter.ar...i/BABDDHBF.html

    In cases where the literals are globals variables, you can use __attribute__((section("..."))) to place them in separate sections and then scatter load them where you want, e.g.


    struct T2 { int x; const char s[10];  };
    extern const struct T2 a[] [/size][size=2]__attribute__((section("my_consts"))) = {
      { 11, "hi" },
      { 19, "there" },
    };


    (Of course there are many (an arbitrarily large number of) cases I haven't covered above.)
Children
No data