>> >>* PR13812 .trampolines location in linker script cause >> >>"internal error: out of range error" >> >> >> >>Dunno if this is still an issue resp. can be solved by a better >> >>default linker script. Maybe a user-specific ld script is needed >> >>here, too. >> > >> >I'd say, this is not a bug, but abuse of the .progmem(.data) section, >> >> Not really. Problems arise if .trampolines is shifted out of the first >> 128KiB segment if .progmem gets too big. Notice that .trampolines is >> located *after* .progmem, thus a fix is to locate .trampolines before >> .progmem. > >Having always put trampolines before their destinations (on other >targets),
progmem does not contain destinations of stubs in .trampolines. And I don't see how experience from other targets would be pertinent to this particular issue. Are you familiar with the intended use of these sections in avr-gcc and avr-libc? > that seems preferable, and a simple linker script tweak. >Is there any reason not to improve the default script in this regard? It is not an *improvement*, it is a *change* with potentially detrimetal effect (reduced .usable "low progmem data" space. Have you read my previous answer to Johann's post? >> The trouble with that approach is that I found no way to express >> different flash usage scenarios in one linker script, e.g. you want to >> use segment #1 (2nd 64 KiB chunk) [A] for program or [b] for data. >> >> Data for __flash1 will be put into input section .progmem1.data, but >> I found no way to describe that in the linker script. > What happens when you add a .progmem1.data input section? Do you have experience with using >64kB constant data in FLASH? There are several ways to approach that, as I wrote in the places I referred to before. For "segmented" access (i.e. ELPM with constant high address byte, which is what __flashN is about), you need to ensure that the data is located not below the 0xN0000 address (0x10000 for __flash1). At the same time, if .text reaches above 0xN0000, it should not overlap these data, rather, it should "push" them upwards. Alternatively, the data could be located in a reverse order from top of the segment. IMHO there's no support for either in the current linker (I am no ld guru so I may easily be wrong). JW _______________________________________________ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
