On 05/07/2023 18:13, Rafał Pietrak via Gcc wrote:
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.
No, it's about the access - not the allocation (or section). Access
boils down to a "read" function and a "write" function (or possibly
several, optimised for different sizes - C11 _Generic can make this
neater, though C++ handles it better).
[----------]
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?
The compiler knows a lot more than just literal values at compile time -
lots of things are "compile-time constants" without being literals that
can be used in string literals. That includes the value of static
"const" variables, and the results of calculations or "pure" function
calls using compile-time constant data. You can do a great deal more of
this in C++ than in C ("static const int N = 10; int arr[N];" is valid
in C++, but not in C). Calculated section names might be useful for
sections that later need to be sorted.
To be fair, you can construct string literals by the preprocessor that
would cover many cases.
I can also add that generating linker symbols from compile-time
constructed names could be useful, to use (abuse?) the linker to find
issues across different source files. Imagine you have a
microcontroller with multiple timers, and several sources that all need
to use timers. A module that uses timer 1 could define a
"using_timer_1" symbol for link time (but with no allocation to real
memory). Another module might use timer 2 and define "using_timer_2".
If a third module uses timer 1 again, then you'd get a link-time error
with two conflicting definitions of "use_timer_1" and you'd know you
have to change one of the modules.
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?
You can't have the same section name and multiple flags. But you
sometimes want to have unusual flag combinations, such as executable ram
sections for "run from ram" functions.
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?
Very often you have buffers in your programs, which you want to have
statically allocated in ram (so they have a fixed address, perhaps
specially aligned, and so you have a full overview of your memory usage
in your map files), but you don't care about the contents at startup.
Clearing these to 0 is just a waste of processor 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.
These are ugly and hard to maintain in practice - the most common way to
give fixed addresses is to use macros that cast the fixed address to
pointers to volatile objects and structs.
But sometimes it is nice to have sections at specific addresses, and it
would be a significant gain for most people if these could be defined
entirely in C (or C++), without editing linker files. Many embedded
toolchains support such features - "int reg @ 0x1234;", or similar
syntax. gcc has an "address" attribute for the AVR, but not as a common
attribute. (It is always annoying when one target has an attribute that
would be useful on other ports, but only exists on the one target.)
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?
They are, yes. But it would be useful to have non-debug user sections
that act in a similar manner - it would not confuse debuggers, and be
easier for user-written parsers to pull out of the elf or map files.
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, ....
};
You also need control of the allocation (or lack thereof). This can be
done using sections with flags and/or linker file setup, but again it
would be good to have a standardised GCC extension for it. It is far
easier for people to use a GCC attribute than to learn about the messy
details of section flags and linker files.
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?
You might like to have a code organisation where source files could
define structures for, say, threads. Each of these would need an entry
in a thread table holding priorities, run function pointer, etc. If
this table were built up as a single section where each thread
declaration contributed their part of it, then the global thread table
would be built at link time rather than traditional run time setup. The
advantages include a clear static measure of the number of the number of
threads (see point 9), clear memory usage, and smaller initialisation
code. (Obviously we are talking about statically defined threads here,
not dynamically defined threads.)
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.
Fair enough.
