On Sat, Feb 16, 2013 at 10:09:08PM +1100, Erik Christiansen wrote: > TL;DR: There is a workaround at the end. Is its lower intrusiveness > better balanced against the small optimisation, than the > binutils tweak which provides full automation? Whatever. ;-) > > On 15.02.13 15:41, Senthil Kumar Selvaraj wrote: > > On Fri, Feb 15, 2013 at 08:31:42AM +0100, Georg-Johann Lay wrote: > > > Does this really need binutils changes, or could it be achieved by > > > linker script improvements, e.g. start .text after the last .vector? > > It is automatic detection of the start of the "bad vectors" tail, prior > to the end of the vector table, which is more than difficult for both > gas and ld. > > > > Currently the size of .vectors is forced by crt.o, but maybe there > > > are other way to do it? > > > > > I couldn't think of any. Normally, -ffunction-sections and discarding > > unused input sections makes the linker exclude unused code, but that > > obviously won't work for the vector table and interrupt handlers, as > > there are no explicit references/callers. > > > > I don't know if all the logic can be expressed in a linker script - 2 > > levels of indirection are involved (symbols and then to addresses > > referencing those symbols), and the addresses themselves can't be moved. > > That level of semantics whizzes way over the linker's head, since the > language makes no attempt to deal with indirection, AFAICT. Also, > iterating over an array of addresses is not available. > > > I had some vague ideas about having one section per entry, and dealing > > with those sections in the linker script, but I didn't really get > > anywhere. If your concern is about baking in assumptions about avr-libc > > into binutils source code - I fully share it, but this was the only way > > I could get it to work. > > > > It still might be possible though; I'm hoping someone in the binutils > > mailing list would point it out if it is. > > Yes, individual input sections flitted through my mind too, on reading > the OP, but without any relevant information from the compiler, other > than that no used vector follows the tail of "bad vectors", ld is hard > pressed to perform this optimisation. Rereading "3.10.5 Evaluation" in > "info ld" reminds us why. (Just as conditional assembly also fails if we > try to do it with gas instead: 'Error: non-constant expression in ".if" > statement') > > As you've pointed out, even -ffunction-sections needs additional > selection information, which doesn't exist, greatly amplifying the > challenge. > > Granted, the (saved memory) reward for the effort is small, but if the > user would specify the number of the highest used vector, then gas > conditional assembly, in a "bad vector" macro does handle the task:
Ah, but right now, the vector table is defined in avr-libc (crt1/gcrt1.S) and gets built into crtxxx.o at avr-libc build time. It is then linked into the final executable automatically by the gcc driver. I guess that rules out conditional assembly? Regards Senthil _______________________________________________ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
