about summary refs log tree commit diff
Commit message (Collapse)AuthorAgeFilesLines
* gmon: Fix allocated buffer overflow (bug 29444)Леонид Юрьев (Leonid Yuriev)2023-02-221-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The `__monstartup()` allocates a buffer used to store all the data accumulated by the monitor. The size of this buffer depends on the size of the internal structures used and the address range for which the monitor is activated, as well as on the maximum density of call instructions and/or callable functions that could be potentially on a segment of executable code. In particular a hash table of arcs is placed at the end of this buffer. The size of this hash table is calculated in bytes as p->fromssize = p->textsize / HASHFRACTION; but actually should be p->fromssize = ROUNDUP(p->textsize / HASHFRACTION, sizeof(*p->froms)); This results in writing beyond the end of the allocated buffer when an added arc corresponds to a call near from the end of the monitored address range, since `_mcount()` check the incoming caller address for monitored range but not the intermediate result hash-like index that uses to write into the table. It should be noted that when the results are output to `gmon.out`, the table is read to the last element calculated from the allocated size in bytes, so the arcs stored outside the buffer boundary did not fall into `gprof` for analysis. Thus this "feature" help me to found this bug during working with https://sourceware.org/bugzilla/show_bug.cgi?id=29438 Just in case, I will explicitly note that the problem breaks the `make test t=gmon/tst-gmon-dso` added for Bug 29438. There, the arc of the `f3()` call disappears from the output, since in the DSO case, the call to `f3` is located close to the end of the monitored range. Signed-off-by: Леонид Юрьев (Leonid Yuriev) <leo@yuriev.ru> Another minor error seems a related typo in the calculation of `kcountsize`, but since kcounts are smaller than froms, this is actually to align the p->froms data. Co-authored-by: DJ Delorie <dj@redhat.com> Reviewed-by: Carlos O'Donell <carlos@redhat.com>
* malloc: remove redundant check of unsorted bin corruptionAyush Mittal2023-02-221-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | * malloc/malloc.c (_int_malloc): remove redundant check of unsorted bin corruption With commit "b90ddd08f6dd688e651df9ee89ca3a69ff88cd0c" (malloc: Additional checks for unsorted bin integrity), same check of (bck->fd != victim) is added before checking of unsorted chunk corruption, which was added in "bdc3009b8ff0effdbbfb05eb6b10966753cbf9b8" (Added check before removing from unsorted list). .. 3773 if (__glibc_unlikely (bck->fd != victim) 3774 || __glibc_unlikely (victim->fd != unsorted_chunks (av))) 3775 malloc_printerr ("malloc(): unsorted double linked list corrupted"); .. .. 3815 /* remove from unsorted list */ 3816 if (__glibc_unlikely (bck->fd != victim)) 3817 malloc_printerr ("malloc(): corrupted unsorted chunks 3"); 3818 unsorted_chunks (av)->bk = bck; .. So this extra check can be removed. Signed-off-by: Maninder Singh <maninder1.s@samsung.com> Signed-off-by: Ayush Mittal <ayush.m@samsung.com> Reviewed-by: DJ Delorie <dj@redhat.com>
* Use Linux 6.2 in build-many-glibcs.pyJoseph Myers2023-02-221-1/+1
| | | | | | | This patch makes build-many-glibcs.py use Linux 6.2. Tested with build-many-glibcs.py (host-libraries, compilers and glibcs builds).
* Ignore MAP_VARIABLE in tst-mman-consts.pyJoseph Myers2023-02-221-2/+5
| | | | | | | | | | | Linux 6.2 removed the hppa compatibility MAP_VARIABLE define. That means that, whether or not we remove it in glibc, it needs to be ignored in tst-mman-consts.py (since this macro comparison infrastructure expects that new kernel header versions only add new macros, not remove old ones). Tested with build-many-glibcs.py for hppa-linux-gnu (Linux 6.2 headers).
* AArch64: Fix HP_TIMING_DIFF computation [BZ# 29329]Jun Tang2023-02-221-1/+1
| | | | | | | | Fix the computation to allow for cntfrq_el0 being larger than 1GHz. Assume cntfrq_el0 is a multiple of 1MHz to increase the maximum interval (1024 seconds at 1GHz). Reviewed-by: Wilco Dijkstra <Wilco.Dijkstra@arm.com>
* s390: Fix build for -march=z13Adhemerval Zanella2023-02-202-0/+2
| | | | | | | | It fixes the build after 7ea510127e2067e and 22999b2f0fb62. Checked with build for s390x-linux-gnu with -march=z13. Reviewed-by: Arjun Shankar <arjun@redhat.com>
* arm: Support gcc older than 10 for find_zero_allAdhemerval Zanella2023-02-201-0/+6
| | | | | | | | __builtin_arm_uqsub8 is only available on gcc newer or equal than 10. Checked on arm-linux-gnueabihf built with gcc 9. Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
* Linux: Remove generic ImpliesAdhemerval Zanella2023-02-209-24/+0
| | | | | | | | | The default Linux implementation already handled the Linux generic ABIs interface used on newer architectures, so there is no need to Imply the generic any longer. Reviewed-by: Carlos O'Donell <carlos@redhat.com> Tested-by: Carlos O'Donell <carlos@redhat.com>
* Linux: Remove unused generic MakefileAdhemerval Zanella2023-02-201-3/+0
| | | | | | | Both are already defined on default linux Makefile. Reviewed-by: Carlos O'Donell <carlos@redhat.com> Tested-by: Carlos O'Donell <carlos@redhat.com>
* Linux: Assume and consolidate getpeername wire-up syscallAdhemerval Zanella2023-02-2010-28/+6
| | | | | | | | | And disable if kernel does not support it. Checked on x86_64-linux-gnu and i686-linux-gnu. Reviewed-by: Carlos O'Donell <carlos@redhat.com> Tested-by: Carlos O'Donell <carlos@redhat.com>
* Linux: Assume and consolidate getsockname wire-up syscallAdhemerval Zanella2023-02-2010-13/+11
| | | | | | | | | And disable if kernel does not support it. Checked on x86_64-linux-gnu and i686-linux-gnu. Reviewed-by: Carlos O'Donell <carlos@redhat.com> Tested-by: Carlos O'Donell <carlos@redhat.com>
* Linux: Move wordsize-32 Version to defaultAdhemerval Zanella2023-02-2012-38/+3
| | | | | | | | | | | | | | | | | And remove redundant entries on other architectures Version. The version for fallocate64 was supposed to be 2.10, but it was then added to 32-bit platforms in 2.11 because it mistakenly wasn't exported for them in 2.10 (see the commit message for 1f3615a1c97a030bca59f728f998947f852679b9). The linux/generic did not exist before 2.15, i.e. when the tile ports were added (and microblaze did not exist before 2.18), which explains those differences but also illustrates that "2.11 for 32-bit, 2.10 for 64-bit" should be sufficient since versions older than the minimum for the architecture are automatically adjusted. Reviewed-by: Carlos O'Donell <carlos@redhat.com> Tested-by: Carlos O'Donell <carlos@redhat.com>
* __glob64_time64: Fix typo for stub_warning call (BZ #30146)Samuel Thibault2023-02-201-1/+1
| | | | The exported symbol is actually __glob64_time64, not glob64_time64.
* elf: Restore ldconfig libc6 implicit soname logic [BZ #30125]Joan Bruguera2023-02-207-23/+67
| | | | | | | | | | | | | | | | | | | | | | While cleaning up old libc version support, the deprecated libc4 code was accidentally kept in `implicit_soname`, instead of the libc6 code. This causes additional symlinks to be created by `ldconfig` for libraries without a soname, e.g. a library `libsomething.123.456.789` without a soname will create a `libsomething.123` -> `libsomething.123.456.789` symlink. As the libc6 version of the `implicit_soname` code is a trivial `xstrdup`, just inline it and remove `implicit_soname` altogether. Some further simplification looks possible (e.g. the call to `create_links` looks like a no-op if `soname == NULL`, other than the verbose printfs), but logic is kept as-is for now. Fixes: BZ #30125 Fixes: 8ee878592c4a ("Assume only FLAG_ELF_LIBC6 suport") Signed-off-by: Joan Bruguera <joanbrugueram@gmail.com> Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* stdlib: Undo post review change to 16adc58e73f3 [BZ #27749]Vitaly Buka2023-02-203-2/+81
| | | | | | | | | | Post review removal of "goto restart" from https://sourceware.org/pipermail/libc-alpha/2021-April/125470.html introduced a bug when some atexit handers skipped. Signed-off-by: Vitaly Buka <vitalybuka@google.com> Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* Define PC, SP and SYSRETURN for hurd x86_64Flavio Cruz2023-02-201-3/+9
| | | | | | Moved thread_state.h to x86 directory since we only need to customize those 3 definitions. Message-Id: <Y+x4xrsDMkAomncO@jupiter.tail36e24.ts.net>
* mach: Use PAGE_SIZESergey Bugaev2023-02-201-1/+5
| | | | | | | | | | | | | | The PAGE_SIZE from the Mach headers statically defines the machine's page size. There's no need to query it dynamically; furthermore, the implementation of the vm_statistics () RPC unconditionally fills in pagesize = PAGE_SIZE; Not doing the extra RPC shaves off 2 RPCs from the start-up of every process! Signed-off-by: Sergey Bugaev <bugaevc@gmail.com> Message-Id: <20230218203717.373211-7-bugaevc@gmail.com>
* hurd: Simplify init-first.c a bitSergey Bugaev2023-02-201-16/+7
| | | | | | | | And make it a bit more 64-bit ready. This is in preparation to moving this file into x86/ Signed-off-by: Sergey Bugaev <bugaevc@gmail.com> Message-Id: <20230218203717.373211-6-bugaevc@gmail.com>
* hurd: Make timer_t pointer-sizedSergey Bugaev2023-02-201-1/+1
| | | | | | | | This ensures that a timer_t value can be cast to struct timer_node * and back. Signed-off-by: Sergey Bugaev <bugaevc@gmail.com> Message-Id: <20230218203717.373211-5-bugaevc@gmail.com>
* hurd: Fix xattr function return typeSergey Bugaev2023-02-205-5/+5
| | | | | | | They all return int, not size_t. Signed-off-by: Sergey Bugaev <bugaevc@gmail.com> Message-Id: <20230218203717.373211-4-bugaevc@gmail.com>
* hurd: Use proper integer typesSergey Bugaev2023-02-206-10/+14
| | | | | | | | Fix a few more cases of build errors caused by mismatched types. This is a continuation of f4315054b46d5e58b44a709a51943fb73f846afb. Signed-off-by: Sergey Bugaev <bugaevc@gmail.com> Message-Id: <20230218203717.373211-3-bugaevc@gmail.com>
* hurd: Move thread state manipulation into _hurd_tls_new ()Sergey Bugaev2023-02-202-21/+22
| | | | | | | This is going to be done differently on x86_64. Signed-off-by: Sergey Bugaev <bugaevc@gmail.com> Message-Id: <20230218203717.373211-2-bugaevc@gmail.com>
* glob64_time64: Fix typo for stub_warning call (BZ #30146)Samuel Thibault2023-02-191-1/+1
| | | | | We were erroneously reporting a stub warning for glob64 instead of glob64_time64.
* Use uintptr_t instead of performing pointer subtraction with a null pointerQihao Chencao2023-02-1712-36/+35
| | | | | | Signed-off-by: Qihao Chencao <twose@qq.com> Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* ARC:fpu: add extra capability check before use of sqrt and fma builtinsPavel Kozlov2023-02-172-4/+24
| | | | | | | | | | | | | | | | | | | | Add extra check for compiler definitions to ensure that compiler provides sqrt and fma hw fpu instructions else use software implementation. As divide/sqrt and FMA hw support from CPU side is optional, the compiler can be configured by options to generate hw FPU instructions, but without use of FDDIV, FDSQRT, FSDIV, FSSQRT, FDMADD and FSMADD instructions. In this case __builtin_sqrt and __builtin_sqrtf provided by compiler can't be used inside the glibc code, as these builtins are used in implementations of sqrt() and sqrtf() functions but at the same time these builtins unfold to sqrt() and sqrtf(). So it is possible to receive code like that: 0001c4b4 <__ieee754_sqrtf>: 1c4b4: 0001 0000 b 0 ;1c4b4 <__ieee754_sqrtf> The same is also true for __builtin_fma and __builtin_fmaf. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* ARC: align child stack in clonePavel Kozlov2023-02-171-0/+1
| | | | | | | | | | | The ARCv2 ABI requires 4 byte stack pointer alignment. Don't allow to use unaligned child stack in clone. As the stack grows down, align it down. This was pointed by misc/tst-misalign-clone-internal and misc/tst-misalign-clone tests. Stack alignmet fixes these tests fails. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* string: Remove string_private.hAdhemerval Zanella2023-02-176-105/+0
| | | | | | Now that _STRING_ARCH_unaligned is not used anymore. Reviewed-by: Wilco Dijkstra <Wilco.Dijkstra@arm.com>
* iconv: Remove _STRING_ARCH_unaligned usageAdhemerval Zanella2023-02-173-407/+59
| | | | | | | | | | Use put/get macros __builtin_bswap32 instead. It allows to remove the unaligned routines, the compiler will generate unaligned access if the ABI allows it. Checked on x86_64-linux-gnu and i686-linux-gnu. Reviewed-by: Wilco Dijkstra <Wilco.Dijkstra@arm.com>
* iconv: Remove _STRING_ARCH_unaligned usage for get/set macrosAdhemerval Zanella2023-02-1710-154/+42
| | | | | | | | | And use a packed structure instead. The compiler generates optimized unaligned code if the architecture supports it. Checked on x86_64-linux-gnu and i686-linux-gnu. Reviewed-by: Wilco Dijkstra <Wilco.Dijkstra@arm.com>
* resolv: Remove _STRING_ARCH_unaligned usageAdhemerval Zanella2023-02-171-36/+0
| | | | | | | | GCC with default implementation already generates optimized code. Checked on x86_64-linux-gnu and i686-linux-gnu. Reviewed-by: Wilco Dijkstra <Wilco.Dijkstra@arm.com>
* nscd: Remove _STRING_ARCH_unaligned usageAdhemerval Zanella2023-02-173-10/+0
| | | | | | | | | It only adds a small overhead for unaligned inputs (which should not be common) and unify the code. Checked on x86_64-linux-gnu and i686-linux-gnu. Reviewed-by: Wilco Dijkstra <Wilco.Dijkstra@arm.com>
* stdlib: Simplify getenvAdhemerval Zanella2023-02-171-59/+5
| | | | | | | | And remove _STRING_ARCH_unaligned usage. Checked on x86_64-linux-gnu and i686-linux-gnu. Reviewed-by: Wilco Dijkstra <Wilco.Dijkstra@arm.com>
* crypto: Remove _STRING_ARCH_unaligned usageAdhemerval Zanella2023-02-173-65/+13
| | | | | | | | | Assume unaligned inputs on all cases. The code is built and used only in compat mode. Checked on x86_64-linux-gnu and i686-linux-gnu. Reviewed-by: Wilco Dijkstra <Wilco.Dijkstra@arm.com>
* Fix ifunc-impl-list.c build for s390Joseph Myers2023-02-171-1/+1
| | | | | | | | | | | | | | | | | | | | | | Builds for s390 recently started failing with: ../sysdeps/s390/multiarch/ifunc-impl-list.c: In function '__libc_ifunc_impl_list': ../sysdeps/s390/multiarch/ifunc-impl-list.c:83:21: error: unused variable 'dl_hwcap' [-Werror=unused-variable] 83 | unsigned long int dl_hwcap = features->hwcap; | ^~~~~~~~ https://sourceware.org/pipermail/libc-testresults/2023q1/010855.html Add __attribute__ ((unused)) as already done for another variable there. Tested with build-many-glibcs.py (compilers and glibcs) for s390x-linux-gnu and s390-linux-gnu. Note: s390x-linux-gnu-O3 started failing with a different error earlier; that problem may still need to be fixed after this fix is in. https://sourceware.org/pipermail/libc-testresults/2023q1/010829.html
* [hurd] Fix i686 build breakage caused by 4fedebc91108Flavio Cruz2023-02-173-4/+4
| | | | Message-Id: <Y+8bqZzYTl7WaUm7@jupiter.tail36e24.ts.net>
* C2x strtol binary constant handlingJoseph Myers2023-02-1684-24/+1683
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | C2x adds binary integer constants starting with 0b or 0B, and supports those constants in strtol-family functions when the base passed is 0 or 2. Implement that strtol support for glibc. As discussed at <https://sourceware.org/pipermail/libc-alpha/2020-December/120414.html>, this is incompatible with previous C standard versions, in that such an input string starting with 0b or 0B was previously required to be parsed as 0 (with the rest of the string unprocessed). Thus, as proposed there, this patch adds 20 new __isoc23_* functions with appropriate header redirection support. This patch does *not* do anything about scanf %i (which will need 12 new functions per long double variant, so 12, 24 or 36 depending on the glibc configuration), instead leaving that for a future patch. The function names would remain as __isoc23_* even if C2x ends up published in 2024 rather than 2023. Making this change leads to the question of what should happen to internal uses of these functions in glibc and its tests. The header redirection (which applies for _GNU_SOURCE or any other feature test macros enabling C2x features) has the effect of redirecting internal uses but without those uses then ending up at a hidden alias (see the comment in include/stdio.h about interaction with libc_hidden_proto). It seems desirable for the default for internal uses to be the same versions used by normal code using _GNU_SOURCE, so rather than doing anything to disable that redirection, similar macro definitions to those in include/stdio.h are added to the include/ headers for the new functions. Given that the default for uses in glibc is for the redirections to apply, the next question is whether the C2x semantics are correct for all those uses. Uses with the base fixed to 10, 16 or any other value other than 0 or 2 can be ignored. I think this leaves the following internal uses to consider (an important consideration for review of this patch will be both whether this list is complete and whether my conclusions on all entries in it are correct): benchtests/bench-malloc-simple.c benchtests/bench-string.h elf/sotruss-lib.c math/libm-test-support.c nptl/perf.c nscd/nscd_conf.c nss/nss_files/files-parse.c posix/tst-fnmatch.c posix/wordexp.c resolv/inet_addr.c rt/tst-mqueue7.c soft-fp/testit.c stdlib/fmtmsg.c support/support_test_main.c support/test-container.c sysdeps/pthread/tst-mutex10.c I think all of these places are OK with the new semantics, except for resolv/inet_addr.c, where the POSIX semantics of inet_addr do not allow for binary constants; thus, I changed that file (to use __strtoul_internal, whose semantics are unchanged) and added a test for this case. In the case of posix/wordexp.c I think accepting binary constants is OK since POSIX explicitly allows additional forms of shell arithmetic expressions, and in stdlib/fmtmsg.c SEV_LEVEL is not in POSIX so again I think accepting binary constants is OK. Functions such as __strtol_internal, which are only exported for compatibility with old binaries from when those were used in inline functions in headers, have unchanged semantics; the __*_l_internal versions (purely internal to libc and not exported) have a new argument to specify whether to accept binary constants. As well as for the standard functions, the header redirection also applies to the *_l versions (GNU extensions), and to legacy functions such as strtoq, to avoid confusing inconsistency (the *q functions redirect to __isoc23_*ll rather than needing their own __isoc23_* entry points). For the functions that are only declared with _GNU_SOURCE, this means the old versions are no longer available for normal user programs at all. An internal __GLIBC_USE_C2X_STRTOL macro is used to control the redirections in the headers, and cases in glibc that wish to avoid the redirections - the function implementations themselves and the tests of the old versions of the GNU functions - then undefine and redefine that macro to allow the old versions to be accessed. (There would of course be greater complexity should we wish to make any of the old versions into compat symbols / avoid them being defined at all for new glibc ABIs.) strtol_l.c has some similarity to strtol.c in gnulib, but has already diverged some way (and isn't listed at all at https://sourceware.org/glibc/wiki/SharedSourceFiles unlike strtoll.c and strtoul.c); I haven't made any attempts at gnulib compatibility in the changes to that file. I note incidentally that inttypes.h and wchar.h are missing the __nonnull present on declarations of this family of functions in stdlib.h; I didn't make any changes in that regard for the new declarations added.
* [hurd] Add MTU_DISCOVER valuesSamuel Thibault2023-02-151-0/+20
|
* hurd: Fix unwinding over INTR_MSG_TRAP in shared tooSamuel Thibault2023-02-141-0/+1
| | | | | This follows 63550530d98d ("hurd: Fix unwinding over INTR_MSG_TRAP"), for the shared library case.
* mach: undef ENTRY2Sergey Bugaev2023-02-141-0/+1
| | | | | | | | This macro from Mach headers conflicts with how sysdeps/x86_64/multiarch/strcmp-sse2.S expects it to be defined. Signed-off-by: Sergey Bugaev <bugaevc@gmail.com> Message-Id: <20230214173722.428140-3-bugaevc@gmail.com>
* hurd: i386 TLS tweaksSergey Bugaev2023-02-141-13/+35
| | | | | | | | | | | | | | * Micro-optimize TLS access using GCC's native support for gs-based addressing when available; * Just use THREAD_GETMEM and THREAD_SETMEM instead of more inline assembly; * Sync tcbhead_t layout with NPTL, in particular update/fix __private_ss offset; * Statically assert that the two offsets that are a part of ABI are what we expect them to be. Signed-off-by: Sergey Bugaev <bugaevc@gmail.com> Message-Id: <20230214173722.428140-2-bugaevc@gmail.com>
* stdio: Do not ignore posix_spawn error on popen (BZ #29016)Adhemerval Zanella2023-02-143-16/+63
| | | | | | To correctly return error in case of default shell is not present. Checked on x86_64-linux-gnu.
* update auto-libm-test-out-hypotPaul Zimmermann2023-02-141-0/+25
| | | | | This change was forgotten in commit cf7ffdd. Reviewed-by: Florian Weimer <fweimer@redhat.com>
* added pair of inputs for hypotf in binary32Paul Zimmermann2023-02-141-0/+2
| | | | | | | | | | | | | | This pair yields an error of 1 ulp in binary32, whereas the current maximal known error for hypotf on x86_64 is zero: Checking hypot with glibc-2.37 hypot 0 -1 -0x1.003222p-20,-0x1.6a2d58p-32 [0.501] 0.500001 0.500000001392678 libm gives 0x1.003224p-20 mpfr gives 0x1.003222p-20 See https://sourceware.org/pipermail/libc-alpha/2023-February/145432.html and https://sourceware.org/pipermail/libc-alpha/2023-February/145442.html Reviewed-by: Carlos O'Donell <carlos@redhat.com>
* Naming the parameter of dummy_sa_handlerMahesh Bodapati2023-02-131-1/+1
| | | | | | | | ISO C does not support omitting parameter names in function definitions before C2X,the compiler is giving an error with older versions of gcc and this commit will resolve the test failure "error: parameter name omitted" Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* hurd: Fix tcflag_t and speed_t types on 64-bitSergey Bugaev2023-02-121-2/+2
| | | | | | | | These are supposed to stay 32-bit even on 64-bit systems. This matches BSD and Linux, as well as how these types are already defined in tioctl.defs Signed-off-by: Sergey Bugaev <bugaevc@gmail.com>
* htl: Remove ./sysdeps/htl/bits/types/struct___pthread_mutex.hSamuel Thibault2023-02-121-61/+0
| | | | This follows a99155555c21 ("htl: Remove unused files")
* hurd, htl: Add some x86_64-specific codeSergey Bugaev2023-02-123-0/+78
| | | | | Signed-off-by: Sergey Bugaev <bugaevc@gmail.com> Message-Id: <20230212111044.610942-12-bugaevc@gmail.com>
* Fix typos in commentsSamuel Thibault2023-02-122-2/+2
|
* htl: Generalize i386 pt-machdep.h to x86Samuel Thibault2023-02-123-1/+3
|
* hurd: Set up the basic tree for x86_64-gnuSergey Bugaev2023-02-126-2/+10
| | | | | | | And move pt-setup.c to the generic x86 tree. Signed-off-by: Sergey Bugaev <bugaevc@gmail.com> Message-Id: <20230212111044.610942-11-bugaevc@gmail.com>
generated by cgit-pink 1.4.1 (git 2.36.1) at 2024-07-01 12:09:36 +0000