Initial support for GNU/Hurd#2088
Conversation
|
How many more changes will be needed for this? This looks fairly minimal, but Hurd is not in our support matrix, and we don't test against it. So it may be accidentally broken again by future changes. To evaluate whether or not this is a good idea, it would be good to see the full scope of the necessary changes. The more you need to touch, the less likely it is to be stable |
It is mostly this; I just rebased this PR with an additional fix for As for things to do:
My plan is to send changes for each separately, so it is easier to review them.
That is fine for me. Once abseil is changed to build/work on the Hurd, I do not expect a constant stream of changes to keep it up-to-date -- followup fixes should be easy to do and to review (IMHO). |
|
I think for something like this it might be easier to review it in totality. My worry is that we accept this PR (which seems pretty minimal) and then the next one seems too invasive. |
Tweak configuration & tests so that most of abseil works on the Hurd:
- enable available TLS ("__thread", in practice)
- enable available mmap
- enable available POSIX semaphores
- enable available POSIX write()
- disable the ELF symbolizer: while the object format is ELF, the
symbolizer uses bits (i.e. "mmap" files in /proc) not currently
available
- use the available /proc/self/exe
- tweak a log test for the different value of EBADF
- tweak the strerror test for the GNU libc Hurd string representation
of -1
Sorry for the late answer. I checked a bit more, and I think this is the biggest set of changes needed for the the Hurd. Hence it should be ready for review. |
| ValueWithStr(Eq("Bad file descriptor"))), | ||
| ValueWithLiteral(Eq(" [")), | ||
| AnyOf(ValueWithStr(Eq("8")), ValueWithStr(Eq("9"))), | ||
| AnyOf(ValueWithStr(Eq("8")), ValueWithStr(Eq("9")), ValueWithStr(Eq("1073741833"))), |
There was a problem hiding this comment.
This feels a little magical, where does this number come from?? Do we need tests to pass on Hurd? We don't run these in CI anyway and they're likely to backslide, so I'd be tempted to say we should revert all these test changes
There was a problem hiding this comment.
This feels a little magical, where does this number come from??
It's simply the decimal value of EBADF, as I wrote in the commit/PR message:
tweak a log test for the different value of
EBADF
In the Hurd implementation of GNU libc, the POSIX errnos start at 0x40000001 (the first). This is because there are different ranges of error values, and the POSIX values are one of those ranges (in addition to e.g. the Mach errors, IPC errors, etc).
$ grep -r EBADF /usr/include/i386-gnu/
/usr/include/i386-gnu/bits/errno.h: EBADF = 0x40000009, /* Bad file descriptor */
/usr/include/i386-gnu/bits/errno.h:#define EBADF 0x40000009
$ errno EBADF
EBADF 1073741833 Bad file descriptor
See also the GNU libc Hurd sources: https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/mach/hurd/bits/errno.h;h=3b54f5855e21091123ab0669402550968f0746cf;hb=d70dd7d72273ac1aa53b435156de3f50f0c5a868#l37
There was a problem hiding this comment.
Yea my larger point is: is there any significant value to submitting fixes to get tests working on Hurd? I get that it was useful to produce this PR, but you only need the prod code to work right?
The test changes seem particularly confusing without context, and like they (marginally) weaken the tests in the platforms we do support.
The non-test changes all look fine to me
3 participants
Tweak configuration & tests so that most of abseil works on the Hurd:
__thread, in practice)write()mmapfiles in/proc) not currently available/proc/self/exeEBADF-1