Does anyone know why __WIFSTOPPED macro redefined for MIPS architecture as
#if !defined(__mips__)
#define __WIFSTOPPED(status) (((status) & 0xff) == 0x7f)
#else
#define __WIFSTOPPED(status) (((status) & 0xff) == 0x7f && ((status) & 0xff00)) #endif
?
The problem with this definition is in that newer gdb versions (>= 7.0) expect that WIFSTOPPED(W_STOPCODE(0)) is true (see [1]), otherwise a debugger erroneously blocks a child process in a trace status until gdb exit.
In the glibc [2] this macro expansion is the same for all architectures.
Is this a gdb or uClibc-ng bug?
1. https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git; a=blob;f=gdb/linux-nat.c;h=445b59fa4adadbb2890a9e2debffb5 330f1e09e4;hb=HEAD#l497 2. https://sourceware.org/git/gitweb.cgi?p=glibc.git;a=blob; f=bits/waitstatus.h;h=a1c232612cd13e758f222ade6b27bc2c85ab8f8f;hb=HEAD#l44
Hio Sergey,
it was added with this commit by Denys: 4a96b948687166da26a6c327e6c6733ad2336c5c
Denys, do you remember why?
best regards Waldemar
Sergey Korolev wrote,
Does anyone know why __WIFSTOPPED macro redefined for MIPS architecture as
#if !defined(__mips__) #define __WIFSTOPPED(status) (((status) & 0xff) == 0x7f) #else #define __WIFSTOPPED(status) (((status) & 0xff) == 0x7f && ((status) & 0xff00)) #endif
?
The problem with this definition is in that newer gdb versions (>= 7.0) expect that WIFSTOPPED(W_STOPCODE(0)) is true (see [1]), otherwise a debugger erroneously blocks a child process in a trace status until gdb exit.
In the glibc [2] this macro expansion is the same for all architectures.
Is this a gdb or uClibc-ng bug?
1. https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob;f=gdb/ linux-nat.c;h=445b59fa4adadbb2890a9e2debffb5330f1e09e4;hb=HEAD#l497 2. https://sourceware.org/git/gitweb.cgi?p=glibc.git;a=blob;f=bits/ waitstatus.h;h=a1c232612cd13e758f222ade6b27bc2c85ab8f8f;hb=HEAD#l44
devel mailing list devel@uclibc-ng.org https://mailman.uclibc-ng.org/cgi-bin/mailman/listinfo/devel
On Sun, Jun 10, 2018 at 7:20 PM, Waldemar Brodkorb wbx@uclibc-ng.org wrote:
Hio Sergey,
it was added with this commit by Denys: 4a96b948687166da26a6c327e6c6733ad2336c5c
Denys, do you remember why?
Yes.
status 00xx means "killed by signal xx". status yy7F means "stopped by signal yy".
status 007F means "killed by signal 0x7f", not "stopped by signal 0" (the latter does not make sense since signal 0 does not exist).
Does anyone know why __WIFSTOPPED macro redefined for MIPS architecture as
#if !defined(__mips__) #define __WIFSTOPPED(status) (((status) & 0xff) == 0x7f) #else #define __WIFSTOPPED(status) (((status) & 0xff) == 0x7f && ((status) & 0xff00)) #endif
The __WIFSTOPPED(status) (((status) & 0xff) == 0x7f) would not work correctly for status of 007F. This is only important for the single arch (mips) which has signal numbers >64.
Looks like gdb makes an assumption which is invalid for mips arch.
-
Denys Vlasenko -
Sergey Korolev -
Waldemar Brodkorb