Hi,
W dniu 5.07.2023 o 16:45, David Brown pisze:
On 05/07/2023 15:29, Rafał Pietrak wrote:
[---------------]
OK. I don't see a problem here, but I admit that mixing semantics
often lead to problems.
I think it also allows better generalisation and flexibility if they are
separate. You might want careful control over where something is
allocated, but the access would be using normal instructions.
Conversely, you might not be bothered about where the data is allocated,
but want control of access (maybe you want interrupts disabled around
accesses to make it atomic).
that would require compiler to know the "semantics" of such section. I
don't think you've listed it below, worth adding. If I understand you
correctly, that means the code generated varies depending on target
section selected. This is linker "talking" to compiler if I'm not mistaken.
but OK. I see your point.
[----------]
Let me try to list some things I think might be useful (there may be
some overlap). I am not giving any particular order here.
1. Adding a prefix to section names rather than replacing them.
OK. +1
2. Adding a suffix to section names.
+1
3. Constructing section names at compile time, rather that just using a
string literal. (String literals can be constructed using the
pre-processor, but that has its limitations.)
I'm not sure what this means? At compile time, you only have literals,
so what's missing?
4. Pragmas to apply section names (or prefixes or suffixes) to a block
of definitions, changing the defaults.
+1
5. Control of section flags (such as read-only, executable, etc.). At
the moment, flags are added automatically depending on what you put into
the section (code, data, read-only data). So if you want to override
these, such as to make a data section in ram that is executable (for
your JIT compiler :-) ), you need something like :
__attribute__((section("jit_buffer,\"ax\"\n@")))
I assume, that adding an attribute should split a particular section
into "an old one" and "the new one with new attribute", right?
One would need to have linker logic (and linker script definitions)
altered, to follow that (other features so far wouldn't require any
changes to linkers, I think).
to add the flags manually, then a newline, then a line comment character
(@ for ARM, but this varies according to target.)
6. Convenient support for non-initialised non-zeroed data sections in a
standardised way, without having to specify sections manually in the
source and linker setup.
What gain and under which circumstances you get with this? I mean, why
enforce keeping uninitialized memory fragment, while that is just a one
shot action at load time?
7. Convenient support for sections (or variables) placed at specific
addresses, in a standardised way.
Hmm... Frankly, I'm quite comfortable with current features of linker
script, and I do it like this:
SECTIONS
{
sfr_devices 0x40000000 (NOLOAD): {
. = ALIGN(1K); PROVIDE(TIM2 = .);
. = 0x00400; PROVIDE(TIM3 = .);
. = 0x00800; PROVIDE(TIM4 = .);
}
}
The only problem is that so far I'm not aware of command line options to
"supplement" default linker script with such fragment. Option "-T"
replaces it, which is a nuisance.
8. Convenient support for sections that are not allocated space by the
linker in the target memory, but where the contents are still included
in the elf file and map files, where they can be read by other tools.
(This could be used for external analysis tools.)
Isn't it so, that current debugger sections are just that?
Extrapolating your words: Do you think of sections that you would have
full control on it's content at compilation, and it isn't sufficient to
do it like this:
char private[] __attribute__((section("something"))) = {
0xFF, 0x01, 0x02, ....
};
9. Support for getting data from the linker to the code, such as section
sizes and start addresses, without having to manually add the symbols to
the linker file and declare extern symbols in the C or C++ code.
+1
10. Support for structs (or C++ classes) where different parts of the
struct are in different sections. This would mean the struct could only
be statically allocated (no stack allocation - just global or static),
and it would have no accessible address or size (you could have pointers
to fields, but not to the struct objects themselves). This would let
you tie together objects made of multiple parts such as constant data in
flash and writeable data in ram.
+1
11. Convenient support for building up tables where the contents are
scattered across different source files, without having to manually edit
the linker files.
do you have an example where that is useful?
12. I'd supplement the list with a better control on code section names
towards something like code namespaces.
13. and data sections "growing downwords" like stack does. This is for
more flexible planning of memory layouts of micros (limited RAM). One
class of sections you put into RAM sequencialy bottom to top, the other
category from top to bottom.
-R
