Bug#636286: eglibc: SIGSEGV in strcoll in UTF-8 locales with certain characters
There is no testcase. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." -- 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/m2pqknhgrt@igel.home
Bug#636286: eglibc: SIGSEGV in strcoll in UTF-8 locales with certain characters
The locale files are invalid. Since I cannot reproduce that with the unmodified localedef program this must be due to some broken debian patches. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." -- 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/m2pqkhoxsj@igel.home
Bug#652356: please use argument-safe bswap macros on all architectures
Thorsten Glaser writes: > Aurelien Jarno dixit: > >>I am not an m68k porter, and I am not planning to try things. m68k is >>lagging upstream wrt other architectures. Please work with upstream to >>fix things, then I can include tested and accepted patches. > > I’m not an m68k porter either, but this fix is easily done from working > with a libc (BSD libc in my case) skills. But okay. Am I guessing that > libc-po...@sourceware.org is “upstream”? It was hard to find information > about eglibc-ports on the ’net. > > Anyway, here it is: This has already been fixed a long time ago. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." -- 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/m2k45vax0a@igel.home
Bug#429021: builtin echo command redirection misbehaves in detached scripts when terminal is closed
Chet Ramey <[EMAIL PROTECTED]> writes: > What's needed is a portable interface like BSD's fpurge(3). This is also available from glibc as __fpurge (likewise on Solaris). Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Bug#709992: eglibc: FTBFS: Assembler messages: Error: bad register expression
>From 5ccb4311206d95f48e44ffaba09bf6cf05d17145 Mon Sep 17 00:00:00 2001 From: Andreas Schwab Date: Tue, 25 Jun 2013 18:57:42 +0200 Subject: [PATCH] m68k: fix bad use of register alias in cfi insn --- ports/ChangeLog.m68k| 5 + ports/sysdeps/m68k/sysdep.h | 4 ++-- 2 files changed, 7 insertions(+), 2 deletions(-) diff --git a/ports/ChangeLog.m68k b/ports/ChangeLog.m68k index f9a5f0b..c5b1e21 100644 --- a/ports/ChangeLog.m68k +++ b/ports/ChangeLog.m68k @@ -1,3 +1,8 @@ +2013-06-25 Andreas Schwab + + * sysdeps/m68k/sysdep.h (CALL_MCOUNT) [PROF]: Use %a6 instead of + %fp in cfi insns. + 2013-06-15 Siddhesh Poyarekar * sysdeps/unix/sysv/linux/m68k/coldfire/nptl/libpthread.abilist: diff --git a/ports/sysdeps/m68k/sysdep.h b/ports/sysdeps/m68k/sysdep.h index cd34dd8..f8ad70e 100644 --- a/ports/sysdeps/m68k/sysdep.h +++ b/ports/sysdeps/m68k/sysdep.h @@ -45,11 +45,11 @@ to locate our caller, so push one just for its benefit. */ # define CALL_MCOUNT \ move.l %fp, -(%sp);\ - cfi_adjust_cfa_offset (4); cfi_rel_offset (%fp, 0); \ + cfi_adjust_cfa_offset (4); cfi_rel_offset (%a6, 0); \ move.l %sp, %fp; \ jbsr JUMPTARGET (_mcount); \ move.l (%sp)+, %fp;\ - cfi_adjust_cfa_offset (-4); cfi_restore (%fp); + cfi_adjust_cfa_offset (-4); cfi_restore (%a6); # else # define CALL_MCOUNT /* Do nothing. */ # endif -- 1.8.3.1 -- 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/87txkm5dbm@igel.home
Re: libc 2.3 and RT signals broken
Daniel Jacobowitz <[EMAIL PROTECTED]> writes: |> SIGRTMIN has changed behavior recently in 2.3; at the same time as: |> |> 2002-09-18 Ulrich Drepper <[EMAIL PROTECTED]> |> |> * signal/allocrtsig.c: Move to... |> * sysdeps/generic/allocrtsig.c: ...here. New file. |> |> as far as I can tell. |> |> The problem is something I ran into in GDB today: the location of a |> source file overrides the normal search path. If a file in |> sysdeps/generic/ includes a header using "", the copy in |> sysdeps/generic/ will win. So we get sysdeps/generic/testrtsig.h |> instead of the sysdeps/unix/sysv/linux/testrtsig.h, and |> kernel_has_rtsig always returns 0. The right fix is probably to change "..." to <...>. Could you try that please? Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: libc 2.3 and RT signals broken
Jakub Jelinek <[EMAIL PROTECTED]> writes: |> That of course works just fine (tested it even when it is obvious). |> As for why allocrtsig.c was moved from signal to sysdeps/generic, |> look at nptl/sysdeps/unix/sysv/linux/allocrtsig.c. |> Can you or AJ please check it in? Thanks. Done. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Linux getdents.c is not aliasing safe
Daniel Jacobowitz <[EMAIL PROTECTED]> writes:
|> Highlights:
|> char *kbuf = buf;
|> size_t kbytes = nbytes;
|> if (offsetof (DIRENT_TYPE, d_name)
|> < offsetof (struct kernel_dirent64, d_name)
|> && nbytes <= sizeof (DIRENT_TYPE))
|> {
|> kbytes = nbytes + offsetof (struct kernel_dirent64, d_name)
|>- offsetof (DIRENT_TYPE, d_name);
|> kbuf = __alloca(kbytes);
|> }
|>
|> dp = (DIRENT_TYPE *)buf;
|> kdp = (struct kernel_dirent64 *) kbuf;
|>
|> uint64_t d_ino = kdp->d_ino;
|> int64_t d_off = kdp->d_off;
|> unsigned char d_type = kdp->d_type;
|>
|> DIRENT_SET_DP_INO (dp, d_ino);
|> dp->d_off = d_off;
|>
|> GCC is perfectly free to re-order the stores and loads here; if it does,
|> when buf and kbuf are pointing at the same thing (which they usually are),
|> then storing to dp->d_off (at offset 4 in a 32-bit dirent) corrupts d_ino
|> (at offset 0 and size 8 in a kernel_dirent64). This is why Debian was
|> seeing a broken ldconfig.
|>
|> Not sure how to fix this while still editing the buffer in-place. It seems
|> like we want the equivalent of:
|>
|> union {
|> DIRENT_TYPE dpbuf[];
|> struct kernel_dirent64[];
|> }
|>
|> but that's not legal C.
How about using two pointers of type
union {
DIRENT_TYPE dp;
struct kernel_dirent64 kdp;
}
?
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#184048: [m68k] binutils testsuite failures built in a glibc-2.3.1 environment
Matthias Klose <[EMAIL PROTECTED]> writes: |> but fewer testcases as well ... |> |> FAIL: visibility (hidden_weak) (non PIC, load offset) |> FAIL: visibility (hidden_weak) (PIC main, non PIC so) |> FAIL: visibility (protected_undef_def) (non PIC, load offset) |> |> these three did pass with glibc-2.3.1 and glibc-2.2.3, the second one |> did pass with glibc-2.3.1, but not with glibc-2.2.3. |> |> Andreas, do we need to care about these failures? Non-PIC DSOs are generally not something you should use, so this is low priority. But it is still worth fixing. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Manual pages from glibc-doc
On Mai 21 2023, Alejandro Colomar wrote: > It seems that the pages were removed from glibc upstream in 2005 [1], That was the time when the whole linuxthreads directory was removed. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: libc 2.3 and RT signals broken
Daniel Jacobowitz <[EMAIL PROTECTED]> writes: |> SIGRTMIN has changed behavior recently in 2.3; at the same time as: |> |> 2002-09-18 Ulrich Drepper <[EMAIL PROTECTED]> |> |> * signal/allocrtsig.c: Move to... |> * sysdeps/generic/allocrtsig.c: ...here. New file. |> |> as far as I can tell. |> |> The problem is something I ran into in GDB today: the location of a |> source file overrides the normal search path. If a file in |> sysdeps/generic/ includes a header using "", the copy in |> sysdeps/generic/ will win. So we get sysdeps/generic/testrtsig.h |> instead of the sysdeps/unix/sysv/linux/testrtsig.h, and |> kernel_has_rtsig always returns 0. The right fix is probably to change "..." to <...>. Could you try that please? Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: libc 2.3 and RT signals broken
Jakub Jelinek <[EMAIL PROTECTED]> writes: |> That of course works just fine (tested it even when it is obvious). |> As for why allocrtsig.c was moved from signal to sysdeps/generic, |> look at nptl/sysdeps/unix/sysv/linux/allocrtsig.c. |> Can you or AJ please check it in? Thanks. Done. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: Linux getdents.c is not aliasing safe
Daniel Jacobowitz <[EMAIL PROTECTED]> writes:
|> Highlights:
|> char *kbuf = buf;
|> size_t kbytes = nbytes;
|> if (offsetof (DIRENT_TYPE, d_name)
|> < offsetof (struct kernel_dirent64, d_name)
|> && nbytes <= sizeof (DIRENT_TYPE))
|> {
|> kbytes = nbytes + offsetof (struct kernel_dirent64, d_name)
|>- offsetof (DIRENT_TYPE, d_name);
|> kbuf = __alloca(kbytes);
|> }
|>
|> dp = (DIRENT_TYPE *)buf;
|> kdp = (struct kernel_dirent64 *) kbuf;
|>
|> uint64_t d_ino = kdp->d_ino;
|> int64_t d_off = kdp->d_off;
|> unsigned char d_type = kdp->d_type;
|>
|> DIRENT_SET_DP_INO (dp, d_ino);
|> dp->d_off = d_off;
|>
|> GCC is perfectly free to re-order the stores and loads here; if it does,
|> when buf and kbuf are pointing at the same thing (which they usually are),
|> then storing to dp->d_off (at offset 4 in a 32-bit dirent) corrupts d_ino
|> (at offset 0 and size 8 in a kernel_dirent64). This is why Debian was
|> seeing a broken ldconfig.
|>
|> Not sure how to fix this while still editing the buffer in-place. It seems
|> like we want the equivalent of:
|>
|> union {
|> DIRENT_TYPE dpbuf[];
|> struct kernel_dirent64[];
|> }
|>
|> but that's not legal C.
How about using two pointers of type
union {
DIRENT_TYPE dp;
struct kernel_dirent64 kdp;
}
?
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Bug#204789: ia64 function descriptors and unexec
Camm Maguire <[EMAIL PROTECTED]> writes: > To sum up the previous discussion, the ia64 linux ABI apparently > offers no opportunity for ld.so to ensure that function descriptors > remain constant, even over successive executions of the same binary on > the same machine. There is no problem with statically initialized function pointers, only for assigned pointer at runtime. The function descriptors for the former are generated at compile time and won't ever change. > I believe that this issue stood in the way of an emacs port to ia64 > linux for some time, There is no such problem with GNU Emacs. Only XEmacs has this problem. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#204789: [Gcl-devel] Re: ia64 function descriptors and unexec
Camm Maguire <[EMAIL PROTECTED]> writes: > OK, but I need saved runtime-initialized function pointers. Do you > have either a reference for how xemacs has handled this, or a contact > person who might know? I have hacked XEmacs to re-assign all those function pointers, good enough to get it running. But this hack is too ugly, so I never bothered to send the patch upstream (I also never used XEmacs myself, so I don't care much). I've heard that the current version of XEmacs use a different dumper which doesn't have this problem any more, but I didn't test it yet. > Was there ever a GNU emacs obstacle on ia64 linux, or am I confusing > the situation with xemacs? Since GNU Emacs does not assign function pointers at runtime there was never such a problem. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#204789: [Gcl-devel] Re: ia64 function descriptors and unexec
Peter Chubb <[EMAIL PROTECTED]> writes: >>>>>> "Andreas" == Andreas Schwab <[EMAIL PROTECTED]> writes: > > Andreas> Camm Maguire <[EMAIL PROTECTED]> writes: > > Andreas> I have hacked XEmacs to re-assign all those function > Andreas> pointers, good enough to get it running. But this hack is > Andreas> too ugly, so I never bothered to send the patch upstream (I > Andreas> also never used XEmacs myself, so I don't care much). I've > Andreas> heard that the current version of XEmacs use a different > Andreas> dumper which doesn't have this problem any more, but I didn't > Andreas> test it yet. > > Well the version packaged for Debian on IA64 still does not work: > Bug #149088 in the debian bug tracking system. You can get a picture of the necessary changes from <ftp://ftp.suse.com/pub/suse/i386/8.2/suse/src/xemacs-21.4.12-39.src.rpm>. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#204789: [Gcl-devel] Re: ia64 function descriptors and unexec
Camm Maguire <[EMAIL PROTECTED]> writes: > Greetings! > > Andreas Schwab <[EMAIL PROTECTED]> writes: > >> > Was there ever a GNU emacs obstacle on ia64 linux, or am I confusing >> > the situation with xemacs? >> >> Since GNU Emacs does not assign function pointers at runtime there was >> never such a problem. >> > > Could you please sketch how this is accomplished in emacs, given its > lisp base? [...] > Or are all lisp function objects statically defined in C source files as > explicitly initialized structures? Yes. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#204789: [Gcl-devel] Re: ia64 function descriptors and unexec
[removing emacs-devel from cc: since it's off-topic there.] Camm Maguire <[EMAIL PROTECTED]> writes: > Far better than trying to probe ld.so's function descriptor table, I > should rather ammend the lisp compiler to write a static function > structure into each produced C source file before compilation, with the > structure's pointer element statically initialized to the static > function in the same file. I then use the address for this structure at > runtime in setting the lisp symbol's function definition. This should > work, right? I have rechecked the specs, and actually the key point isn't static vs. dynamic assignment, but rather local vs. dynamic symbols. A function descriptor for a symbol in a shared library will be allocated by the dynamic linker, whereas those for symbols in the executable are allocated by the static linker. So you only have to make sure that all function pointers in the executable only refer to functions therein. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#204789: [Gcl-devel] Re: ia64 function descriptors and unexec
Camm Maguire <[EMAIL PROTECTED]> writes: > When I first read this, I was more confused by the meaning of the term > 'local' and what I've been seeing. Which is understandable, because I was confused, too. What you are saying is correct. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
