build_system: Cleanup access to ".intList" section

[rakons]

This is currently proof of concept and idea for discussion.
I was trying to remove the need for dummy IDT_LIST memory definition that provides some limits to the number of supported interrupts. As I am working on solution for interrupt system that would require more fields in _isr_list structure this requirement for dummy memory is even more limiting.

The idea here is to add (INFO) type for the ".intList" section. Such a section is not present in the output and I could not access it via objcopy. But the section is still in elf file - and it can be accessed via pyelftools - and this is how I had used it.

The additional "gain" here is one temporary file less in the build directory.

I have tested it on hello_world sample on nrf52840dk_nrf52840 target. For the full solution it would probably require more cleanups for rest of the linker files around the declaration of the ".intList" section. I wish to get some feedback before I start doing it. If you see any drawbacks for the proposed solution or would you welcome it in zephyr?

[carlocaione]

The only concern I have (so far) is that the INFO output section type is there only for backward compatibility and my impression is that it could be removed or simply neglected soon.

Can you expand on:

provides some limits to the number of supported interrupts

?

[carlescufi]

@dcpleung could you please take a look?

[rakons]

@carlocaione - the ".intList" section is put into IDT_LIST memory section that has to be provided by chip vendor linker files. I can see that it used to be 2KB. Sure - we can increase it, but still would be some gimmick just to put a section here.
Every _isr_list occupies 16B on 32b architecture and 24B on 64bit architecture. At the beginning of the section is a header that takes 16B. It means that on 32b arch we can put here 127 entries, and on 64b - 83. Am I missing something? What would happen if we overflow this IDT_LIST memory section?

[rakons]

@carlocaione - Regarding to INFO section - I also saw it, but I also saw it is doing what I am expecting. This is also something we should discuss - how to reach the same result with the usage of INFO section. I will be probably able to look into it deeper in the next week.

[dcpleung]

Looks reasonable.

[carlocaione]

@carlocaione - the ".intList" section is put into IDT_LIST memory section that has to be provided by chip vendor linker files. I can see that it used to be 2KB. Sure - we can increase it, but still would be some gimmick just to put a section here.

sorry, I'm still not fully clear here. Increasing the 2KB limit would solve all your issues? Because I understand this is a bit unusual (having a fake section just to temporarily keep interrupt vectors) but if we can solve all the problem by simply increasing its size I would gladly take that instead of reworking the whole mechanism just at the end of the day to save one temporary file in the build directory.

[rakons]

Increasing the 2KB limit would solve all your issues? Because I understand this is a bit unusual (having a fake section just to temporarily keep interrupt vectors)

It still forces the vendors to choose some dummy address for that section that is not in use by anything else, just to temporary keep interrupt vectors. Why are we doing that? Why do we need to generate another file from input ELF file to just provide it to the script? Why cannot we just use elftools module that we are using anyway? This PR offers:

• Build script simplification (removing of the file that is first generated from ELF and then provided to the script with the same ELF).
• Getting rid of the needs of looking into device and providing some dummy address and space that has to be in the real address space but has to be free from any really existing peripherals and memories.
• And probably - I did not tested in yet - we would be able to simplify the build process even more because the INFO section does not have to be stripped away in the final build.

[carlocaione]

It still forces the vendors to choose some dummy address for that section that is not in use by anything else, just to temporary keep interrupt vectors. Why are we doing that? Why do we need to generate another file from input ELF file to just provide it to the script? Why cannot we just use elftools module that we are using anyway? This PR offers:

ok, just trying to understand the rationale here. Can you entirely remove the IDT_LIST section from all the linker scripts in the Zephyr repo and see if the CI is still green?

[rakons]

What about the usage of:

PHDRS
{
  intList PT_NOTE ;
}

...

SECTION_PROLOGUE(.intList,,)
{
	KEEP(*(.irq_info*))
	KEEP(*(.intList*))
} :intList

Did not tested it yet, just looking for some not depreciated way to get the same result. Anybody more familiar with linker scripts?

---

Just checked that it would not work.

[rakons]

Interesting fact: The hex files before and after the change differs at the end. The lst files are identical.

---

I found the difference source - the difference is at very end of the file where the boot string banner is placed. As the part of it is the zephyr commit hash - this is quite obvious the it would differ.

[rakons]

I had tried to create and use memory region:

IDT_LIST (!airwx) : ORIGIN = 0, LENGTH = 64K

It is still not the effect we are looking for.

[tejlmand]

Did some investigation on INFO in binutils.
It was introduced with binutils 2.7, Jun 24, 1996, and made backward compatible (note, this is not the same as deprecated) with binutils 2.10, May 2000.

This means that it has been around for >20 years, and afaict there is not a good alternative in the binutils releases <= 2.38.
2.38 is the version shipped with Zephyr-sdk.
With binutils >=2.39, there seems to be introduced an alternative with:
TYPE = type, where type can be an integer, or: SHT_PROGBITS, SHT_STRTAB, SHT_NOTE, SHT_NOBITS, SHT_INIT_ARRAY, SHT_FINI_ARRAY, and SHT_PREINIT_ARRAY, ref https://sourceware.org/binutils/docs/ld/Output-Section-Type.html.
but I haven't had a chance yet to test out if TYPE = <integer> can achieve the desired behavior.

Another interesting observation is this commit:
https://gnu.googlesource.com/binutils-gdb/+/6752dd75f76457902729a5f03d09fa28ec5d68c3

which is fairly recent, Mar 16, 2023, and is using the INFO type.
If the binutils project itself is using this type, then that indicates to me the following

• There is not a good alternative (or the project itself would have used it)
• It's not being removed anytime soon, unless replaced with an alternative, meaning we can adjust to that alternative at the same time.

My proposal is to accept the use of (INFO) and follow binutils releases closely, so that as soon as there is a good alternative introduced, then we switch to the alternative.

Note, when switching, for example to TYPE = type, we must carefully take into consideration non-Zephyr-sdk toolchains, as they can still be based on older ld releases.
In such a case we may adjust the linker script template to support both old and new, by testing which binutil / ld release currently in use.

[tejlmand]

Approved, based on following comment: #60838 (comment)

[tejlmand]

@rakons maybe take some of the information given here #60838 (comment) and add to the commit message.

In future, it will be easier to do a git blame / git log and understanding the choices made wrt. to (INFO) without having to find the PR / github message itself.

[rakons]

@tejlmand Thank you for the information and the job done. I had spend two days searching for alternative but did not manage to find so deep understanding. What I need now it to provide this proof of concept to the rest of the ld templates to make it fully ready PR.
During this work I will add additional info from your comment.

[rakons]

Just removed missed #ifndef LINKER_ZEPHYR_FINAL from qemu_x86_tiny.ld.

[rakons]

Rebase on main.

[rakons]

Another rebase to include uart_sam0 shadowed variable fix.

[dcpleung]

Have you tried with LLVM's lld and see if it still works?

[tejlmand]

we need to extend the linker script generator to work with the new INFO type.

[tejlmand]

this will not work.
The type specified here is not a GNU ld type, but a generic type which then maps to the linker script depending on whether that is ld or a scatter file.

That is also why you see a CMake warning with this PR:

CMake Warning at /projects/github/ncs/zephyr/cmake/modules/extensions.cmake:4247 (message):
  zephyr_linker_section(NAME ...) given unknown arguments: INFO;)                    

ld:

zephyr/cmake/linker/ld/ld_script.cmake

Lines 192 to 193 in b5bfe0a

	set(SECTION_TYPE_NOLOAD NOLOAD)
	set(SECTION_TYPE_BSS NOLOAD)

scatter:

zephyr/cmake/linker/armlink/scatter_script.cmake

Line 72 in b5bfe0a

if("${type}" STREQUAL BSS)

https://github.com/zephyrproject-rtos/zephyr/blob/main/cmake/linker/armlink/scatter_script.cmake#L269

so for this to work with the linker generator then we need a new type there.

INFO would be a good name 😉

See also: #61846

[tejlmand]

Have you tried with LLVM's lld and see if it still works?

I have tested with llvm (clang / lld) and compiler-rt.

INFO type is fully understood by lld.

[rakons]

In last force-push:
Updated section description from "TYPE (INFO)" to "TYPE INFO" after the discussion with @tejlmand as this would be the right way to use it after the INFO section would be added into linker script generator.

[rakons]

As it seems we cannot support anything similar to INFO section type on Keil - we have to pass this solution and return to the old one. Not happy about this. The only think that may still be used from this PR is probably the way the script is updated to take the IRQ information directly from the elf file instead of using temporary binary file.

[rakons]

As the decision has been made not to include this solution because we cannot support it on Keil compiler scatter files. New PR would be created with simplified version that only removes the need of the temporary binary file for interrupt table generation script.