[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v6 1/3] xen/arm: add support for run_in_exception_handler()

Hi Jan,

On 21/01/2021 10:06, Jan Beulich wrote:
On 21.01.2021 10:50, Julien Grall wrote:
Hi Jan,

On 21/01/2021 07:55, Jan Beulich wrote:
On 20.01.2021 19:20, Julien Grall wrote:
On 16/01/2021 10:33, Juergen Gross wrote:
Add support to run a function in an exception handler for Arm. Do it
as on x86 via a bug_frame, but pass the function pointer via a
register (this needs to be done that way, because inline asm support
for 32-bit Arm lacks the needed functionality to reference an
arbitrary function via the bugframe).

I was going to commit the series, but then realized the commit message
and comment needs some tweaking because technically GCC is supporting
'i' (I managed to get it working with -fno-pie).

So how about:

"This is needed to be done that way because GCC complains about invalid
constraint when using a function pointer with "i" and PIE is enabled
(default on most of GCC shipped with distro). Clang happily accepts it,
so it may be a bug in GCC."

May I ask why you think it's a bug in gcc? I'd rather consider it
a bug in clang. Taking the address of a symbol doesn't yield a
constant in PIC or PIE code, aiui.

I consider it a bug because we were using it as:

.pushsection .bug.frame
.long (%0 - 2b)

So I expect the compiler to be able to find the displacement in both
cases as we don't need to know the exact address.

I think Clang is just clever enough to figure out we want a displacement.

If they take apart the contents of the asm(), this may be possible,
yes. (Did you try with -no-integrated-as, btw?).

Clang will be able to build the code with and without -no-integrated-as. The dump of the structure will show that the address of the function will be stored (I used this small snippet [1]).


Do you have a suggestion of constraint that could resolve the issue?

No. Don't use -fpie (but I guess that's not an option for other

Yes, we need to have Xen code relocatable for at least UEFI. In the future we will need to be able to change at runtime the Xen virtual address in order to address memory issues (we can't switch page-tables with MMU enabled).

Linux Arm64 supports KASLR, yet, they are building with -fno-pie. I need to figure out how they deal with relocating the kernel and see if we can re-use it in Xen.

I have revised the comment to not suggest this is a bug and commit the series.



int test(void)
        return 0;

int main(void)
    asm volatile (".pushsection .bug_frames, \"aw\"\n"
              ".quad %0\n"
              :: "i"(test));

    return 0;

Julien Grall



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.