Alberto Bertogli wrote:

I'll try to get a debian install to boot for armhf, but it'll take me a
bit because it's not straightforward (to put it mildly :).

Oh, yeah. :/ Perhaps qemu might be better option here. There might
even be pre-built disk images flying around.

How urgent/important is this issue?

Medium? As it is technically a regression (as in, armhf used to build
before), this was filed with a severity of "serious". What this means
in practical terms is that newer versions of libfiu we upload will not
migrate to the staging area for the next release of Debian.


Regards,

--
,''`.
: :' : Chris Lamb
`. `'` lamby@debian.org 🍥 chris-lamb.co.uk
`-

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, Mar 24, 2024 at 06:00:51PM +0000, Chris Lamb wrote:

Alberto Bertogli wrote:

I'll try to get a debian install to boot for armhf, but it'll take me a
bit because it's not straightforward (to put it mildly :).

Oh, yeah. :/ Perhaps qemu might be better option here. There might
even be pre-built disk images flying around.

Sorry, yes that's what I meant! To install it under qemu!

Unfortunately, I haven't been able to get it to work.

I managed to get bookworm installed, and then extracted the
kernel+initrd from inside the virtual disk (as apparently that's
needed), but the kernel won't boot due to: `Unhandled fault: synchronous
abort (translation table walk)`.

At this point I'm not really keen on debugging whatever that armhf
kernel issue is :(

If you know of a functional official image that I can use to try to
reproduce the problem, or recently-tested steps I can follow to get a
working qemu install, please let me know.

Thanks,
Alberto

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, Apr 20, 2024 at 12:00:00AM +0200, Santiago Vila wrote:

El 25/3/24 a las 20:12, Chris Lamb escribió:

Alberto Bertogli wrote:

If you know of a functional official image that I can use to try to >>>reproduce the problem, or recently-tested steps I can follow to get
a working qemu install, please let me know.

Alas, I can't actually be helpful here. There are no official images
as far as I know… and somewhat annoyingly I (ie. a Debian Developer) >>actually have access to some machines set aside for this purpose. I
call this "annoying" because I naturally can't then give you direct
SSH access transitively — but I can proxy ideas, of course.

Hi.

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.

Thank you!
Alberto

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, Apr 28, 2024 at 01:02:26PM +0100, Alberto Bertogli wrote:

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.

More things that make this interesting.

This program:

```
#include <stdio.h>
#include <unistd.h>
#include <dlfcn.h>

int main() {
printf("pread: %p\n", pread);
printf("pread64: %p\n", pread64);
printf("pread64 is pread: %b\n", pread == pread64);

void *lib = dlopen(NULL, RTLD_NOW);
void *l_pread = dlsym(lib, "pread");
void *l_pread64 = dlsym(lib, "pread64");

printf("l_pread: %p\n", l_pread);
printf("l_pread64: %p\n", l_pread64);
printf("l_pread64 is l_pread: %b\n", l_pread == l_pread64);
}
```

Built with:
cc -save-temps=obj -D_XOPEN_SOURCE=600 -D_LARGEFILE64_SOURCE=1 -std=c99 -Wall demo.c

Prints this on x86_64 Debian testing (which does not show this bug):

```
pread: 0x7fc1970f0c10
pread64: 0x7fc1970f0c10
pread64 is pread: 1
l_pread: 0x7fc1970f0c10
l_pread64: 0x7fc1970f0c10
l_pread64 is l_pread: 1
```

And prints this on the armel chroot:

```
pread: 0xf7da6a90
pread64: 0xf7da6a90
pread64 is pread: 1
l_pread: 0xf7da68f8
l_pread64: 0xf7da6a90
l_pread64 is l_pread: 0
```

So on x86_64 both pread() and pread64() are the same function, yet the
headers allow us to declare them individually.

But on armel, even though there is a separate implementation of pread()
on libc, the headers prevent us from declaring them separately (because
of the asm name declaration in unistd.h).

Just putting this here in case it helps someone else debug a similar
problem in the future.

I'm still trying to find a reasonable workaround.

Thanks,
Alberto

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)