On Sat, Apr 20, 2024 at 10:30:20AM +0100, Alberto Bertogli wrote:
On Sat, Apr 20, 2024 at 12:00:00AM +0200, Santiago Vila wrote:
I can't offer ssh access either (for now), but I've checked and
this error may be reproduced easily on an arm64 machine using an
armel chroot.
Oohhh this is good to know, I didn't know that was a viable option.
Thank you for the suggestion!
I will try to reproduce it this way, I'll let you know how it goes.
I managed to reproduce this the way you suggested, on a Hetzner VM and
an armel chroot.
The problem seems to be that some of the functions that have 64-bit
variants (e.g. pread64, pwrite64) have an assembler name declared for
the regular variant in the header; while other platforms don't do that
and have the two functions declared separately.
https://gcc.gnu.org/onlinedocs/gcc/Asm-Labels.html
For example, this is the declaration of pread and pwrite in a
post-preprocessed file, diff between x86_64 (without the bug, '-') and
armel (with the bug, '+'):
```
@@ -1068,18 +1111,14 @@
extern ssize_t write (int __fd, const void *__buf, size_t __n)
__attribute__ ((__access__ (__read_only__, 2, 3)));
-# 389 "/usr/include/unistd.h" 3 4
-extern ssize_t pread (int __fd, void *__buf, size_t __nbytes,
- __off_t __offset)
- __attribute__ ((__access__ (__write_only__, 2, 3)));
-
-
+# 404 "/usr/include/unistd.h" 3 4
+extern ssize_t pread (int __fd, void *__buf, size_t __nbytes, __off64_t __offset) __asm__
("" "pread64")
+ __attribute__ ((__access__ (__write_only__, 2, 3)));
+extern ssize_t pwrite (int __fd, const void *__buf, size_t __nbytes, __off64_t __offset) __asm__
("" "pwrite64")
-extern ssize_t pwrite (int __fd, const void *__buf, size_t __n,
- __off_t __offset)
__attribute__ ((__access__ (__read_only__, 2, 3)));
# 422 "/usr/include/unistd.h" 3 4
extern ssize_t pread64 (int __fd, void *__buf, size_t __nbytes,
```
That's why it's the assembler (and not linking) stage that's
complaining, because that means both functions end up named as the
64-bit variant. This can be seen in the assembly file. Continuing to use
pread/pread64 as an example, there is no definition for pread(), only
pread64() twice: once for pread and one for pread64.
It's tricky to support this in a generic way, because it's difficult to
detect this is even happening, as the assembler name operates at a
compiler level so we can't just undo it.
I'll keep trying to find a viable workaround for this.
Thanks,
Alberto
