Porting the linker

[Jean Christophe Beyler]

> It feels like your situation is similar to the small data areas supported by
> some architectures.  With most of those however if the small area is filled
> to excess the linker just issues an error message and aborts.

Yes that is the idea except that we don't want to make it abort.

> Just a thought - it might be easier in the linker to fill the large text and
> data sections first and then, as late as possible, extract portions of those
> sections to go into the smaller text and data sections.

That could be a solution, any hints as to how to do that ?

Thanks a lot,
Jean Christophe Beyler

On Mon, Mar 1, 2010 at 12:24 PM, Nick Clifton <nickc@redhat.com> wrote:
> Hi Jc,
>
>> - My architecture has hierarchy memory (basically 3 levels)
>
> Is this sort of like L1 cache, L2 cache and external RAM or something else ?
>
>> - However, technically, I'd have 3 sections for the data (both data
>> and bss) and 2 sections for text (1 level of the memory can't have
>> text). How do I explain this to the assembler ?
>
> The assembler can support as many sections as you like.  For example the
> .section pseudo-op can be used to create new sections with arbitrary names
> and various different attributes.  Presumably however you want to define
> some "well-known" extra sections that are specific to your port of the
> assembler and which the programmer does not have to specify themselves.
>  This is quite straightforward.  Several ports do it.  For example have a
> look at gas/config/tc-microblaze.c.
>
>> - Knowing that additionally, I'd need to have a system that overflows
>> if a smaller level is full
>
> Presumably this is something that you want to happen in the linker, not the
> assembler.
>
>> - Is there a correct way to do this without touching the internals of
>> the binutils that I'm missing or do I have to modify a bit it to make
>> it compatible to our architecture ?
>
> You are going to have to modify the internals of binutils.  Although with
> luck you should find that all of the changes that you need to make can be
> done via the various target specific hook functions provided by bfd and ld.
>
> It feels like your situation is similar to the small data areas supported by
> some architectures.  With most of those however if the small area is filled
> to excess the linker just issues an error message and aborts.
>
> Just a thought - it might be easier in the linker to fill the large text and
> data sections first and then, as late as possible, extract portions of those
> sections to go into the smaller text and data sections.
>
> Cheers
>  Nick
>
>
>