On 9/7/21 9:55 PM, Linus Torvalds wrote:
On Tue, Sep 7, 2021 at 9:28 PM Guenter Roeck <linux@xxxxxxxxxxxx> wrote:
It is seen with gcc 11.x whenever a memXXX or strXXX function parameter
is a pointer to a fixed address.
I wonder why I don't see it with gcc 11.2 here on x86-64.
I see the problem only on some architectures. No idea what triggers it,
but it is definitely architecture dependent.
gcc is happy if "(void *) 0xfffc1f2c"
is passed to a global function which does nothing but return the address,
such as:
void *sanitize_address(void *address)
{
return address;
}
We have had reasons to do things like that before for somewhat similar
(well, opposite) reasons - trying to disassociate some pointer from
its originating symbol type.
Look at RELOC_HIDE().
It might be worth it having something similar for "absolute_pointer()".
Entirely untested "written-in-the-MUA" garbage:
#define absolute_pointer(val) \
({ void *__res; __asm__("":"=r" (__res):"0" ((unsigned
long)(val))); __res; })
or:
#define absolute_pointer(val) RELOC_HIDE(val, 0)
or maybe:
#define absolute_pointer(val) RELOC_HIDE((void *)val, 0)
would do the same (though the first variant needs a pointer as argument).
All of those compile.
I tested the first and the last option on qemu:parisc and confirmed that
both work as expected.
I'd be happy to send a formal patch. Which one do you prefer, and where
should I put it ?
Thanks,
Guenter