Re: [avr-gcc-list] [RFC] Device specific linker scripts

[Dhakshinamoorthy, Soundararajan]

Hi,

The way i conveyed the problem might be misleading, i guess. The originial idea 
is to make device support easier.  This concept of supplementry linker 
configuration file will augemnet the main linker script with necessary device 
specific information, which will always be one per device. Such a file can also 
suppliment the information that gcc currently passes to the linker i.e -Tdata 
<section-start>.
This patch is a step towards achieving this. If you have ideas for making 
device support easier, i would be interested to discusss them as well.

Thanks,
Soundararajan

________________________________________
From: address@hidden address@hidden on behalf of Joerg Wunsch address@hidden
Sent: Friday, November 29, 2013 12:55 PM
To: address@hidden
Subject: Re: [avr-gcc-list] [RFC] Device specific linker scripts

"Dhakshinamoorthy, Soundararajan" <address@hidden> wrote:

> As discussed below,

I thought the outcome of the discussion was that it makes not
much sense?

>> >MEMORY
>> >{
>> >  text   (rx)   : ORIGIN = 0, LENGTH = 62K
>> >  boot   (rx)   : ORIGIN = 62K, LENGTH = 2K
>> >  data   (rw!x) : ORIGIN = 0x800100, LENGTH = 4K
>> >  eeprom (rw!x) : ORIGIN = 0x810000, LENGTH = 2K
>> >}

The correctness of these data even depends on fuse settings.  Do you
want to implement one ldscript for each possible fuse combination?

How are you going to handle devices with external SRAM option, do you
want to have one linker script for each per-user RAM configuration?

People could live without per-device linker scripts for more than ten
years, apparently without having much trouble.  I've got the
impression that you are trying to solve a problem that doesn't really
exist at all.  I know there are compromises in the way it's done right
now, but I still believe that per-device linker scripts are even worse
than the compromises we've got now.
--
cheers, Joerg               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/
Never trust an operating system you don't have sources for. ;-)

_______________________________________________
AVR-GCC-list mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/avr-gcc-list