Hello, first time poster so apologies if I posted to the wrong list.
Anyone knows why the SPARC makefiles (arch/sparc/Makefile and
arch/sparc/vdso/Makefile) set `-fcall-used-g5` and `-fcall-used-g7`
in their CFLAGS?
Would it be safe if the kernel is compiled without those flags?
The context is that there's an effort to make the sparc64 kernel build
under LLVM/clang, and if possible we'd like to build the kernel without
those flags, at least when building with clang, since it simplifies
a lot of things on the LLVM side.
(LLVM tracker: https://github.com/llvm/llvm-project/issues/40792)
Hi Koakuma,
On Sat, Mar 16, 2024 at 02:59:42PM +0000, Koakuma wrote:
> Hello, first time poster so apologies if I posted to the wrong list.
>
> Anyone knows why the SPARC makefiles (arch/sparc/Makefile and
> arch/sparc/vdso/Makefile) set `-fcall-used-g5` and `-fcall-used-g7`
> in their CFLAGS?
sparc32 uses:
-fcall-used-g5 -fcall-used-g7
sparc64 uses:
-ffixed-g4 -ffixed-g5 -fcall-used-g7
For sparc64:
-ffixed-g4 is added because sparc64 uses the g4 register to hold the
pointer to the current task. See:
arch/sparc/include/asm/current.h line 18.
g2, g5, g7 all have their specific use or assumptions.
From arch/sparc/include/asm/ttable.h:
* Further note that we cannot use the g2, g4, g5, and g7 alternate
* globals in the spill routines, check out the save instruction in
* arch/sparc64/kernel/etrap.S to see what I mean about g2, and
* g4/g5 are the globals which are preserved by etrap processing
* for the caller of it. The g7 register is the return pc for
* etrap. Finally, g6 is the current thread register so we cannot
* us it in the spill handlers either. Most of these rules do not
* apply to fill processing, only g6 is not usable.
*/
Looking at https://github.com/gcc-mirror/gcc/blob/master/gcc/config/sparc/sparc.h
I read that:
On v9 systems:
g1,g5 are free to use as temporaries, and are free to use between calls
...
g6-g7 are reserved for the operating system (or application in
embedded case).
Based on the above I would assume gcc do not change behaviour with or
without -fcall-used-g7.
I do not have a sparc64 system at my hands - and for this qemu may not
cut it. But it would be super if someone with a working sparc64 target
could verify if the kernel could be built and works without
-fcall-used-g7.
For sparc32 the above file says:
g5 through g7 are reserved for the operating system.
So again - it looks like -fcall-used-g5 -fcall-used-g7 should have no
effect here and verification on a real target would be nice.
Sam
Hello Sam,
Sam Ravnborg <[email protected]> wrote:
> Hi Koakuma,
> Looking at https://github.com/gcc-mirror/gcc/blob/master/gcc/config/sparc/sparc.h
> I read that:
>
> On v9 systems:
> g1,g5 are free to use as temporaries, and are free to use between calls
> ...
> g6-g7 are reserved for the operating system (or application in
> embedded case).
>
> Based on the above I would assume gcc do not change behaviour with or
> without -fcall-used-g7.
> [...]
> For sparc32 the above file says:
>
> g5 through g7 are reserved for the operating system.
>
> So again - it looks like -fcall-used-g5 -fcall-used-g7 should have no
> effect here and verification on a real target would be nice.
>
> Sam
From my understanding (and looking at the codegen results) those flags
forces GCC to treat the named register as volatile, despite what the ABI
says. However, I also believe that removing them wouldn't be harmful?
To quote my reasoning in the LLVM tracker:
> omitting the flags shouldn't be harmful either - compilers will now
> simply refuse to touch them, and any assembly code that happens
> to touch them would still work like usual (because Linux' conventions
> already treats them as volatile anyway).
But I am not entirely sure about it, that is why it'd be great if there's
some explaination on why those flags were added in the first place.
> I do not have a sparc64 system at my hands - and for this qemu may not
> cut it. But it would be super if someone with a working sparc64 target
> could verify if the kernel could be built and works without
> -fcall-used-g7.
I am currently running a build with those flags taken out on a T5120,
and the kernel seems to be running okay for what I do (LLVM development),
but I don't know if there are more comprehensive test suite for me
to try on.
Hi Koakuma.
On Sat, Mar 23, 2024 at 04:37:27PM +0000, Koakuma wrote:
> Hello Sam,
>
> Sam Ravnborg <[email protected]> wrote:
>
> > Hi Koakuma,
> > Looking at https://github.com/gcc-mirror/gcc/blob/master/gcc/config/sparc/sparc.h
> > I read that:
> >
> > On v9 systems:
> > g1,g5 are free to use as temporaries, and are free to use between calls
> > ...
> > g6-g7 are reserved for the operating system (or application in
> > embedded case).
> >
> > Based on the above I would assume gcc do not change behaviour with or
> > without -fcall-used-g7.
> > [...]
> > For sparc32 the above file says:
> >
> > g5 through g7 are reserved for the operating system.
> >
> > So again - it looks like -fcall-used-g5 -fcall-used-g7 should have no
> > effect here and verification on a real target would be nice.
> >
> > Sam
>
> >From my understanding (and looking at the codegen results) those flags
> forces GCC to treat the named register as volatile, despite what the ABI
> says. However, I also believe that removing them wouldn't be harmful?
>
> To quote my reasoning in the LLVM tracker:
> > omitting the flags shouldn't be harmful either - compilers will now
> > simply refuse to touch them, and any assembly code that happens
> > to touch them would still work like usual (because Linux' conventions
> > already treats them as volatile anyway).
>
> But I am not entirely sure about it, that is why it'd be great if there's
> some explaination on why those flags were added in the first place.
>
> > I do not have a sparc64 system at my hands - and for this qemu may not
> > cut it. But it would be super if someone with a working sparc64 target
> > could verify if the kernel could be built and works without
> > -fcall-used-g7.
>
> I am currently running a build with those flags taken out on a T5120,
> and the kernel seems to be running okay for what I do (LLVM development),
> but I don't know if there are more comprehensive test suite for me
> to try on.
I tried to build a sparc32 kernel with the two -fcall-used-g5 -fcall-used-g7
flags dropped. Everything worked for me in qemu - but then I only booted
to a prompt and browsed around a little.
From your explanation and our limited testing it seems likely the flags
can be dropped, but I cannot say for sure.
Unless others chime in maybe try to send in patches to drop the flags
from sparc32 and sparc64 and see how it goes.
Sam