is there a macro symbol for strlen($LINUX_SOURCE_PATH)
in the kernel, there are a lot of usages of __FILE__ this means that there are a lot of copies of fully rooted paths, including all the varying ~/src/linux prefixes used by individual builders. Id hazard a guess that something like __RELPATH_FILE__ would work in many cases and perhaps even be more readable (by reducing long strings) in the generated output Do the macros exist to cobble this together for compile-time ? Does it warrant a short name ? either to wrap __FILE__ uses or replace them ?
On 19/09/04 03:42PM, jim.cromie@gmail.com wrote:
in the kernel, there are a lot of usages of __FILE__
this means that there are a lot of copies of fully rooted paths, including all the varying ~/src/linux prefixes used by individual builders.
On gcc, `__FILE__` is the path of the file relative to the directory that the build is run from. Try something like #include <stdio.h> #define testing() printf("%s\n", __FILE__) int main() { testing(); } and compile it from different directories to replicate this behaviour.
Id hazard a guess that something like __RELPATH_FILE__ would work in many cases and perhaps even be more readable (by reducing long strings) in the generated output
Do the macros exist to cobble this together for compile-time ? Does it warrant a short name ? either to wrap __FILE__ uses or replace them ?
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
On Wed, Sep 4, 2019 at 4:14 PM Varun Iyer <varun_iyer@posteo.net> wrote:
On 19/09/04 03:42PM, jim.cromie@gmail.com wrote:
in the kernel, there are a lot of usages of __FILE__
this means that there are a lot of copies of fully rooted paths, including all the varying ~/src/linux prefixes used by individual builders.
On gcc, `__FILE__` is the path of the file relative to the directory that the build is run from.
Try something like
#include <stdio.h> #define testing() printf("%s\n", __FILE__) int main() { testing(); }
and compile it from different directories to replicate this behaviour.
whoa. how long have I been out ? per https://www.cprogramming.com/reference/preprocessor/__FILE__.html __FILE__ is a preprocessor macro that expands to full path to the current file. and thanks for that simple demo. I shoulda done that myself, but I had no concept that such a change might happen. and its not the whole story. when I rebuild from .. the __FILE__ value changes [jimc@frodo play]$ make gcc/file.o cc -c -o gcc/file.o gcc/file.c [jimc@frodo play]$ make gcc/file cc gcc/file.o -o gcc/file [jimc@frodo play]$ gcc/file gcc/file.c so its build-path relative (which u pretty much said), but I doubt its that simple either. I presume it is also controllable / customizable using one or more make variables or techniques. linux/Makefile's $srctree variable looks to be involved Perhaps this is (one more reason) why (shell-descent) recursive makes are less than desirable ? In any case I added a printk("__FILE__: %s\n", __FILE__) to see for myself, and you are correct. So I feel compelled to offer a fix for dynamic_debug, attached. hopefully it explains adequately, I have some doubts.. maybe this should go to LKML now, but I guess Id prefer to make my obvious thinkos less publicly. Im happy to bikeshed the commit-msg or code.
On Thu, 05 Sep 2019 08:31:55 -0600, jim.cromie@gmail.com said:
So I feel compelled to offer a fix for dynamic_debug, attached. hopefully it explains adequately, I have some doubts..
maybe this should go to LKML now, but I guess Id prefer to make my obvious thinkos less publicly. Im happy to bikeshed the commit-msg or code.
You should find a way to test that this is TRTTD for all gcc releases still supported for building a kernel (which may mean finding a 4.8 or 4.9 to test on to see if it uses relative or full paths). Removing these functions for kernels built with pre-change gcc will cause some semantic changes. Probably the *right* thing to do is to figure out what release it was changed in, and do some hacking to include/config/compiler-gcc.h. In addition, any such patches should be at least non-hostile to the ongoing effort to get a kernel tree that builds with clang rather than gcc.
On Wed, Sep 04, 2019 at 03:42:01PM -0600, jim.cromie@gmail.com wrote:
in the kernel, there are a lot of usages of __FILE__
And almost all of them should go away, I think checkpatch.pl will mention something like that. I know I will gladly take patches that fix up printk messages that have __FILE__ in them to use the correct macros instead for portions of the kernel that I maintain. thanks, greg k-h
participants (4)
-
Greg KH -
jim.cromie＠gmail.com -
Valdis Klētnieks -
Varun Iyer