Re: [RFC] Linux system call builtins
On 08-04-24 09:19, Matheus Afonso Martins Moreira via Gcc wrote: + It's becoming common Despite being specific to the Linux kernel, support for it is showing up in other systems. FreeBSD implements limited support[4] for Linux ABIs. Windows Subsystem for Linux started out[5] similarly, as an implementation of this system call ABI. Apparently it's becoming something of a lingua franca. Maybe one day Linux programs will actually become portable by virtue of this stable binary interface. I don't really buy your portability argument. FreeBSD implements this as a syscall (two actually). syscall 0: int syscall(int number, ...); syscall 198: int __syscall(int64_t number, ...); (I've never seen the second one used in anger, it's supposed to be for systems that have unusual argument padding). The argument shuffling gets done in the kernel, not libc. In fact FreeBSD 15 just moved all syscall wrappers to a separate library, libsys, so it's there now. Over in OpenBSD they are going to removing 'syscall' from libc. https://lwn.net/Articles/949078/ From what I've seen it has also been removed by Apple. Whilst you aren't proposing the same thing, I see systems making it more difficult for code to make syscalls, not easier. I also think that this could be misleading. There are sometimes subtle differences between the syscall interface and the interface exported by libc. A+ Paul
Re: Sourceware mitigating and preventing the next xz-backdoor
On 03-04-24 14:32, Martin Uecker via Gcc wrote: The backdoor was hidden in a complicated autoconf script... How many uncomplicated autoconf scripts exist in the real world? A+ Paul
Re: Safe transposition of logical and operands
On 18-09-23 22:52, Martin Uecker wrote: Is the problem that valgrind transforms the code before it then emulates it and the problem is that during emulation the code could trap? Yes, roughly the process is guest ISA -> IR -> IR transformations -> IR optimizations -> execution The && "idiom recovery" is getting filtered out during the IR transformations. A+ Paul
Re: Safe transposition of logical and operands
On 18-09-23 21:09, Martin Uecker wrote: I do not understand why memcheck cares about the potential trap when deciding to do the backwards transformation that combines the two comparisons? Can't you just remove this condition? I assume it is meant as a filter to only transform cases which really come from an '&&' condition in the source, but as this example show, this is too strict. Or am I missing something? My understanding is that this is a generic transformation of if (a && b) [which might have been transposed from if (b && a)] into if (a & b) [with appropriate extension to the right size]. That means both get evaluated and we can't take that risk that one of them traps. A+ Paul
Re: Safe transposition of logical and operands
On 18-09-23 16:55, Richard Biener wrote: What you could do is report the access only on the point of use of the accessed value? (and disregard when the register holding the value is re-used) Hi Richard Not sure that I follow what you're saying. memcheck triggers errors like this at conditional branching opcodes where it determines that the condition is undefined. There are mechanisms to de-duplicate errors, so once an error is emitted it won't be printed again. However, one of our goals is no false positives. This is one example that is slipping through the cracks. Regards Paul
Re: Safe transposition of logical and operands
On 17-09-23 22:51, Jonathan Wakely wrote: Why would it be trapping? It's loading an int64_t, which might be uninitialised but it can't trap. In this context I think that Valgrind is considering that any memory load could trap. *f on a std::optional is not like dereferencing a pointer, the int64_t memory location is always present as part of the object. For this movq40(%rbx), %rax unless you know that what RBX+40 is pointing to is safe to dereference it's not different to dereferencing a pointer. So I think that the problem is that Valgrind is being cautious and not allowing any loads but GCC is accepting what it considers safe loads from the stack. A+ Paul
Safe transposition of logical and operands
Hi
I'm looking at a Valgrind issue. Full details here
https://bugs.kde.org/show_bug.cgi?id=472329
This code
void foo(std::optional f) {
std::cout << (f ? *f : 0) << std::endl;
std::set test;
test.emplace(0);
auto it{test.begin()};
while (it != test.end()) {
int64_t b{*it};
// Valgrind error on next line
if (f && *f != b) {
[snip]
int main() { foo(std::nullopt); }
generates (using g++ 12.2 on FreeBSD 13.2 amd64)
movq40(%rbx), %rax
Error on next line:
cmpq%r14, %rax # f, SR.252
je .L47
cmpb$0, -97(%rbp) #, %sfp
jne .L69
Unless I'm completely mistaken cmpq %r14, %rax is the quadword
comparison of *f != b and cmpb $0, -97(%rbp) is the
std::optional::operator bool() comparison with 0. That means that g++
has transposed the order of evaluation.
The first cmpq/je generates a
==49599== Conditional jump or move depends on uninitialised value(s)
Valgrind has machinery to detect transformations like this and to
convert them back into bit accurate bitwise ands.
However, Valgrind thinks that these transpositions can't be done when
there are potentially trapping memory loads like *f.
So who is right? Is this a safe transformation?
Regards
Paul
Re: distinguishing gcc compilation valgrind false positives
Hi the main reason why it looks like a false positive is that I've had these valgrind warnings ... since probably ever, but it was never causing issues. I cannot tell from the sources if there is anything wrong, so I am better asking here. Well, that's the nature of undefined behaviour. Undefined doesn't mean that it is non-deterministic. And if you really do find false positives (which is always possible, especially with new compiler releases) then please report them to us at https://bugs.kde.org/enter_bug.cgi?product=valgrind A+ Paul
Re: distinguishing gcc compilation valgrind false positives
On 24/11/2021 20:05, Zdenek Sojka via Gcc wrote: Hello, from time to time, I come upon a testcase that failed during the automated runs, but passes during reduction; there are valgrind warnings present, however. How do I distinguish what warnings are valid and which are false positives? Is there any way gcc could prevent generating the false positives? What makes you think that any are false positives? Memcheck generally has a low false positive rate (though I am little biased). You need to read the source and decide based on that. A+ Paul
