glibc: ELF_MACHINE_USER_ADDRESS_MASK, sysdeps/mach/hurd/dl-sysdep.c:fmh
Hi Roland! Richard et moi, we wondered what ELF_MACHINE_USER_ADDRESS_MASK »Mask identifying addresses reserved for the user program, where the dynamic linker should not map anything.«, the reason for it usage in sysdeps/mach/hurd/dl-sysdep.c:__mmap for vm_map's mask argument (but not in sysdeps/mach/hurd/mmap.c:__mmap which addmittedly is not »the dynamic linker«, so...), and then especially sysdeps/mach/hurd/dl-sysdep.c:fmh »XXX loser kludge for vm_map kernel bug« are all about. You added that in commit 5bf62f2d3a8af353fac661b224fc1604d4de51ea (well, wy before someone would speak about Git commits), and later touched it in commit 9ce8b3c817156108b9f1a1cf12a3fa6eb4332f11. Grüße, Thomas pgpYDn5pJI7sR.pgp Description: PGP signature
[Bug hurd/3665] errno 118 assigned twice (ECANCELED and ENOTSUP)
http://sourceware.org/bugzilla/show_bug.cgi?id=3665 Thomas Schwinge tschwinge at sourceware dot org changed: What|Removed |Added Status|NEW |RESOLVED CC||tschwinge at sourceware dot ||org Resolution||FIXED AssignedTo|roland at gnu dot org |tschwinge at sourceware dot ||org --- Comment #6 from Thomas Schwinge tschwinge at sourceware dot org 2012-11-04 21:21:39 UTC --- commit d6d98dea2d97e1dee5ab727982dd7430873c836f Author: Samuel Thibault samuel.thiba...@ens-lyon.org AuthorDate: Sun Jul 22 13:50:04 2007 +0200 Commit: Thomas Schwinge tho...@codesourcery.com CommitDate: Sun Nov 4 22:15:29 2012 +0100 [BZ #3665] Regenerate sysdeps/mach/hurd/bits/errno.h. -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug hurd/5246] Patches to fix glibc 2.7 on Hurd
http://sourceware.org/bugzilla/show_bug.cgi?id=5246 Thomas Schwinge tschwinge at sourceware dot org changed: What|Removed |Added Status|NEW |RESOLVED CC||tschwinge at sourceware dot ||org Resolution||FIXED AssignedTo|roland at gnu dot org |tschwinge at sourceware dot ||org --- Comment #7 from Thomas Schwinge tschwinge at sourceware dot org 2012-11-04 21:02:15 UTC --- __CPU_ALLOC_SIZE issue (attachment 2076) has been fixed in commit 2b7e92df930b8ed1ace659bf6e0b8dff41d65bf0. __strtoul_internal issue (attachment 2077) has been fixed in commit 10589b4adb212dfde20670aacfb76aa842f42b92. Last occurrences of PTR_MANGLE/PTR_DEMANGLE have been conditionalized in commit e10bb1072cf11e52aad85d59673da86aeafd1b47 making attachment 2085 obsolete. -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
GCC for GNU Hurd: MACH built-in preprocessor macro (was: gdb: FTBFS on hurd-i386 (for review))
Hi!
On Fri, 28 Sep 2012 09:56:41 +0200, Samuel Thibault samuel.thiba...@gnu.org
wrote:
Thomas Schwinge, le Thu 27 Sep 2012 09:15:23 +0200, a écrit :
On Wed, 26 Sep 2012 16:02:29 +0200, Svante Signell
svante.sign...@telia.com wrote:
gdb does not build from source any longer since gdb-multiarch packages
was enabled in 7.4.1-1. The build problems are due to two reasons:
I also once had a look and came to the same conclusion.
First the reserved keyword MACH is defined in include/objcode/h8300.h
causing problems since gcc defines it for GNU/Hurd.
Correct. And I wonder if that isn't a name-space violation? This is
what I meant to look up when working on this two months ago, but then it
seems I again got distracted by other issues. Roland, do you have any
comments regarding that?
[GCC]/gcc/config/gnu.h:
[...]
#undef GNU_USER_TARGET_OS_CPP_BUILTINS
#define GNU_USER_TARGET_OS_CPP_BUILTINS() \
do {\
builtin_define (__gnu_hurd__);\
builtin_define (__GNU__); \
builtin_define_std (unix);\
builtin_define_std (MACH);\
builtin_assert (system=gnu); \
builtin_assert (system=mach); \
builtin_assert (system=unix); \
builtin_assert (system=posix);\
} while (0)
$ gcc -dM -E -x c - /dev/null | grep -i mach
#define __MACH 1
#define __MACH__ 1
#define MACH 1
On Linux i386, both linux and i386 macros are defined, which poses
its own problems too.
(Let's pause for a moment in remembrance of the »glibc vs. i686 defined«
issue that would nearly have seen its 10th anniversary these days.)
I'd indeed tend to say that defining a non-underscored macro is only a
way for troubles.
Could we/should we remove the latter one? Though, I have no idea how
much user code is relying on MACH being #defined. I had a colleague
check, and Apple/Darwin systems do *only* #define __MACH__ (as well as
__APPLE__).
Here is the straightforward patch. With it, only the __MACH__ built-in
preprocessor macro remains, and we get:
[...]
Fixing headers into /home/thomas/tmp/gnu-0/obj/gcc/gcc/include-fixed for
i686-pc-gnu target
-Forbidden identifiers: MACH i386 unix
+Forbidden identifiers: i386 unix
[...]
These two are to remain.
diff --git gcc/config/gnu.h gcc/config/gnu.h
index dddbcbf..4d9449e 100644
--- gcc/config/gnu.h
+++ gcc/config/gnu.h
@@ -34,7 +34,7 @@ along with GCC. If not, see http://www.gnu.org/licenses/.
builtin_define (__gnu_hurd__);\
builtin_define (__GNU__); \
builtin_define_std (unix);\
- builtin_define_std (MACH);\
+ builtin_define (__MACH__);\
builtin_assert (system=gnu); \
builtin_assert (system=mach); \
builtin_assert (system=unix); \
Samuel, is there any way you can unpack all Debian source packages on a
Debian machine, and run a recursive grep command (I can work out a
suitable regex) to see where removing the MACH or __MACH built-in
preprocessor macros might cause trouble?
Grüße,
Thomas
pgpEwHYhuMTBW.pgp
Description: PGP signature
