This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Porting the linker


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]