feat: support using an expression when setting the location counter#2005
feat: support using an expression when setting the location counter#2005vishruth-thimmaiah wants to merge 6 commits into
Conversation
Signed-off-by: vishruth-thimmaiah <vishruththimmaiah@gmail.com>
Signed-off-by: vishruth-thimmaiah <vishruththimmaiah@gmail.com>
Signed-off-by: vishruth-thimmaiah <vishruththimmaiah@gmail.com>
| { | ||
| . = 0x600000; | ||
| . = 0x300000 * 2; | ||
| start_of_sections = .; |
There was a problem hiding this comment.
Setting the location before defining any sections sets the location for the first section in the section table, not the first section in the linker script. Hence the need for this change, as the first section might not be .text.
There was a problem hiding this comment.
I guess possibly another way of looking at what you said is that when the linker reads the linker script, when it encounters the first section, it emits certain linker-generated sections before that first section. This alternative way of looking at it might suggest a slightly different implementation. e.g. perhaps when reading the linker script, those implicit sections should be inserted, almost as if they were in the file. Not sure if that would have any implications or how it would compare in terms of complexity. Don't feel that you need to change anything in this regard... just something to think about.
Also related... I assume the location counter can be set either before the first section or between sections. Are both tested?
There was a problem hiding this comment.
Also related... I assume the location counter can be set either before the first section or between sections. Are both tested?
Yes, this is already tested in line 10.
Signed-off-by: vishruth-thimmaiah <vishruththimmaiah@gmail.com>
vishruth-thimmaiah
changed the title
.Signed-off-by: vishruth-thimmaiah <vishruththimmaiah@gmail.com>
vishruth-thimmaiah
force-pushed
the
expr_loc
branch
from
4cbb5c6 to
17f9f6d
Compare
| { | ||
| . = 0x600000; | ||
| . = 0x300000 * 2; | ||
| start_of_sections = .; |
There was a problem hiding this comment.
I guess possibly another way of looking at what you said is that when the linker reads the linker script, when it encounters the first section, it emits certain linker-generated sections before that first section. This alternative way of looking at it might suggest a slightly different implementation. e.g. perhaps when reading the linker script, those implicit sections should be inserted, almost as if they were in the file. Not sure if that would have any implications or how it would compare in terms of complexity. Don't feel that you need to change anything in this regard... just something to think about.
Also related... I assume the location counter can be set either before the first section or between sections. Are both tested?
| if current_section_id.is_none() { | ||
| output_sections.set_base_address(new_location.address.clone()); | ||
| continue; | ||
| } |
There was a problem hiding this comment.
If I comment out this if-block, the tests still seem to still all pass. Is it possible to make the test exercise and verify the behaviour here?
There was a problem hiding this comment.
I suppose we could verify .text is not at the base address, since it is not the first section outputed.
| &symbol_db, | ||
| ); | ||
|
|
||
| let memory_regions: Vec<crate::linker_script::MemoryRegion<'_>> = symbol_db |
There was a problem hiding this comment.
If I replace this Vec with and empty one, the tests still pass. Is it practical to add a test that catches it?
There was a problem hiding this comment.
We don't fully support the syntax for defining MEMORY regions that ld requires for an executable, so writing a test for this might not be possible here. memory_regions here is used for evaluating ORIGIN and LENGTH functions in an expression.
Signed-off-by: vishruth-thimmaiah <vishruththimmaiah@gmail.com>
2 participants
This PR adds support for using expressions when setting the current location within
SECTIONS.This PR doesn't add support for using symbols when setting the location pointer.