Variables mixed with a bunch of configuration constants

[hongshui3000]

Mixed in a bunch of configuration constants in the global variable display

The extension seems to have no ability to distinguish what is a variable and what is a constant

zephyr.zip

[haneefdm]

Yup, they are all symbols as reported by GDB/nm/objdump. What are they? A bit of C code would have helped to see what the declaration(s) look like. Can you attach a tiny executable?

[hongshui3000]

Yup, they are all symbols as reported by GDB/nm/objdump. What are they? A bit of C code would have helped to see what the declaration(s) look like. Can you attach a tiny executable?

zephyr.zip :elf && map

It seems strange that something like this CONFIG_ARCH is only used in the compilation phase. Why does it appear in global variables?

My understanding is that variables should only be placed in the bss and data segments and not elsewhere

[haneefdm]

It seems strange that something like this CONFIG_ARCH is only used in the compilation phase. Why does it appear in global variables?

Because objdump reports them as global symbols and no different from a regular global variable.

My understanding is that variables should only be placed in the bss and data segments and not elsewhere

Not totally true. That is only a convention. You can have multiple bss and data segments and they don't even have to have those names. Try the IAR compiler.

However, these variables are marked as 'ABS' and have no size which means we can probably ignore them.

[hongshui3000]

However, these variables are marked as 'ABS' and have no size which means we can probably ignore them.

It is very good if it can be ignored. There are too many such configurations in me, which greatly affects the search for real global variables.

[haneefdm]

Do you know what C/C++ construct creates such symbols? Like CONFIG_ARCH for instance. Was it a #define? Or something constant in assembly.

I don't have a single executable where I see such symbols. So, no way to test it on the HW I got.

[haneefdm]

Try the latest pre-release from the Marketplace, but I do need an answer to the question above. Otherwise, I will remove the potential fix I have in the pre-release.

[hongshui3000]

Try the latest pre-release from the Marketplace, but I do need an answer to the question above. Otherwise, I will remove the potential fix I have in the pre-release.

I'm using zephyrrtos, he uses kconfig configuration system (same as linux kernel configuration system), when I can configure these macros in the configuration file, then the build system will automatically generate header files for me. My understanding of these will only be expanded during compilation and preprocessing, and the corresponding code will be selected to be compiled, or put into rom

I really don't understand why these symbols are needed in the generated elf compiled by gcc, for debugging? or other? ?

[hongshui3000]

The new preview version looks great to me without a lot of useless symbols

[hongshui3000]

I probably understand the role of ABS
https://stackoverflow.com/questions/56035556/what-is-abs-section-and-when-to-use

[haneefdm]

What we already knew and was common was this.

00000000 l    df *ABS*	00000000 swap.c
000000a5 g       *ABS*	00000000 __data_size

What we see new now with whatever version of GCC you are using is this

00000001 g     O *ABS*	00000000 CONFIG_FLASH

The O marks this symbol as a variable. This is something we have never seen before. The fact that the #defines survive and make it to the symbol table is also new.

What compiler are you using? Are you using GCC or some version of clang?

[haneefdm]

I am closing this but you can still report which compiler/version you were using.

[hongshui3000]