On 20/08/2021 23:02, Segher Boessenkool wrote: > On Fri, Aug 20, 2021 at 08:55:54PM +0200, David Brown wrote: >> On 20/08/2021 10:22, Werthmann Luca via Gcc-help wrote: >>> I am writing to ask if there is a chance with the GNU GCC Compiler to group __attribute__((section (“NAME”))) statements. >>> >>> IAR Supports for example the following commands: >>> >>> # pragma default_function_attributes = @ ".MY_FUNC" /* start placing following functions in section .MY_FUNC */ >>> # pragma default_function_attributes = /* stop placing functions in section*/ >>> >>> # pragma default_variable_attributes = @ ".MY_DATA" /* start placing following variables in section .MY_DATA */ >>> # pragma default_variable_attributes = /* stop placing functions in section*/ > >> To the best of my knowledge, there is no way to do this in gcc - you >> have to put the section attribute on each function. (You can use a >> macro to reduce the typing!) > > There are no such pragmas, correct. And macros+attributes (as you > suggest) is a more flexible solution. Is there some use case that would > make such pragmas super useful, overcoming all the obvious usability > downsides of it? In embedded programming, it is not uncommon to have different areas of memory that you need for different purposes. For example, a microcontroller is likely to have flash to use for holding the code. But code that is used for erasing and re-programming the flash (for in-system updates) cannot run from flash - it needs to be in ram. So you would have to mark all the functions involved as being in a section that then gets linked to ram. With gcc, you have to do that individually for all functions involved. With other embedded compilers, you'd use a pragma - after all, these functions are likely to be all within the same file. In another case, such as the device I am using at the moment, the processor (an ARM Cortex-M7) has "tightly coupled memories" as well as main ram and flash. Access to instructions and data in the TCM's is significantly higher bandwidth, lower latency, and much lower jitter - so you use it for critical tasks. It is limited in size, so you can't put /all/ the code in the instruction tightly-coupled memory. But it is not so limited that you only want a few functions there. If there were pragmas for function sections, it would be easy. Individual function attributes gets very tedious and ugly for so much code. So I end up using complicated linker setups. In a perfect (for me) toolchain, you'd have pragmas for code and data sections in addition to attributes. These would affect the base name of the section, which would still contain additional parts if -ffunction-sections or -fdata-sections is used. (These are very useful if you are writing code that is more of a library, where the final program will only use some of the functions - in small embedded systems you don't use dynamic libraries at all.) And I'd like to be able to have warnings (or errors) if code placed within a specific section called functions (including library support functions, such as software floating point routines, as well as normal functions) that are outside that section. See also <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88391> I'd also like to have a "small data section", as is often found on targets with lots of registers (like the PowerPC or Risc-V). It would not have a reserved base register, but the compiler would know that all data smaller than the cut-off point (perhaps 16 bytes, configurable with -msmall-data-limit) is within 16-bit offset from a base register. And it could be placed in small, fast memory while leaving big arrays and buffers in the bigger, slower memories. These kinds of features would be extremely useful to a lot of small-system embedded programmers. How feasible they would be to implement, I don't know. (I would expect pragmas for code and data sections should be reasonable, at least.) mvh., David > >> If you are versed in linker files, it is possible to have a modified >> linker setup to put the code or data from a specific file into >> non-standard output sections. > > Or you can play games with objcopy. > >> I too would like to see this as a feature in gcc - it is one of the few >> features that are common to most embedded compilers but missing from gcc. > > Do -ffunction-sections / -fdata-sections help your use case? > > > Segher >
