macros: RIOT_FILE_RELATIVE printing wrong file name for headers

[OlegHahm]

If RIOT_FILE_RELATIVE is located inside a header (e.g. inside a macro or static inline function), it will give the wrong file name, i.e. the name of the including C file instead of the header's file name.

[kaspar030]

Yes... Can anyone think of how to fix this?

[OlegHahm]

Maybe @Kijewski?

[miri64]

Bump

[kaspar030]

Cantfix?

[miri64]

For __FILE__ it works as expected, so there might be a way to fix it.

[Kijewski]

Dunno if this even needs a fix. I think the current state is even better than printing the .h file, because when you look at the .c file, you can easily see that this line uses a macro, and follow its macro expansions, but it is extremely difficult to do the reverse, and trace back the expansions that led to this line in the .h file.

[miri64]

Dunno if this even needs a fix. I think the current state is even better than printing the .h file, because when you look at the .c file, you can easily see that this line uses a macro, and follow its macro expansions, but it is extremely difficult to do the reverse, and trace back the expansions that led to this line in the .h file.

But if you try something like printf("%s:%d ...\n, RIOT_FILE_RELATIVE, __LINE__); the output is very confusing.

[miri64]

(in inline functions I mean)

[OlegHahm]

Dunno if this even needs a fix. I think the current state is even better than printing the .h file, because when you look at the .c file, you can easily see that this line uses a macro

Nope, because the debug message will give you the name of the .c file, but the line number from the .h file.

[Kijewski]

the debug message will give you the name of the .c file, but the line number from the .h file.

OK, that's less than optimal :)

[OlegHahm]

Anyone with a nice solution?

[cladmi]

I fell on a related issue because libfixmath_unittest uses __FILE__ for outputing the file name. Which makes the size of the build firmware vary with the build path. So I took some time to read about it.

From my tests, the issue mentioned here is only present for inline functions and not macros.

• inline functions, __FILE__ and __LINE__ are evaluated as the header and RIOT_FILE_RELATIVE is set to the C file.
• macros __FILE__ and __LINE__ are evaluated to the C file which is the same as RIOT_FILE_RELATIVE.

__FILE__ uses the path given to the compiler https://gcc.gnu.org/onlinedocs/cpp/Standard-Predefined-Macros.html

Another solution is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70268 but only recently added for GCC 8 and as patch for llvm https://reviews.llvm.org/D49466

---

I tried replacing gcc $(abspath C file) by cd $(RIOTBASE) && gcc $(relative path to the C file) It makes __FILE__ have the relative value and could be used instead of RIOT_FILE_RELATIVE.
However, it makes the generated .d file have a wrong path for the c file as it is not relative to the current directory anymore.

My solution for this would be to change the way we are currently compiling and always build from $(RIOTBASE) and refer to the sources with their relative path.

make -C $(RIOTBASE) -f $(SRCDIR)/Makefile

And Makefile.base would deduce the relative SRCDIR from the Makefile location or could be specified from command line for packages.

The downside of this is that SRCS and wildcard in general should be adapted to take this into account.

core/Makefile:SRC := $(filter-out mbox.c msg.c thread_flags.c,$(wildcard *.c))

It could remove the need to do abspath all the time and only have relative path in the build.

This could also help in general to have reproducible builds when different build directories are used, even for the debug symbols and also allow spaces in the path to RIOT.

---

It is something I would be interested to do and would be for more than just the debug macro.
Would that be a direction you would agree to take ?

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions.

[maribu]

Judging from the title only, I think @benpicco solved this some time ago

[OlegHahm]

The macro is gone entirely and I couldn't reproduce the issue any more.