Bug#995269: glibc-source: Please enable MTE (heap) checking on arm64
Package: glibc-source Severity: wishlist Tags: patch glibc 2.33 onwards has support for 'Memory Tagging Extension' on arm64. Could you please enable this feature (by setting --enable-memory-tagging in the config). The effect is to add colouring bits into heap pointers so that typical illegal accesses (either temporally or spatially) can be detected and faulted. Glibc just has the userspace heap tagging - there is also corresponding kernel support. The functionality operates on arm ISA 8.5 or later, which has extra instructions to manipulate the tag bits in pointers. The details are explained in https://developer.arm.com/-/media/Arm%20Developer%20Community/PDF/Arm_Memory_Tagging_Extension_Whitepaper.pdf The implementation has been designed so that it is safe to enable in distros (which makes a change!). ifunc and HWCAP are used to link MTE-ready versions of relevant functions on hardware supporting ARMv8.5 instruction set or later. On eailer hardware things will work just as they do now. Here is the (trivial) patch: diff -u debian/sysdeps/arm64.mk~ debian/sysdeps/arm64.mk --- debian/sysdeps/arm64.mk~2021-08-24 14:31:06.0 + +++ debian/sysdeps/arm64.mk 2021-09-28 19:43:58.782118977 + @@ -1,2 +1,2 @@ # configuration options for all flavours -extra_config_options = --enable-multi-arch --enable-static-pie +extra_config_options = --enable-multi-arch --enable-static-pie --enable-memory-tagging -- Wookey
Bug#874587: glibc: Packaging support for arm64ilp32 architecture
Source: glibc
Version: 2.24-11
Severity: wishlist
Tags: patch
arm64ilp32 is a new 32-bit ABI 'ILP32' for the arm64 architecture,
which normally uses the 'LP64' ABI
We are adding support to Debian so that it is possible to build this
architecture. glibc is part of the toolchain bootstrap so needs to
support this. However the ABI is not yet in upstream glibc because
they are waiting for the kernel to adopt the final ABI interface
first. The branch for tracking is here:
https://git.linaro.org/toolchain/glibc.git/log/?h=arm/ilp32
Attached is the (fairly trivial) patch for adding support to the debian
packaging so that once upstream supports this it can be built.
To actually build a glibc for arm64ilp32 you also need the 250K glibc
patch which I won't include here, and a couple of fixes. These three commits
show what's needed:
https://anonscm.debian.org/cgit/users/wookey/rebootstrap.git/commit/?h=ilp32-stable=091d79dd8c23d4f02dbc32cf1fd3cf1a5716bf9a
https://anonscm.debian.org/cgit/users/wookey/rebootstrap.git/commit/?h=ilp32-stable=a72b2eefd6295fc5aad25ff3bc2ba8c9b913637e
https://anonscm.debian.org/cgit/users/wookey/rebootstrap.git/commit/?h=ilp32-stable=7883ccac72bfaaaeb6f4504db4010e8f32c1a5b1
diff -urN glibc-2.24/debian/control glibc-2.24.patched/debian/control
--- glibc-2.24/debian/control 2017-04-09 21:28:38.0 +
+++ glibc-2.24.patched/debian/control 2017-05-18 13:19:04.001882367 +
@@ -157,7 +157,7 @@
be removed once nothing on the system depends on it.
Package: libc6
-Architecture: amd64 arm64 armel armhf hppa i386 m68k mips mipsel mipsn32 mipsn32el mips64 mips64el nios2 powerpc powerpcspe ppc64 ppc64el sparc sparc64 s390x sh3 sh4 x32
+Architecture: amd64 arm64 arm64ilp32 armel armhf hppa i386 m68k mips mipsel mipsn32 mipsn32el mips64 mips64el nios2 powerpc powerpcspe ppc64 ppc64el sparc sparc64 s390x sh3 sh4 x32
Section: libs
Priority: required
Multi-Arch: same
@@ -188,7 +188,7 @@
and the standard math library, as well as many others.
Package: libc6-dev
-Architecture: amd64 arm64 armel armhf hppa i386 m68k mips mipsel mipsn32 mipsn32el mips64 mips64el nios2 powerpc powerpcspe ppc64 ppc64el sparc sparc64 s390x sh3 sh4 x32
+Architecture: amd64 arm64 arm64ilp32 armel armhf hppa i386 m68k mips mipsel mipsn32 mipsn32el mips64 mips64el nios2 powerpc powerpcspe ppc64 ppc64el sparc sparc64 s390x sh3 sh4 x32
Section: libdevel
Priority: optional
Multi-Arch: same
@@ -203,7 +203,7 @@
and link programs which use the standard C library.
Package: libc6-dbg
-Architecture: amd64 arm64 armel armhf hppa i386 m68k mips mipsel mipsn32 mipsn32el mips64 mips64el nios2 powerpc powerpcspe ppc64 ppc64el sparc sparc64 s390x sh3 sh4 x32
+Architecture: amd64 arm64 arm64ilp32 armel armhf hppa i386 m68k mips mipsel mipsn32 mipsn32el mips64 mips64el nios2 powerpc powerpcspe ppc64 ppc64el sparc sparc64 s390x sh3 sh4 x32
Section: debug
Priority: extra
Multi-Arch: same
@@ -215,7 +215,7 @@
library.
Package: libc6-pic
-Architecture: amd64 arm64 armel armhf hppa i386 m68k mips mipsel mipsn32 mipsn32el mips64 mips64el nios2 powerpc powerpcspe ppc64 ppc64el sparc sparc64 s390x sh3 sh4 x32
+Architecture: amd64 arm64 arm64ilp32 armel armhf hppa i386 m68k mips mipsel mipsn32 mipsn32el mips64 mips64el nios2 powerpc powerpcspe ppc64 ppc64el sparc sparc64 s390x sh3 sh4 x32
Section: libdevel
Priority: optional
Multi-Arch: same
@@ -231,7 +231,7 @@
Package: libc6-udeb
Package-Type: udeb
-Architecture: amd64 arm64 armel armhf hppa i386 m68k mips mipsel mipsn32 mipsn32el mips64 mips64el nios2 powerpc powerpcspe ppc64 ppc64el sparc sparc64 s390x sh3 sh4 x32
+Architecture: amd64 arm64 arm64ilp32 armel armhf hppa i386 m68k mips mipsel mipsn32 mipsn32el mips64 mips64el nios2 powerpc powerpcspe ppc64 ppc64el sparc sparc64 s390x sh3 sh4 x32
Section: debian-installer
Priority: extra
Provides: libc6, libc-udeb, libnss-dns-udeb, libnss-files-udeb, ${locale-compat:Depends}
diff -urN glibc-2.24/debian/libc6.symbols.arm64ilp32 glibc-2.24.patched/debian/libc6.symbols.arm64ilp32
--- glibc-2.24/debian/libc6.symbols.arm64ilp32 1970-01-01 00:00:00.0 +
+++ glibc-2.24.patched/debian/libc6.symbols.arm64ilp32 2017-05-18 13:19:04.001882367 +
@@ -0,0 +1,5 @@
+#include "libc6.symbols.common"
+ld-linux-aarch64_ilp32.so.1 #PACKAGE# #MINVER#
+#include "symbols.wildcards"
+libc.so.6 #PACKAGE# #MINVER#
+#include "symbols.wildcards"
diff -urN glibc-2.24/debian/rules.d/control.mk glibc-2.24.patched/debian/rules.d/control.mk
--- glibc-2.24/debian/rules.d/control.mk 2017-04-09 21:28:38.0 +
+++ glibc-2.24.patched/debian/rules.d/control.mk 2017-05-18 13:19:04.001882367 +
@@ -1,7 +1,7 @@
libc_packages := libc6 libc6.1 libc0.1 libc0.3
libc0_1_archs := kfreebsd-amd64 kfreebsd-i386
libc0_3_archs := hurd-i386
-libc6_archs := amd64 arm64 armel armhf hppa i386 m68k mips mipsel mipsn32 mipsn32el mips64 mips64el nios2 powerpc powerpcspe ppc64 ppc64el sparc sparc64
Re: Bug#851790: installation-reports: DNS not working
On 2017-01-19 11:04 +0100, Cyril Brulebois wrote: > Steve McIntyre <st...@einval.com> (2017-01-19): > > On Thu, Jan 19, 2017 at 08:57:54AM +0100, Aurelien Jarno wrote: > > > > > >The workaround are to make sure the chroots are up-to-date (which should > > >be the case now on the build daemons). An other alternative would be to > > >avoid copying a library in mklibs if it is already present in the image. > > >That might break if some very strict dependencies are used, though > > >I guess the way the udebs are downloaded, they should always have the > > >same or a newer version than in the chroot. > > > > Thanks for the explanation - it's appreciated! > > Yeah, thanks for the confirmation. OK. I tested today's image (2017-01-23 04:56) and the install went through OK, so we are back in sync and this issue is gone for now. It should probably be retitled to something about library sync/using host libs and left open until it's fixed propoerly. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: Digital signature
Re: struct user conflicts on arm
This subject came up on debian-arm: http://lists.debian.org/debian-arm/2011/12/msg00025.html And it seems like the sort of architectural issue linaro should take an interest in fixing to avoid making people's lives difficult when building on arm. Is it on anyone's list already? In short: A C app that defines a struct 'user' and uses wait.h or signal.h will find a clash with the system struct of the same name, which should only be needed for GDB (when built on/for arm). On other arches this is not pulled in by default so the problem doesn't arise. We can 1) Change every app in the world that defines a 'struct user' 2) Stop these headers getting brought in when not actually needed (it's a relatively recent change that brings it in) 3) Change the name in glibc/GDB to something less likely to clash disclaimer: I know nothing at all about this except what I just read in that thread. Please refer to the thread for details. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111215110917.gc28...@dream.aleph1.co.uk
Bug#500164: /etc/environment file is not dealt with by dpkg-reconfigure locales
Package: locales Version: 2.7-13 Severity: normal Tags: l10n /etc/environment has been superceded by /etc/default/locale but nothing ensures that only one exists on the system or that they match up, or that locales to support both are generated. If this causes a problem it is very difficult for the user to find out where the problem lies and what to do about it. I think that the old file should probably just be removed (is there a good reason why not?). If not then the user should be warned if they do not match up and dpkg-reconfigure locales should adjust both when run. Case study of how this caused a problem: I had a machine generating mail every five minutes (munin cron job) complaining about perl being unable to set locale: perl: warning: Setting locale failed. perl: warning: Please check that your locale settings: LANGUAGE = en_GB:en_US:en_GB:en, LC_ALL = (unset), LANG = en_GB are supported and installed on your system. perl: warning: Falling back to the standard locale (C). the /etc/environment file looked like this: LANGUAGE = en_GB:en_US:en_GB:en LANG=en_GB the /etc/default/locale file looked like this: # File generated by update-locale LANG=en_GB.UTF-8 This all looks reasonable to anyone not intimately familiar with how the locale stuff works. For some reason the perl scipr run by cron picked up the settings from /etc/environment perl run on the cooman-line did not complain - I guess it was using /etc/default/locale. I eventually ran dpkg-reconfigure locales to find that en_GB.iso8859-15 and en_GB.UTF-8 were being generated. That lokoed OK (I know that en_GB.ISO8859-15 is en_GB.ISO8859-1 plus the euro symbol) It turns out that LANG=en_GB actually requires en_GB.ISO8859-1 to be generated to be satisfied, hecne the complaints from perl and the torrent of email. Running dpkg-reconfigure locales did not change the LANG in /etc/environment to be one that was generated or wanr that it pointed at one that was not. Nor did it give any clue that the old file might still be being used and thus might cause problems and should be removed. Not directly related to this bug: To add to the fun the mails generated came from root (Cron Daemon) and were forwarded to an offsite email. They were rejected by the forwarded-to server due to not coming from a valid address, and were bounced back to an invalid address so they were never seen by anyone until work's anti-spam filter provider complained that they were exceeding their 9000 messages/month and needed to pay extra. 8900-odd of those messages were coming from this bug combined with a stock installation of munin and an MTA that did not do address rewriting on cron-generated mail. I am a reasonably savvy user and it took me most of the day to track this down and work out what the right fix is. It would help all users, but especially the less-expert if the old file was tidied-up or automatically synced and/or warned-about, or had locales generated for it. thanx -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (990, 'testing'), (600, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.24-1-amd64 (SMP w/1 CPU core) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages locales depends on: ii debconf [debconf-2.0] 1.5.22 Debian configuration management sy ii libc6 [glibc-2.7-1] 2.7-13 GNU C Library: Shared libraries locales recommends no packages. locales suggests no packages. -- debconf information: * locales/default_environment_locale: en_GB.UTF-8 * locales/locales_to_be_generated: en_GB.UTF-8 UTF-8 __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#391305: closed by Clint Adams [EMAIL PROTECTED] (Bug#391305: fixed in linux-kernel-headers 2.6.18-2)
On 2006-10-07 06:36 -0700, Debian Bug Tracking System wrote: Subject: Bug#391305: fixed in linux-kernel-headers 2.6.18-2 OK, thanx for the prompt upload. Just for omcpleteness anyone reading this should be aware that it relates to this issue: http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=3608/1 Wookey -- Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel +44 (0) 1223 811679 work: http://www.aleph1.co.uk/ play: http://wookware.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#391305: linux-kernel-headers: FTBFS on arm - complains about __32 t; in include/asm/byteorder.h:21
Package: linux-kernel-headers
Version: 2.6.18-2
Severity: serious
Justification: no longer builds from source
building fails with
cc -Wall -Werror -W -I
/root/linux-kernel-headers-2.6.18/testsuite/../debian/linux-kernel-headers/usr/include
-I /root/linux-kernel-headers-2.6.18/testsuite/../include -ansi -pedantic -o
ansi-msdos-fs.o -c msdos-fs.c
In file included from
/root/linux-kernel-headers-2.6.18/testsuite/../include/linux/msdos_fs.h:7,
from msdos-fs.c:1:
/root/linux-kernel-headers-2.6.18/testsuite/../debian/linux-kernel-headers/usr/include/asm/byteorder.h:21:
error: expected '=', ',', ';', 'asm' or '__attribute__' before '__u32'
cc1: warnings being treated as errors
In file included from
/root/linux-kernel-headers-2.6.18/testsuite/../include/linux/byteorder/little_endian.h:12,
from
/root/linux-kernel-headers-2.6.18/testsuite/../debian/linux-kernel-headers/usr/include/asm/byteorder.h:54,
from
/root/linux-kernel-headers-2.6.18/testsuite/../include/linux/msdos_fs.h:7,
from msdos-fs.c:1:
/root/linux-kernel-headers-2.6.18/testsuite/../include/linux/byteorder/swab.h:
In function '__fswab32':
/root/linux-kernel-headers-2.6.18/testsuite/../include/linux/byteorder/swab.h:148:
warning: implicit declaration of function '___arch__swab32'
make[1]: *** [ansi-msdos-fs.o] Error 1
make[1]: Leaving directory /root/linux-kernel-headers-2.6.18/testsuite'
make: *** [lkh-test] Error 2
This is as reported in
http://buildd.debian.org/fetch.php?pkg=linux-kernel-headersarch=armver=2.6.18-1stamp=1159121860file=log
and confirmed on leisner.d.o
This seems a bit wierd:
/root/linux-kernel-headers-2.6.18/testsuite/../include/linux/byteorder/little_endian.h:12
leisner:~/linux-kernel-headers-2.6.18/testsuite# grep -n #include
../include/linux/byteorder/little_endian.h
11:#include linux/types.h
12:#include linux/byteorder/swab.h
which is including linux/byteorder/swab.h, not asm/byteorder.h. so how did we
get to the error in asm/byteorder.h:21 ?
using -E instead of -c in above command we get:
the source:
---asm-arm/byteorder.h--
#ifndef __ASM_ARM_BYTEORDER_H
#define __ASM_ARM_BYTEORDER_H
#include linux/compiler.h
#include asm/types.h
static inline __attribute_const__ __u32 ___arch__swab32(__u32 x)
{
__u32 t;
#ifndef __thumb__
if (!__builtin_constant_p(x)) {
--
preprocessed to:
-
typedef __signed__ int __s32;
typedef unsigned int __u32;
__extension__ typedef __signed__ long long __s64;
__extension__ typedef unsigned long long __u64;
# 20
/root/linux-kernel-headers-2.6.18/testsuite/../debian/linux-kernel-headers/usr/include/asm
/byteorder.h 2
static inline __u32 ___arch__swab32(__u32 x)
{
__u32 t;
if (!__builtin_constant_p(x)) {
--
which looks OK to me.
(Is __attribute_const__ supposed to be null?)
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: arm (armv4tl)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.17-csb637
Locale: LANG=, LC_CTYPE=
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
