ARM 4.6.4 linker warning

Compression is only allowed on sections that have been finalized; that is, all of the data has been filled in, and there are no unresolved external references.  "Foo" is for some reason not-yet-resolved.  Perhaps you are doing a partial link?

No. It is full link. the code basically looks like this (single file):

extern void Foo(void);

extern void *const Ptr1;
extern void *const Ptr2;
extern void *const Ptr3;

typedef void (*FOO)(void);
volatile FOO Foos[] =
{
    Foo,
    NULL
};
volatile void *const *Voids[] =
{
    &Ptr1,
    &Ptr2,
    &Ptr3
};

void Foo(void)

{

}

Linker does not complain about non function constant data.  Ptrs are defined in linker file and no warnings are issued. Generated assembly places both Foos and Voids into .data section. What might be the problem here?

I'm not very familiar with ARM, I'd need a reproducible test case (with command line options) to analyze this.  I note that probably all of the variables "Foos", "Voids", and "PtrN"  are in the .data section, and Foo is probably in the .text section, which may be relevant to the warning.

yes, I believe that .text is the reason for warning. However it shouldn't matter for linker because all symbols are resolved before compressions starts, aren't they?

The small test case is attached. You will need to add 4.6.4 ARM compiler and adjust path in the linker_foo.bat file.

Eugene2185.linker_foo.zip

Okay, first of all, the linker would emit the same warning about the reference to Ptr1, but it stops emitting this particular warning after the first one affecting a particular section.  You can see this by removing the array "Foos".

Second, the real problem is that in the linker command file, the section ".cinit" is being placed inside a group with sections that it refers to.  This is problematic.  .cinit should not be placed in a group with any section that will be initialized at startup.

How would you propose then to achieve sequential allocation of input sections? In my example I need all section to be sequential block and Ptr1pointing to the first unallocated address in flash.

Since I did not receive an answer to the question I guess it wasn't clear. Allow me to re-phrase it.

Given that .cinit can not be used in the GROUP statement how does user need to structure linker command file to have consecutive (or as a unordered but contiguous block) allocation of arbitrary set of input sections (including .text, .const and .cinit) and be able to place labels at the start and the end of the allocated block?

Thank you,

Eugene

Eugene, 

Sorry for the delay.  I don't have much to say at this point.  You have raised a valid question, and we are discussing how to respond.  I hope to reply by tomorrow.

Thanks and regards,

-George

The reasons behind why you get this warning ...

warning #10229-D: output section ".data" refers to load symbol "Foo" and
   hence cannot be compressed; compression "rle" is ignored

... are a bit complicated.  The .data section cannot refer to function pointers like Foo, or symbols developed in the linker command file like Ptr1, and be compressed.  I'll add a full explanation later.  For now, I want to focus on the solution.  The solution is to isolate the data structures which contain the problem symbols into a separate section.  This new section will not get compressed, but since it is small, it won't matter much. 

A good way to get your data structures into their own section is with GCC variable attributes.  For the code you give above it looks like this ...

    volatile FOO Foos[]
        __attribute__ ((section ("for_special_syms"))) =
    ...
    volatile void *const *Voids[]
        __attribute__ ((section ("for_special_syms"))) =

You have to build with the option --gcc to use such attributes.  Another method is to use the DATA_SECTION pragma, in which case you do not need to use --gcc.

In the linker command file, place the section for_special_syms just like .data.

Thanks and regards,

-George

George,

There is a problem with this solution when software is a collection of COTs. These are delivered to a fixed set of code generation options and and COT internal data structures can not be changed by the end user. I do not know and can not control where in the collection of COTs files or objects  function pointers or other references to linker or .const section symbols will be placed into .data section.

On the other hand when .cinit section is out of the GROUP statement then it gets compressed regardless of the function pointers or linker defined labels being placed into .data section. At least there are no warnings and map file looks fine. Why would linker have an issue with ordered (with regards to other input section inside the GROUP statement) placement of .cinit? I do not recall this being the problem for COFF formats.

Could you find other solution for consecutive placement of input sections along with .cinit by using just linker command file? The order does not matter as long as a set of input sections can be placed between linker defined labels for start and the end of the block. I can't use MEMORY directive as I obviously do not know the size of the generated code before link step.

Thanks,

Eugene

George,

Why does it work if .cinit is not in the GROUP statement? According to your explanation it shouldn't or it does not work and linker is not reporting it?

Thanks,

Eugene

Eugene,

You are talking about a different situation.  I'll try to describe this situation and explain why it works.

There is no end_of_flash symbol.  Rather, a function has its address used in some table of function pointers.  This function is at some address within the .text section.  The table appears in the .data section.  In the test case you sent, this function is named Foo (in .text), and its address appears within a table named Foos (in .data).

Your test case places both .text and .cinit within the same GROUP.  You get a similar warning diagnostic in that case.  Why?  Going back to the numbered steps from my last post, you conceptually change out .data for the entire GROUP.  Step 2 now means space is allocated in memory for the GROUP.  But that cannot happen until the length of the compressed .cinit is known.  But .cinit cannot be compressed because it needs to know the address of the function in text (Foo).  And so it goes.  The circle of dependencies appears once again.

What happens if .text and .cinit are not in a GROUP?  Then all the steps of my previous post can take place on .text, and then on .cinit.  In particular, by the time step 3 for .cinit occurs, the address of the function (Foo) is known, and the relocations can be finalized.  Thus, .cinit can be compressed.

Thanks and regards,

-George