Bug 1967482

"invalid operand in inline asm" type errors tend to be consequences of compiler optimizations fighting with the STAP_SDT_ARG_CONSTRAINT parameter for governing the inline-assembler operands.  These tend not to be bugs either in llvm, the instrumented application, nor in systemtap, but just an unlucky integration difficulty.

See /usr/include/sys/sdt.h for a brief blurb on the phenomenon.  Consider a #define'ing a different STAP_SDT_ARG_CONSTRAINT.

It seems to work indeed if I set STAP_SDT_ARG_CONSTRAINT to either "nr" or "r" instead of "nor", so seems like Clang does not like the "o" constraint on ppc64.

Now I don't think it makes sense to clutter userspace programs with STAP_SDT_ARG_CONSTRAINT depending on the architecture and compiler that is getting used.
So how could we proceed here in a more generic way? Should this BZ get re-assigned to the clang component, so they could fix the problem with the "o" constraint? Or would it make more sense to include a "#if defined(__clang__) && defined(__ppc64__)" section in sys/sdt.h to define a differnt default value for STAP_SDT_ARG_CONSTRAINT in that case?

(In reply to Thomas Huth from comment #2)
> It seems to work indeed if I set STAP_SDT_ARG_CONSTRAINT to either "nr" or
> "r" instead of "nor", so seems like Clang does not like the "o" constraint
> on ppc64.

Doesn't like it as in doesn't support it at all, or that particular point of code with that particular constraint generates an error?  Note that on __powerpc__, the sys/sdt.h file uses nZr as the default (line 100ish).

> Now I don't think it makes sense to clutter userspace programs with
> STAP_SDT_ARG_CONSTRAINT depending on the architecture and compiler that is
> getting used.

The problem is that the constraints represent a tradeoff that systemtap is not well positioned to impose.  An "r" constraint forces the compiler to load all the parameters into registers, even if they didn't otherwise need to be there.  That means increasing register pressure, which if in some tight loop could hit performance.  For a given region of code, there might simply not be enough free registers, and we get an error anyway.

This parameter gives developers some power to choose, and the occasional necessity.

(In reply to Frank Ch. Eigler from comment #4)
> Doesn't like it as in doesn't support it at all, or that particular point of
> code with that particular constraint generates an error?  Note that on
> __powerpc__, the sys/sdt.h file uses nZr as the default (line 100ish).
[...]
> This parameter gives developers some power to choose, and the occasional
> necessity.

The code works perfectly fine when using gcc on that ppc64le machine. So I think the constraint should normally not be an issue here. It's just that Clang does not like it at all...

If "nZr" is not acceptable to powerpc clang, that would seem to be an outright gcc incompatibility that maybe they should fix.

Does someone have a reduced test case with the failing inline asm statement?

(In reply to Tom Stellard from comment #7)
> Does someone have a reduced test case with the failing inline asm statement?

If I preprocess the above example and strip down the result to the bare minimum, I end up with:

void func(int myarg)
{
    asm volatile(" .asciz \"%n[S1]@%I[A1]%[A1]\" "
                 :: [S1] "n" (1), [A1] "nZr" ((myarg)));
}

int main(int argc, char **argv)
{
    func(0);
    return 0;
}

... which still compiles fine with gcc on ppc64le and still produces the "invalid operand in inline asm" with clang.

Bumping to ITM25 to gain more space for dealing with some issues that appeared in llvm-toolset gating.

Verified with llvm-toolset-rhel8-8050020210806062652.b4937e53, llvm-toolset-12.0.1-1.module+el8.5.0+11871+08d0eab5.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (llvm-toolset:rhel8 bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2021:4233