Re: Strange output of gcc -E on GNU/Hurd
Hi! On Sun, 15 Jul 2012 16:32:06 -0400, Barry deFreese bdefre...@debian.org wrote: In looking at libprelude it generates a lot of files using gawk. The attached file is generated from gawk and then is run through gcc -E. On GNU/Hurd, I get significantly different results than I do from GNU/Linux. Anyone have a clue why that might be or where I would look to debug this? What errors do you get? Grüße, Thomas pgp2BZ3rneewW.pgp Description: PGP signature
Re: Strange output of gcc -E on GNU/Hurd
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 7/16/2012 3:43 AM, Thomas Schwinge wrote:
Hi!
On Sun, 15 Jul 2012 16:32:06 -0400, Barry deFreese bdefre...@debian.org
wrote:
In looking at libprelude it generates a lot of files using gawk. The
attached file is
generated from gawk and then is run through gcc -E.
On GNU/Hurd, I get significantly different results than I do from GNU/Linux.
Anyone have a
clue why that might be or where I would look to debug this?
What errors do you get?
Grüße, Thomas
Thomas,
I'm not getting any errors it is just that the output is so radically different
that the package
that processes the output files is having problems.
Attached is foo.h processed by both hurd and linux.
Thanks,
Barry
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAlAEJFcACgkQ5ItltUs5T34pgQCeLut92VjadzC52/NhPwHM/glA
yHoAoPVZ161+tcOqRXGUiVcjutWXv4u1
=ytC2
-END PGP SIGNATURE-
# 1 foo.h
# 1 command-line
# 1 foo.h
# 25 foo.h
# 1 /usr/include/errno.h 1 3 4
# 29 /usr/include/errno.h 3 4
# 1 /usr/include/features.h 1 3 4
# 323 /usr/include/features.h 3 4
# 1 /usr/include/i386-gnu/bits/predefs.h 1 3 4
# 324 /usr/include/features.h 2 3 4
# 356 /usr/include/features.h 3 4
# 1 /usr/include/i386-gnu/sys/cdefs.h 1 3 4
# 359 /usr/include/i386-gnu/sys/cdefs.h 3 4
# 1 /usr/include/i386-gnu/bits/wordsize.h 1 3 4
# 360 /usr/include/i386-gnu/sys/cdefs.h 2 3 4
# 357 /usr/include/features.h 2 3 4
# 388 /usr/include/features.h 3 4
# 1 /usr/include/i386-gnu/gnu/stubs.h 1 3 4
# 1 /usr/include/i386-gnu/bits/wordsize.h 1 3 4
# 5 /usr/include/i386-gnu/gnu/stubs.h 2 3 4
# 1 /usr/include/i386-gnu/gnu/stubs-32.h 1 3 4
# 8 /usr/include/i386-gnu/gnu/stubs.h 2 3 4
# 389 /usr/include/features.h 2 3 4
# 30 /usr/include/errno.h 2 3 4
# 1 /usr/include/i386-gnu/bits/errno.h 1 3 4
# 10 /usr/include/i386-gnu/bits/errno.h 3 4
enum __error_t_codes
{
EPERM = ((0x10 26) | ((1) 0x3fff)),
ENOENT = ((0x10 26) | ((2) 0x3fff)),
ESRCH = ((0x10 26) | ((3) 0x3fff)),
EINTR = ((0x10 26) | ((4) 0x3fff)),
EIO = ((0x10 26) | ((5) 0x3fff)),
ENXIO = ((0x10 26) | ((6) 0x3fff)),
E2BIG = ((0x10 26) | ((7) 0x3fff)),
ENOEXEC = ((0x10 26) | ((8) 0x3fff)),
EBADF = ((0x10 26) | ((9) 0x3fff)),
ECHILD = ((0x10 26) | ((10) 0x3fff)),
EDEADLK = ((0x10 26) | ((11) 0x3fff)),
ENOMEM = ((0x10 26) | ((12) 0x3fff)),
EACCES = ((0x10 26) | ((13) 0x3fff)),
EFAULT = ((0x10 26) | ((14) 0x3fff)),
ENOTBLK = ((0x10 26) | ((15) 0x3fff)),
EBUSY = ((0x10 26) | ((16) 0x3fff)),
EEXIST = ((0x10 26) | ((17) 0x3fff)),
EXDEV = ((0x10 26) | ((18) 0x3fff)),
ENODEV = ((0x10 26) | ((19) 0x3fff)),
ENOTDIR = ((0x10 26) | ((20) 0x3fff)),
EISDIR = ((0x10 26) | ((21) 0x3fff)),
EINVAL = ((0x10 26) | ((22) 0x3fff)),
EMFILE = ((0x10 26) | ((24) 0x3fff)),
ENFILE = ((0x10 26) | ((23) 0x3fff)),
ENOTTY = ((0x10 26) | ((25) 0x3fff)),
ETXTBSY = ((0x10 26) | ((26) 0x3fff)),
EFBIG = ((0x10 26) | ((27) 0x3fff)),
ENOSPC = ((0x10 26) | ((28) 0x3fff)),
ESPIPE = ((0x10 26) | ((29) 0x3fff)),
EROFS = ((0x10 26) | ((30) 0x3fff)),
EMLINK = ((0x10 26) | ((31) 0x3fff)),
EPIPE = ((0x10 26) | ((32) 0x3fff)),
EDOM = ((0x10 26) | ((33) 0x3fff)),
ERANGE = ((0x10 26) | ((34) 0x3fff)),
EAGAIN = ((0x10 26) | ((35) 0x3fff)),
EINPROGRESS = ((0x10 26) | ((36) 0x3fff)),
EALREADY = ((0x10 26) | ((37) 0x3fff)),
ENOTSOCK = ((0x10 26) | ((38) 0x3fff)),
EMSGSIZE = ((0x10 26) | ((40) 0x3fff)),
EPROTOTYPE = ((0x10 26) | ((41) 0x3fff)),
ENOPROTOOPT = ((0x10 26) | ((42) 0x3fff)),
EPROTONOSUPPORT = ((0x10 26) | ((43) 0x3fff)),
ESOCKTNOSUPPORT = ((0x10 26) | ((44) 0x3fff)),
EOPNOTSUPP = ((0x10 26) | ((45) 0x3fff)),
EPFNOSUPPORT = ((0x10 26) | ((46) 0x3fff)),
EAFNOSUPPORT = ((0x10 26) | ((47) 0x3fff)),
EADDRINUSE = ((0x10 26) | ((48) 0x3fff)),
EADDRNOTAVAIL = ((0x10 26) | ((49) 0x3fff)),
ENETDOWN = ((0x10 26) | ((50) 0x3fff)),
ENETUNREACH = ((0x10 26) | ((51) 0x3fff)),
ENETRESET = ((0x10 26) | ((52) 0x3fff)),
ECONNABORTED = ((0x10 26) | ((53) 0x3fff)),
ECONNRESET = ((0x10 26) | ((54) 0x3fff)),
ENOBUFS = ((0x10 26) | ((55) 0x3fff)),
EISCONN = ((0x10 26) | ((56) 0x3fff)),
ENOTCONN = ((0x10 26) | ((57) 0x3fff)),
EDESTADDRREQ = ((0x10 26) | ((39) 0x3fff)),
ESHUTDOWN = ((0x10 26) | ((58) 0x3fff)),
ETOOMANYREFS = ((0x10 26) | ((59) 0x3fff)),
ETIMEDOUT = ((0x10 26) | ((60) 0x3fff)),
ECONNREFUSED = ((0x10 26) | ((61) 0x3fff)),
ELOOP = ((0x10 26) | ((62) 0x3fff)),
ENAMETOOLONG = ((0x10 26) | ((63) 0x3fff)),
EHOSTDOWN = ((0x10 26) | ((64) 0x3fff)),
EHOSTUNREACH = ((0x10 26) | ((65) 0x3fff)),
ENOTEMPTY = ((0x10 26) | ((66) 0x3fff)),
EPROCLIM = ((0x10 26) | ((67) 0x3fff)),
EUSERS = ((0x10 26) | ((68) 0x3fff)),
EDQUOT = ((0x10 26) | ((69) 0x3fff)),
Re: Strange output of gcc -E on GNU/Hurd
Hi Barry!
On Mon, 16 Jul 2012 10:25:27 -0400, Barry deFreese bdefre...@verizon.net
wrote:
On 7/16/2012 3:43 AM, Thomas Schwinge wrote:
On Sun, 15 Jul 2012 16:32:06 -0400, Barry deFreese bdefre...@debian.org
wrote:
In looking at libprelude it generates a lot of files using gawk. The
attached file is
generated from gawk and then is run through gcc -E.
On GNU/Hurd, I get significantly different results than I do from
GNU/Linux. Anyone have a
clue why that might be or where I would look to debug this?
What errors do you get?
I'm not getting any errors it is just that the output is so radically
different that the package
that processes the output files is having problems.
OK -- so a later compilation stage is choking on this and thus emitting
error messages?
Attached is foo.h processed by both hurd and linux.
Hurd:
enum __error_t_codes
{
EPERM = ((0x10 26) | ((1) 0x3fff)),
((0x10 26) | ((1) 0x3fff)) PRELUDE_ERROR_EPERM
Linux:
1 PRELUDE_ERROR_EPERM
So i'm guessing that either the later compilation stage is choking on the
presence of the Hurd version's enum definition, or on the Hurd's
pecularity of E* values and thus the PRELUDE_ERROR_* values not being
simple numerals. Whatever it is (and whatever that code is being used
for...) it needs to be extended to cope with this.
Grüße,
Thomas
pgpPGD1tZikrW.pgp
Description: PGP signature
Re: [PATCH] VM cache policy change.
Hi! On Tue, 10 Jul 2012 03:03:09 +0200, Richard Braun rbr...@sceen.net wrote: On Mon, Jul 09, 2012 at 04:44:57PM +0200, Richard Braun wrote: Note that you need up-to-date versions of both GNU Mach [1] and the Hurd [2] to test this patch, as it needs important bug fixes to avoid file system crashes and kernel panics. Debian packages with the patch and the required bug fixes are available at my repository : deb http://ftp.sceen.net/debian-hurd experimental/ deb-src http://ftp.sceen.net/debian-hurd experimental/ They are currently used on the public hurd box darnassus.sceen.net. Here is what I see for my testload going from originally gnumach-image-1.3.99-486-dbg version 2:1.3.99.dfsg.git20120710-1 to your 2:1.3.99.dfsg.git20120710-1+rbraun.1 (»VM cache policy change.« from »Tue, 10 Jul 2012 19:00:46 +0200«). Unfortunately, performance regresses for me -- hopefully we can figure out why. The testload is for glibc: »make make install make check« after a fresh boot. 2:1.3.99.dfsg.git20120710-1 2:1.3.99.dfsg.git20120710-1+rbraun.1 make100 min 170 min make install15 min 17 min make check 54 min 81 min The baseline numbers have been stable (with minor variance) for a lot of previous builds, here confirmed for two runs, the +rbraun.1 numbers have also been essentially stable for two runs. The logs of the three steps are completely equivalent for the 2:1.3.99.dfsg.git20120710-1 and +rbraun.1 builds. The system is an AMD Athlon XP with 1466 MHz, has 1 GiB of RAM, and is running Debian GNU/Hurd unstable x86 with most packages from around 2012-02, and GNU Mach, hurd* (and netdde), libc0.3* current. I have logs for »ps -w 0 -AF hurd-long«, »vmstat«, »slabinfo« for all runs, directly after booting, and some time after the glibc »make check«, please tell me which you'd like to see; it's a lot of data already. Grüße, Thomas pgpUemcmw0fOY.pgp Description: PGP signature
Re: [PATCH] VM cache policy change.
On Mon, Jul 16, 2012 at 10:30:23PM +0200, Thomas Schwinge wrote: I have logs for »ps -w 0 -AF hurd-long«, »vmstat«, »slabinfo« for all runs, directly after booting, and some time after the glibc »make check«, please tell me which you'd like to see; it's a lot of data already. Thanks for this report. The results of vmstat and slabinfo (vm_object, thread and ipc_port lines) are what I'm mostly interested in. I suspect there are quite a lot of them, and the performance regression probably comes from the scalability issues previously described. -- Richard Braun
Re: [PATCH] VM cache policy change.
Hi! On Mon, 16 Jul 2012 22:44:33 +0200, Richard Braun rbr...@sceen.net wrote: On Mon, Jul 16, 2012 at 10:30:23PM +0200, Thomas Schwinge wrote: I have logs for »ps -w 0 -AF hurd-long«, »vmstat«, »slabinfo« for all runs, directly after booting, and some time after the glibc »make check«, please tell me which you'd like to see; it's a lot of data already. Thanks for this report. And, first and foremost, thanks to you for working on this topic! One thing that comes to mind, by the way, is that the original Debian and your patched package have been built in different environments, by different compilers, so the comparison between them is not completely unbiased, but probably (hopefully!) that shouldn't affect the results very much. The results of vmstat and slabinfo (vm_object, thread and ipc_port lines) are what I'm mostly interested in. I suspect there are quite a lot of them, and the performance regression probably comes from the scalability issues previously described. As you asked on IRC, I'm simply attaching a tarball containing all the log files, also a few from an earlier 2:1.3.99.dfsg.git20120219-1 run (with older hurd* and libc0.3* packages, too, and without netdde), in case that might be interesting too. Please ask if there is anything unclear about which file is which. Also I'm happy to run further tests -- I'll leave the system in the current state. Grüße, Thomas vm_cache_policy_logs.tar.gz Description: Binary data pgpF2xsapONdC.pgp Description: PGP signature
