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

nomeansno wrote:[color=blue]
> 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?[/color]

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".

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:[color=blue]
> nomeansno wrote:[color=green]
> > 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?[/color]
>
> 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".[/color]