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

Odd linker problem

Hi,

I am adapting an existing project based on the ST10 chip. I am adding new data processing functions which are sat along side exisiting functions. Each function uses a unique data structure, therefore there is a TYPEDEF STRUCT for each function. The structures are defined in a corresponding header file. The project was working fine, until I got hold of it.

I added three new functions with their corresponding structures being added to the header file. All was well. Then I added a forth function. It compiled okay but then the linker threw a warning stating that a segment size had been set to less than zero by the SEGSIZE directive. The problem is the segsize directive has not been given to the linker.

After some messing about it became clear it was the amount of code and / or the number of TYPEDEF STRUCT occurances and not the latest function that was causing this problem.

I can get the build to complete but the target is malfunctioning and it looks like the pointer into the structure is mis-aligned.

I managed to strink the program until it would build without error, then preserved the M66 file. Then I increased the code size until it threw the warning. As this was by simply adding another TYPEDEF STRUCT statement, which had no variables declared to it, the actual code was functionally unchanged. I then compared the good and bad M66. About 10% throught the file the statement IGNORED STATEMENTS: was the only different.

Our great software engineer minds are all baffled by this one. We are using version 3.21.

Anyone got any ideas why this is happening and what to do to correct this?

Many thanks,

Dave

Parents
  • Sorry - was me using the wrong word. Some compilers/linkers uses the term "segment" (depends on processor architectures too) but it was the word "section" I intended to use in the previous post.

    Yes, you have a section (such as code section from one object file) that the linker can't see any references into. Then the linker will skip that section.

    This is most common when there exists functions that are never called.

    Sometimes, the code may be designed to be stored at an absolute address, in which case the accesses to the data or function(s) are done by absolute addresses too, in which case the linker will not see the references.

    Are you sure that your program isn't too large, so not everything fits when linking?

Reply
  • Sorry - was me using the wrong word. Some compilers/linkers uses the term "segment" (depends on processor architectures too) but it was the word "section" I intended to use in the previous post.

    Yes, you have a section (such as code section from one object file) that the linker can't see any references into. Then the linker will skip that section.

    This is most common when there exists functions that are never called.

    Sometimes, the code may be designed to be stored at an absolute address, in which case the accesses to the data or function(s) are done by absolute addresses too, in which case the linker will not see the references.

    Are you sure that your program isn't too large, so not everything fits when linking?

Children
  • Hi Per,

    Thanks once again for your thoughts. This makes sense as there is indeed a structure that is defined but not actually used. It is the inclusion of this structure that causes the warning, although to then add code that uses the structures doesn't fix the problem.

    Your other thought is also valid. The program size is now reaching the limits of the memory map definitions. This was very quickly spotted and we are looking at adjusting the memory space allocation to free up more space in the flash memory.

    The bothering thing is the nature of the fault that I am getting, has no bearing on the potential cause. The actual error is

    *** WARNING 11: SECTION SIZE UNDERFLOW; OLD SIZE + CHANGE < 0
        REGBANK: SCC_REGS
    
    L166 RUN COMPLETE.  1 WARNING(S),  0 ERROR(S)
    

    I wanted to make sure that there was no other reason that was leading to this.

    Many thanks once again,

    Dave