------- Comment #11 from malitzke at metronets dot com 2006-06-15 03:03 ------- Hans-Peter!
Thanks for shedding _some_ light on this murky corner. Perhaps, the "i" constraint is now really inapropriate. First of all, a kernel header appropriately replaces __FUNCTION__ with __func__. Therefore the leftover __FUNCTION__ (probably from non GCC compilers) is not an issue. Second, __LINE__, __FILE__, and __func__ are all known to the compiler, because the compiler definitely knows what __FILE__ it is compiling and just emits the appropriate string. Same argument line pertains to the __LINE__ in the __FILE__ and the name of the __func__ (function) it is trying to compile. The whole idea is akin to an "assert". Therefore it is not up to the linker or assembler. Third, if putting __FILE__ in place of the of either __FUNCTION__ or __func__ it works fine as can be seen in the "-S option" output (e.g. file.s). Fourth, and this might be mine and others misunderstanding, I had thought that "i" really referred to the assembly file address of the string. This address, naturally is an address subject to relocation by the linker. To an _old_ assembly language programmer this appears just like a storm in a waterglass. This particular __asm construct is only used for powerpc (and perhaps ppc) It must be left as a holdover for the original AIX compiler or AIX binutils. In my bugzilla PR to kernel.org I pointed out that knowing the __FILE__ and __LINE__ is really quite sufficient and that perhaps, according to my patch to asm-powerpc/bug.h the particular item could be dropped. See bugzilla.kernel.org PR 6533. They have not taken it up as it only pertains to gcc-4.2.0 (experimental) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27528
