MPLINK and the .cinit section (rant)

Author
KeyserSoze
New Member
  • Total Posts : 3
  • Reward points : 0
  • Joined: 2005/09/30 11:34:41
  • Status: offline
2005/09/30 12:43:14 (permalink)
0

MPLINK and the .cinit section (rant)

I have read through a lot of messages on this forum on the topic of the .cinit section generated by MPLINK.

To all the users that do C codes on the PIC; I know you need this section.

For those of us that code in assembly and need every instruction location this "feature" of MPLINK ... well stinks.

This is why.

It seems that in order to use MPLINK on any project you must have an INITIALIZED DATA section (.cinit) of at least two instruction words. Even if you have no use for the .cinit section.

To avoid using MPLINK you must not use relocatable code and assemble a single file of all the code every time to produce a .HEX file for programming and debug. This means to me that you cannot link from common library of object modules.

The only solution I've got so far is to hack the LKR script to force the .cinit section to addresses 0x0002 and 0x0003.

I'm not happy with this solution and would prefer have an option for MPLINK to suppress the .cinit section when there is no data in it.
#1

6 Replies Related Threads

    Olin Lathrop
    Super Member
    • Total Posts : 7463
    • Reward points : 0
    • Joined: 2004/02/26 17:59:01
    • Location: Littleton Massachusetts
    • Status: offline
    RE: MPLINK and the .cinit section (rant) 2005/09/30 13:59:21 (permalink)
    0
    The only solution I've got so far is to hack the LKR script to force the .cinit section to addresses 0x0002 and 0x0003.

    Only solution? Of course not. First, what's the difference if .CINIT ends up at address 2 or somewhere else. It still takes up 2 words, so this isn't even a solution other than "ignore it", which is the solution I use most of the time.

    One time I needed to get rid of .CINIT so I used the linker file to stick it at an unused address. That worked, except some programmer software (including my own) will give you an error if there are illegal addresses in the HEX file. The solution was to write a HEX file post-processor that removed anything at that illegal address. This is not an elegant solution, but not hard and it works.
    < Message edited by Olin Lathrop -- Sep. 30, 2005 4:59:38 PM >
    #2
    magio
    Super Member
    • Total Posts : 2159
    • Reward points : 0
    • Status: offline
    RE: MPLINK and the .cinit section (rant) 2005/09/30 14:31:06 (permalink)
    0
    Hehe, sometimes we have to do this things to make projects work.

    This makes me remember, the vectors declaration on the linker files from 0x00 to 0x04 wich is 'dangerous' and 'even not useful' for programming relocatable code that works with interrupts.

    I also remember this was commented by you Olin some time ago.

    I also think that a 'preprocessor' as you have is a nice tool and a 'need' for having a well defined simple structure for files that 'need' to be shared among many projects but with different constant declarations.

    /edit : changed a typo vecotrs --> vectors
    < Message edited by magio -- Oct. 4, 2005 1:39:44 PM >

    Embedded Software and Hardware Development


    #3
    KeyserSoze
    New Member
    • Total Posts : 3
    • Reward points : 0
    • Joined: 2005/09/30 11:34:41
    • Status: offline
    RE: MPLINK and the .cinit section (rant) 2005/09/30 17:06:37 (permalink)
    0
    First, what's the difference if .CINIT ends up at address 2 or somewhere else.


    The difference is that the words at address 2 and 3 are almost useless and having a .CINIT section with two more useless words is just annoying.

    MPLINK is the first linker I've used that puts in unnecessary code.

    I usually have trouble just getting a linker to put in the require code.Smile
    #4
    xiaofan
    Super Member
    • Total Posts : 6247
    • Reward points : 0
    • Joined: 2005/04/14 07:05:25
    • Location: Singapore
    • Status: offline
    RE: MPLINK and the .cinit section (rant) 2005/09/30 21:20:05 (permalink)
    0
    A simple fix for you, switch to gpasm/gplink, the open source
    alternative of MPASM/MPLINK. It works on lots of OSes,
    including Windows and Linux.

    Switch to gpasm and it does not created that useless section.
    I find out the 2 bytes difference by comparing the hex
    file generated by gpasm/gplink and MPASM/MPLINK.
    Craig Franklin is the author of gputils (including gpasm/gplink).
    So far I have no problems to assemble/link my MPASM code
    under gpasm/gplink.

    However in general, that 2 bytes should not matter.

    Regards,
    Xiaofan


    On 9/23/05, Craig Franklin < craigfranklin@users.sourceforge.net> wrote:
    >
    >I check the list file and find out they are indeed almost the same.
    >The only difference is that the code section starts with 0x07 for
    >MPASM/MPLINK and 0x05 for the gpasm/gplink. There is two word
    >not used by MPASM/MPLINK, a bit strange. The linker scripts are
    >exactly the same.
    >

    mplink always reserves space for .cinit even if no initialized data
    sections exist. Run mplink with the /m option and you will see it.
    gplink only creates the symbol if an initialized section is present.

    The lesson here is map files are your friend. If anything looks strange
    look there.
    #5
    Olin Lathrop
    Super Member
    • Total Posts : 7463
    • Reward points : 0
    • Joined: 2004/02/26 17:59:01
    • Location: Littleton Massachusetts
    • Status: offline
    RE: MPLINK and the .cinit section (rant) 2005/10/01 10:57:24 (permalink)
    0
    The difference is that the words at address 2 and 3 are almost useless

    Useless for anything other than a section containing two words or less. If you have such a section then the linker will put it there. The point is that it doesn't matter if .CINIT goes there or some other two word section. If there is no other two word section, then .CINIT will be the closest fit and the linker is sure to put it there. There is no advantage to forcing .CINIT there. The linker will do the best fit automatically.

    and having a .CINIT section with two more useless words is just annoying.

    Yes, but that has nothing to do with the point you are responding to. Annoying or not I still can't see a point in forcing the linker to put .CINIT at 2.
    #6
    JasonK
    Moderator
    • Total Posts : 3274
    • Reward points : 0
    • Joined: 2003/11/14 09:49:40
    • Location: Microchip Technology in Arizona, USA
    • Status: offline
    RE: MPLINK and the .cinit section (rant) 2005/10/04 10:20:38 (permalink)
    0
    Hi all,
    For those of us that code in assembly and need every instruction location this "feature" of MPLINK ... well stinks.
    Just to clarify, you can use the .cinit section from assembly code to initialize data. See < \MPASM Suite\Example\IDASM16.ASM > for an explanation. However, in practice, most MPASM/MPLINK users probably don't use the .cinit section.

    We have an open enhancement request to suppress the .cinit section, however it is currently low in priority relative to other compiler/assembler/linker enhancements in the pipeline. I'll bring up the issue at the next MPLINK requirements review. Thanks for the feedback.
    #7
    Jump to:
    © 2014 APG vNext Commercial Version 4.5