On 15.02.2024 11:07, Federico Serafini wrote:
> On 15/02/24 09:10, Jan Beulich wrote:
>> On 14.02.2024 17:11, Federico Serafini wrote:
>>> I did some tries with example programs
>>> and the assembler error always points to file and line
>>> of the most enclosing function that caused the failure.
>>> If I am not missing something, using __FILE__ and __LINE__ does not add
>>> any information.
>>>
>>> Therefore, if the new macro is used within the body of other macros,
>>> then the resulting assembler error will point to the source of
>>> the problem (e.g., the site of a bogus call to put_guest()).
>>>
>>> In my opinion, converting put_guest() &Co. to inline functions is not
>>> convenient: the assembler error will point to the most enclosing
>>> function that would be put_unsafe_size(), instead of pointing to the
>>> source of the problem.
>>
>> The assembler error will point to where the inline function was expanded,
>> sure. __FILE__ / __LINE__ ought to point to that inline function (where
>> the macro was used) then, though?
>
> This is what I get:
>
> federico@Dell:~$ cat m.c
> #define STRINGIFY(arg) #arg
> #define STATIC_ASSERT_UNREACHABLE(file, line) \
> asm(".error \"static assertion failed: " file ": " STRINGIFY(line) "\"")
__FILE__ / __LINE__, if to be used, want using here, not at the use
site.
> static inline __attribute__((always_inline)) void g(int x) {
> switch(x) {
> case 0:
> STATIC_ASSERT_UNREACHABLE(__FILE__, __LINE__);
> }
> }
>
> static inline __attribute__((always_inline)) void f(int x) {
> g(x);
> }
>
> int main(void) {
> f(0);
> return 0;
> }
> federico@Dell:~$ gcc -O3 m.c
> m.c: Assembler messages:
> m.c:8: Error: static assertion failed: m.c: 8
That's as expected. There's no mix of macros and inline functions in
your example.
> Note that the linker behaves differently:
>
> federico@Dell:~$ cat m.c
> extern void __put_user_bad(void);
>
> static inline __attribute__((always_inline)) void g(int x) {
> switch(x) {
> case 0:
> __put_user_bad();
> }
> }
>
> static inline __attribute__((always_inline)) void f(int x) {
> g(x);
> }
>
> int main(void) {
> f(0);
> return 0;
> }
> federico@Dell:~$ gcc -O3 m.c
> /usr/bin/ld: /tmp/ccv9KHJD.o: in function `main':
> m.c:(.text.startup+0x9): undefined reference to `__put_user_bad'
> collect2: error: ld returned 1 exit status
The important difference is: Here we're told that there was a use of
__put_user_bad, which is easy to grep for, and thus see how the
supplied function / file / line(?) relate to the ultimate problem.
I'm afraid I'm meanwhile confused enough by the various replies
containing results of experimentation that I can't really tell
anymore what case is best. Hence I can only restate my expectation for
an eventual v3: Diagnosing what the issue is, no matter whether the new
macro is used in another macro or in an inline function, should not
become meaningfully more difficult. In how far this is the case wants
clarifying in the description of the change.
Jan
