[ARCHS]: glibc testsuite fails with vanilla Linux kernels

[pavelvkozlov]

I see the problem with vanilla Linux kernels running on QEMU (ARCv2). I'm running glibc test suit and see the following fails (the system continues to run, just terminates running processes):

Generating locale cy_GB.UTF-8: this might take a while...
Generating locale da_DK.ISO-8859-1: this might take a while...
corrupted double-linked list
Charmap: "ISO-8859-1" Inputfile: "da_DK" Outputdir: "da_DK.ISO-8859-1" failed
Generating locale de_DE.ISO-8859-1: this might take a while...
[error] character L'\u0001d792' in class `upper' must be in class `alpha'
[error] character L'\u0001d793' in class `upper' must be in class `alpha'

I've not seen such issue on HSDK board and nSIM. I can't provide you with small test, but I've found that the following patch from the foss-for-synopsys-dwc-arc-processors Linux kernel fork fixes this issue: https://github.com/foss-for-synopsys-dwc-arc-processors/linux/commit/e297cf5aaad6a03ea376e3e50e4f49b90c1f7763 In this patch extra code to re-enable MMU has been moved from the MachineCheck exception handler to the flush_tlb_range() function. According to the PRM for ARC HS3x processors the MachineCheck exception can reset MMU enable bit, but only the MachineCheck exception and this change should not significantly affect. I don't see MachineCheck exceptions. I see that the flush_tlb_range() function is called periodically and code that enable MMU in the flush_tlb_range() elliminated this issue.

This issue does not allow to use QEMU in glibc verification with latest versions of pure Linux kernel.

This symptom looks like some issue in QEMU. Please take a look. Can we do something with this from the QEMU side?

[kolerov]

This error may be reproduced only if you use glibc from the upstream repository (https://github.com/bminor/glibc). For example, if you'll try to build a Linux image using Buildroot and let him to build a toolchain by itself, then glibc from the upstream repository will be fetched.

The problem is in faulty commit https://github.com/bminor/glibc/commit/0849eed45d which was fixed in another commit https://github.com/bminor/glibc/commit/6a734e62f1557de3449c689effd2b37066ea34eb just several days ago. In short - arguments for sysmalloc_mmap_fallback are passed incorrectly.

Why this error happens only in QEMU but no in nSIM or HSDK? As far as I know, sysmalloc_mmap_fallback is used only when memory allocation using sbrk or brk is failed. This function tries to use mmap. Calling of this function is a rare event and depends on platform's properties and layout of the memory. So, this bug could appear in nSIM and HSDK too under certain conditions.

Another problem is that glibc package in the latest Buildroot uses glibc revision without this patch and the latest release of glibc does not include this patch yet (seems like it will be in 2.38). So, what can we do:

1. Add a temporary patch to https://github.com/foss-for-synopsys-dwc-arc-processors/buildroot. However, this patch cannot be applied to glibc if arc64 branch of glibc is used (it's selected if ARCv3 is used for building Linux).
2. Use only arc64 branch for glibc in https://github.com/foss-for-synopsys-dwc-arc-processors/buildroot.

[pavelvkozlov]

@kolerov, thanks for your recommendations. I've added (cherry-pick) mentioned commit to our arc-2023.03 branch glibc: https://github.com/foss-for-synopsys-dwc-arc-processors/glibc/commit/f15cc27a55506ceaaf17f3d7ec28fde87049827a. As expected, without this commit arc-2023.03 branch glibc causes described issue too.

[kolerov]

@pavelvkozlov Could you confirm that this issue is eliminated in the latest release and it may be closed?