Allows the following script to proceed:
SECTIONS { . foo : { begin_foo = .; *(.foo) end_foo = .; } }
Differential D22683
[ELF] Symbol assignment within input section list evgeny777 on Jul 22 2016, 8:27 AM. Authored by
Details
Diff Detail Event Timeline
Comment Actions Adding Davide to reviewers. Davide, it looks like you handle PROVIDE (and PROVIDE_HIDDEN) inside output section definition just the same way as PROVIDE inside SECTIONS block, adding absolute values. To my understanding this is not correct, because such symbols should have values relative to section base address. Also location counter changes, while input sections are added to output section and your patch seems to ignore this, always using the value of 'Dot'. Also there were the following issues in linkerscript-provide-in-section test case a) Section name mismatch (.blah != blah) Comment Actions Yes, I was thinking the same, and writing a patch. You beat me to the punch apparently, so, I'll just review it.
I fixed a). Are b) and c) really problems? Comment Actions This seems OK, but please wait for Rui for final sign-off. Sorry if I missed this (there's enough activity on linker scripts recently that's hard to keep track of all the things going on). I recommend you to cc: me on you next patches to avoid this kind of issues. I'll do the same. Comment Actions createSections and addScriptedSymbols are already too long, I don't want to add more code to that function. They need to be simplified before adding features. Comment Actions Rebased. Comment Actions Not sure if the visitor pattern is a good choice, but there's a correctness issue with this patch so I'll send this comment now.
Comment Actions Linking our proprietary micro kernel depends on this feature, but I can't share any details, of course BTW, FreeBSD also uses it: https://svnweb.freebsd.org/base/head/sys/conf/ldscript.amd64?revision=284870&view=markup#l100
Comment Actions Review updated. Changes:
and also allows to pass Davide test (linkerscript-provide-in-section.s)
After assignOffsets() is called from Writer::finalizeSections(), those virtual section offsets (OutSecOff) are equal to values of dot symbol.
Comment Actions Interesting idea, but it doesn't sound any easier to me. You'll likely maintain list of symbols instead of list of SymbolInputSection<ELFT>. Also will it work in this case: .foo { *(.foo) end_foo = .; . = ALIGN(0x1000); }
Comment Actions Review updated. Comment Actions Sorry to bring this back again, but I'm wondering why we can't create absolute symbols. This is different from what GNU linkers do, but looks like difference between section-relative symbols and absolute symbols don't matter. If we create absolute symbols, we can remove the virtual input section class.
Comment Actions I think the main reason, we're using virtual input sections is that this the only way to calculate correct symbol offset. As you may know location counter is not incremented while we add input sections to output section, and the true size of input sections is known only after call to OutputSectionBase<ELFT>::assignOffsets(). So if you suggest an algorithm, which can calculate correct symbol value (w/o using virtual input sections) in the case below: .foo : { *(.foo); end_foo = .; *(.bar) } then we can probably switch to absolute symbols (BTW we can also use synthetic symbols - there is a little difference, if any). /* script for linking shared library */ SECTIONS { .text : { text_start = .; *(.text) } } So, when shared library is loaded by application, what value would text_start have, in case it is absolute? I don't know yet, but will try.
Comment Actions I think one of the reasons can be: A symbol set to a relative expression will be relocatable if you request relocatable output For absolute symbols there is ABSOLUTE() keyword:
Comment Actions Review updated.
Comment Actions I'm still thinking about the best way to support it, and I feel like there's a way, but I think it's better to land this. We can improve it later if needed. There's a question for you. How are you going to support assignments to "." inside output section descriptors?
Comment Actions If we calculate input section offset in addSection() and do not change it later then assignment to "." should be easy. I think, its enough to add a parameter to addSection, like this template <class ELFT> void OutputSection<ELFT>::addSection(InputSectionBase<ELFT> *C, uintX_t Offset) { // ... add section to Sections vector and set OutSec. uintX_t Off = alignTo(this->Header.sh_size + Offset, S->Alignment); S->OutSecOff = Off; // ... calculate size } I haven't tried it yet, but at a first glance this should work
Comment Actions Review updated. SECTIONS { .foo : { * (.foo) sizeof_foo_1 = SIZEOF(.foo); /* sizeof_foo_1 is equal to sizeof( *.foo ) */ * (.bar) sizeof_foo_2 = SIZEOF(.foo); /* sizeof_foo_2 is equal to sizeof ( *.foo ) + sizeof ( *.bar) */ . = ALIGN(0x1000); /* The section ends on page boundary */ } } This patch uses virtual input sections (once again, yeah), but they're created and processed inside LinkerScript<ELFT>, without any change introduced to base class InputSection<ELFT>. The reason is that with "." assignments real section size depends on VA and can only be calculated in assignAddresses(). For example sizes of .foo and .bar output sections in example below will be different: SECTIONS { . = 0x500; .foo { . = ALIGN(0x1000); } /* size of .foo is 0x1000 - 0x500 */ } SECTIONS { . = 0xA00; .bar { . = ALIGN(0x1000); } /* size of .bar is 0x1000 - 0xA00 */ } Please also check the test case Comment Actions Let's submit this soon. After submitting this, we could probably simplify things, but this patch provides a real value and is a good start. But before doing this, I think this needs to be fixed...
Comment Actions Review updated. Comment Actions Rui, it was not very clear from your latest comment if this patch can be landed or you want to hold it on for further review. Could you please clarify? Thanks. Comment Actions Review updated. The assignOffsets() now uses LLVM-style casting (https://reviews.llvm.org/D23351) Comment Actions LGTM
|
I think we name this kind of thing OwningSections.