segment naming in COFF output - VxWorks

This is a discussion on segment naming in COFF output - VxWorks ; Hi, Running in an IxWorks 1.1 environment. In a new image build of ours, we suddenly have more than one text segment, that is we now have: ..text ..text1 In an immediately preceeding build we didn't have the 2nd .text ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: segment naming in COFF output

  1. segment naming in COFF output

    Hi,
    Running in an IxWorks 1.1 environment. In a new image build of ours,
    we suddenly have more than one text segment, that is we now have:
    ..text
    ..text1

    In an immediately preceeding build we didn't have the 2nd .text segment
    (a decent amount of new code was added).
    Now our builds fail because of the .text1 segment.

    Can anyone fill me in on why the linker produces the 2nd different text
    segment? And what I might need to do to either make it go away or
    arrange the linker script/build process to
    incorporate it?

    TIA


  2. Re: segment naming in COFF output

    nomeansno wrote:
    > Hi,
    > Running in an IxWorks 1.1 environment. In a new image build of ours,
    > we suddenly have more than one text segment, that is we now have:
    > .text
    > .text1
    >
    > In an immediately preceeding build we didn't have the 2nd .text segment
    > (a decent amount of new code was added).
    > Now our builds fail because of the .text1 segment.
    >
    > Can anyone fill me in on why the linker produces the 2nd different text
    > segment? And what I might need to do to either make it go away or
    > arrange the linker script/build process to
    > incorporate it?


    I believe that you've set the "--split-by-reloc" option
    to the linker. COFF object files can only handle 65535
    relocations per section. Thus, when your code gets too
    large, you need the linker to split it into multiple
    text sections. All this is good and necessary.

    You also to adjust the default linker script to refer
    to .text* sections rather than just .text sections, to
    concatenate all the .text stuff into the same memory area.

    To get a copy of the linker script, you can enter
    ld960 --verbose > ldscript.default
    then edit the script and save it. Then point to the new
    script with the linker option "-T ldscript.new".

  3. Re: segment naming in COFF output

    Hi,
    OK, I understand your explanation. [The linker isn't being given any
    explicit flag to do the relocation/segment magic (the Intel CTOOLS port
    of the tool chain for the linker doesn't seem to even allow that
    flag).]
    So, I've tried to use a linker script to map the *.text and *.text1
    segments from the input files to be mapped to the *.text segment of the
    output file but it seems to ignore it. That is I have:

    SECTIONS
    {
    .text :
    {
    *(.text .text1)
    . = ALIGN(0x40);
    }

    --- other stuff ----
    }

    It does not produce an output file with a single .text segment, it
    still produces a .text and a .text1. Also, can't simply map the
    input .text* to some arbitrary output name because downstream tools
    (for which we have no source) are looking for a single .text segment.
    Any ideas?
    Thanks.


    Bill Cox wrote:
    > nomeansno wrote:
    > > Hi,
    > > Running in an IxWorks 1.1 environment. In a new image build of ours,
    > > we suddenly have more than one text segment, that is we now have:
    > > .text
    > > .text1
    > >
    > > In an immediately preceeding build we didn't have the 2nd .text segment
    > > (a decent amount of new code was added).
    > > Now our builds fail because of the .text1 segment.
    > >
    > > Can anyone fill me in on why the linker produces the 2nd different text
    > > segment? And what I might need to do to either make it go away or
    > > arrange the linker script/build process to
    > > incorporate it?

    >
    > I believe that you've set the "--split-by-reloc" option
    > to the linker. COFF object files can only handle 65535
    > relocations per section. Thus, when your code gets too
    > large, you need the linker to split it into multiple
    > text sections. All this is good and necessary.
    >
    > You also to adjust the default linker script to refer
    > to .text* sections rather than just .text sections, to
    > concatenate all the .text stuff into the same memory area.
    >
    > To get a copy of the linker script, you can enter
    > ld960 --verbose > ldscript.default
    > then edit the script and save it. Then point to the new
    > script with the linker option "-T ldscript.new".



+ Reply to Thread