Re: gdb and PIE binaries

AFAIK gdb does not use fancy information like file-mapping stuff. NT_FILE is probably hard to support on the Hurd, since we don't have a way to go backwards from a memory object port to a file (let alone a file name). All GDB needs is to know where the PIE was loaded, so it can find the DT_DEBUG

Re: [PATCH] getauxval: fix crash on systems without HAVE_AUX_VECTOR

> On 02 Apr 2016 12:57, Samuel Thibault wrote: > > Systems without HAVE_AUX_VECTOR have GLRO(dl_auxv) == NULL, and > > getauxval would thus crash. > > assuming this is for GNU/hurd Yes. > should this just be under HAVE_AUX_VECTOR ? seems like we shouldn't > even bother defining/exporting

Re: Dangerous use of alloca

I don't know where the notion expressed in the Linux man page came from. I'm pretty sure it's never been true of GNU compilers. I don't think there is any actual problem of the sort you have in mind with the existing code. The generally issue of unbounded stack allocation is of course separate

Re: [PATCH] hurd: Define and pass UTIME_NOW and UTIME_OMIT to new file_utimens RPC

Don't repeat all that code. Make a shared helper function _hurd_futimens or suchlike. > 2015-09-20 Fl?vio Cruz > > Define and pass UTIME_NOW and UTIME_OMIT to new file_utimens RPC. > > * sysdeps/mach/hurd/bits/stat.h (UTIME_NOW, UTIME_OMIT): New macros. No

Re: [PATCH] Check sysheaders when looking for Mach and Hurd headers

That looks OK to me.

Re: Question with moving mount/umount logic in glibc

The grepping doesn't tell us whether those programs are using the interface in a way that's actually useful (either at all or specifically in the Hurd context). If the motivation is just to get more sloppily-written programs to compile out of the box, then a header that defines away the functions

Re: Question with moving mount/umount logic in glibc

Frankly I think it would be better to keep these single-caller interfaces out of libc proper. It's not really ideal that they are there for Linux either, but syscall stubs are less of an issue than real code.

Re: Static binaries and nss (dlopen actually)

The short answer is that it's pretty well hopeless. For the Hurd you really really do not want to use static linking. Because of the structure of the system, it's much like having a quarter or third of the Linux kernel baked into each application binary. On Linux and other Unix-like systems, we

Re: Server delegation (fsys_forward)

Indeed the purpose is to avoid the overhead of many processes that are all nearly identical. Obviously there is some sacrifice of the traditional compartmentalization that the whole multi-server model gives you. So it's wise to use it for translators that are relatively simple and thus

Re: Static binaries and nss (dlopen actually)

Roland McGrath, le Wed 18 Feb 2015 16:40:06 -0800, a ?crit : The short answer is that it's pretty well hopeless. Ok, that's what I was feeling, thanks for the confirmation :) Note this also means that features like dynamic linker namespaces and audit modules are essentially unusable

Re: [PATCH] Fix connect/sendto/sendmsg into making sure to ignore bytes beyond sockaddr length

Thanks Tanaka Akira for the report. General glibc policy is that if a bug was user-visible (i.e. observable in a user program that was not itself using undefined behavior, etc.) then there should be a bugzilla item filed for it. That BZ# should then be in the ChangeLog entry. --- /dev/null

Re: [PATCH] hurd: Fix F_*LK* fcntl with __USE_FILE_OFFSET64

+# define F_GETLK 7 /* Get record locking info. */ +# define F_SETLK 8 /* Set record locking info (non-blocking). */ +# define F_SETLKW9 /* Set record locking info (blocking). */ +#endif +#define F_GETLK64 10 /* Get

Re: [PATCH] hurd: add TLS support

--- a/csu/libc-start.c +++ b/csu/libc-start.c @@ -189,10 +189,12 @@ LIBC_START_MAIN (int (*main) (int, char **, char ** MAIN_AUXVEC_DECL), /* Perform IREL{,A} relocations. */ apply_irel (); +#ifndef __GNU__ /* Initialize the thread library at least a bit since the libgcc

Re: [PATCH 7/7] procfs: provide magic retry response for /proc/self

+ proc/self/... means replace `proc/self' with the PID of the current +process and then retry as for FS_RETRY_NORMAL. Roland, does it look OK to use a FS_RETRY_MAGICAL for implementing /proc/self? FS_RETRY_MAGICAL is appropriate. But the string itself should more

Re: [PATCH,Hurd] Fix F_*LK* fcntl with __USE_FILE_OFFSET64

2014-08-31 Samuel Thibault samuel.thiba...@ens-lyon.org struct flock64 uses 64bit values. This introduces other values for F_GETLK, F_SETLK, F_SETLKW to distinguish between both. * sysdeps/mach/hurd/bits/fcntl.h (F_GETLK64, F_SETLK64, F_SETLKW64): New No blank

Re: [PATCH,Hurd] Fix hang on fork

Fix comment formatting, put space before paren, write a ChangeLog entry.

Re: [PATCH,Hurd] bind() fails when umask is 0777

+ if (! err) + if (doretry != FS_RETRY_NORMAL || retryname[0] != '\0') + err = EADDRINUSE; Please use a simple expression rather than a nested if here. + /* Get the address port. */ + err = __ifsock_getsockaddr (ifsock, aport); +

Re: [PATCH,Hurd] bind() fails when umask is 0777

That looks fine. I don't think anybody cares about the freeze for Hurd-only code, so go ahead and commit it.

Re: [PATCH,Hurd] bind() fails when umask is 0000

I assume you mean umask is 0666 or more, such that (0600 ~umask) is 0. The fix to use dir_lookup of to invoke the active translator seems correct and orthogonal to the umask issue. What that fixes is a race where you could wind up with a different node than the one you just created, if the

Re: glibc preparation patch for lockf support in Hurd

If we were starting from scratch, we'd use 64-bit types unconditionally. But given that we already have off_t that is sometimes 32 bits, we should be consistent with the other systems that have this distinction. That means F_GETLK64 should be a different value from F_GETLK in the ABI, and F_GETLK

Re: glibc preparation patch for lockf support in Hurd

Ok, so that will be something like this. Yes.

Re: Small test example for: cannot create /dev/null: Interrupted system call

On Mon, Jul 07, 2014 at 01:29:20PM +0200, Svante Signell wrote: ./test.sh: 6: ./test.sh: cannot create /dev/null: Interrupted system All right, it looks like open() gets interrupted by SIGCHLD here. It's my understanding that signal handling is highly system-specific in such cases, but we

Re: GSOC - valgrind-hurd queries

POSIX specifies that setting SA_NOCLDWAIT in sigaction.sa_flags for SIGCHLD has the same effect on wait* behavior as using SIG_IGN for sigaction.sa_handler for SIGCHLD. So, by POSIX rules you can just as well use SIG_IGN if you do not care to actually handle the signal. However, the Hurd does

Re: Bug#752237: libc0.3: send() asked to transmit 0 chars still triggers recv() on Hurd

I'm inclined to say libc is not the right place to fix this. If the user says write/send 0, what that means should be up to the io server to decide--even if all the servers we have today are intending to implement the same POSIX semantics.

Re: Conflicting ‘thread_info_t’ declaration between nscd and Mach

Send a patch upstream to libc to avoid using the *_t name space for non-public type names like the one in nscd. We'll take it.

Re: [PATCH 1/3] Add a new exec_exec_file_name RPC

I am still not convinced this is the ideal solution for Hurdiness. But I'm not putting the time and effort into figuring out other alternatives and what's adequate for what needs. You shouldn't let me stand in the way of Hurd design changes, since I'm not actually working on it this decade. If

Re: [PATCHv2,HURD] Add fork hooks for pthread_atfork

Roland McGrath, le Fri 20 Dec 2013 13:05:42 -0800, a

Re: Hurd: /lib/ld.so vs. /lib/ld.so.1 (was: Policy: Require new dynamic loader names for entirely new ABIs?)

For x86 Hurd, GCC has been specifying »-dynamic-linker /lib/ld.so« in LINK_SPEC since forever (1995, or earlier), and Debian glibc has had the following since forever (2002, or earlier): ifeq ($(DEB_HOST_GNU_SYSTEM),gnu) # Why doesn't the glibc makefile install this? ln

Re: [PATCH v16] kern: simple futex for gnumach

This is why I was insisting on passing *memory* through IPC. It's not at all clear that makes any kind of sense, unless you mean something I haven't imagined. Can you be specific about exactly what the interface (say, a well-commented MiG .defs fragment) you have in mind would look like? If

Re: glibc: ELF_MACHINE_USER_ADDRESS_MASK, sysdeps/mach/hurd/dl-sysdep.c:fmh

Hi Roland! Hi Thomas of the past! I'm culling old unanswered messages and I can't always tell which ones are still relevant. So ignore if not helpful. Richard et moi, we wondered what ELF_MACHINE_USER_ADDRESS_MASK »Mask identifying addresses reserved for the user program, where the dynamic

Re: [PATCHv2,HURD] Add fork hooks for pthread_atfork

The linker is supposed to define those symbols automagically. Did it break?

Re: llvm / clang / scan-build of the Hurd

Unless I'm mistaken, their semantics imply executable stacks, You are mistaken. Only certain kinds of uses require that. There are no such uses in libc, for example.

Re: llvm / clang / scan-build of the Hurd

Clang does not support nested functions [1], and there is no plan to support them upstream. As such, any file that uses nested functions (or any gcc extension not supported by clang) is excluded from the analysis (see e.g. [2]). Richard has no special love for them, iiuc b/c the semantic is

Re: [RFC] kern: simple futex for gnumach

A fundamental feature of futexes is that they are tied to the memory, not the mapping. If there are two mappings of the same shared page, a futex_wake on an offset N into the page from one mapping must wake a futex_wait on an offset N into the page from the other mapping.

Re: [PATCH 1/5] exec: remove support for transparently unbzip2ing executables

Right. The feature is however still somehow interesting, so I prefered to just disable the support by default, so users can easily build their own exec server and set it up for themselves if they wish. Doing this in the exec server was always just a cheap hack because we didn't have a

Re: [PATCH 4/5] exec: Remove #ifdef 0-out code for user specified exec servers.

There was some reason for the EXECSERVERS environment variable and I think it might not have been just because we didn't yet have the various translators (unionfs, etc.) that would make it straightforward to populate a private root directory for such purposes. But I really can't recall any more.

Re: [PATCH 5/5] exec: remove the BFD code

Indeed it was a nice idea to be able to execute any format for free, and it worked great for the most trivial format known to man (a.out). But the fantasy that BFD actually adequately encapsulates all the object format details so you don't need to know them is no more true for the loader than it

Re: [PATCH 3/5] exec: Remove #ifdef 0-out code doing nothing.

Mmm, the comment still looks valid to me. I don't know what else would make sure the dynamic linker doesn't put anything where libc expects to be putting its heap. We need to make sure something does that before dropping such a scary warning. It's the fmh hack in

Re: /hurd/init and /hurd/proc

They are separate because they do different things. This doesn't seem like it should need a lot of justification to Hurd hackers. If you want to roll things together just because you always run them both, maybe you should be hacking on a monolithic kernel instead.

Re: /hurd/init and /hurd/proc

That's not what he said. He said there is a lot of information propagated from init to proc, and thus the separation is questionable. Are you talking about bootstrap, or what?

Re: [rbr...@sceen.net: [PATCH] Make __getclktck return 100 for the Hurd]

This change doesn't make any sense to me. The explanation refers to /proc, which is wholly irrelevant to libc internals.

Re: [rbr...@sceen.net: [PATCH] Make __getclktck return 100 for the Hurd]

The /proc file system is merely an example. Also, it's not internal to libc, since it gets exported through sysconf(_SC_CLK_TCK). You'll have to explain what problem you think there is more thoroughly.

Re: [rbr...@sceen.net: [PATCH] Make __getclktck return 100 for the Hurd]

Basically, top doesn't report correct CPU times. This is caused by sysconf() returning 100 while values read from /proc are true tick counts, hence 100 per second at most. In fact, that is not a true tick count. Most modern Linux kernels have ticks at 1024Hz, for example. The ABI for

Re: [PATCH,HURD] Recognize GNU/Hurd-specific binaries

First, my usual cleanup patch: * sysdeps/unix/sysv/linux/ldsodefs.h (VALID_ELF_OSABI) (VALID_ELF_ABIVERSION, MORE_ELF_HEADER_DATA): Use ELFOSABI_GNU instead of ELFOSABI_LINUX. ports/ChangeLog.arm * sysdeps/unix/sysv/linux/arm/ldsodefs.h (VALID_ELF_OSABI)

Re: __executable_start (was: [bug #17644] glibc: support for TLS)

OK to commit? * sysdeps/mach/hurd/i386/init-first.c (init1): Use __executable_start symbol intsead instead of _start. OK.

Re: [PATCH,HURD] add ST_NOATIME

OK

Re: [PATCH] libdiskfs: expose the ST_NOATIME flag

I'm more inclined to just use things unconditionally and say that you need to update your libc install before you build the Hurd. #ifdef's in the code as if it were really intended to apply to a variety of environments is just icky.

Re: [PATCH] libdiskfs: expose the ST_NOATIME flag

Sure, I just meant might as well wait to do the Hurd change until after everybody who cares is using a libc with the change.

Re: RFC for patch to add task_{set,get}_name RPC

What for? If you want something like this, why does it belong in the microkernel?

Re: RFC for patch to add task_{set,get}_name RPC

So the kernel can tell what a task is in, e.g. show tasks command, in memory object statistics, etc. Without this it is hard to inspect the whole system state without divining what task is what process. The proc server exists to provide that mapping.

Re: RFC for patch to add task_{set,get}_name RPC

But we can't really ask the proc server from the kernel debugger. There are lots of things you can't do from the kernel debugger. That doesn't mean that more state in the microkernel is the way to debug.

Re: RFC for patch to add task_{set,get}_name RPC

When it helps a huge lot to debug some things, it surely is a way to debug. I was able to debug quite a few spurious port deallocations as soon as I was able to print from the kernel which process was doing it. I don't see how to do the same kind of debugging through the proc server. You

Re: [PATCH 3/3] Explicitly link against all utilized libraries

The Hurd API is that these things are available when you just use -lc. So if need be, we should make the installed libc.so linker script do AS_NEEDED ( libmachuser.so.1 libhurduser.so.1 ) or something like that. I'm somewhat confused about what you're doing so that you had an issue, however. How

Re: connect() access bytes after socket address

I agree. I've worked on a patch, pushed to topgit for later submission. I hope you did it by adding a common helper function (or perhaps it needs to be macro declaring a local VLA) for at least the cases other than bind. bind needs to be a little different since it needs to do a split, but still

Re: connect() access bytes after socket address

I didn't bother, but I can indeed, probably to glibc/include/sys/socket.h, or some other file? It's only needed for Hurd, so but it in some non-installed Hurd-only header. (or perhaps it needs to be macro declaring a local VLA) I rather used strndupa, provided by glibc/include/string.h as

Re: connect() access bytes after socket address

Could be. I need to see the full patch changing all the cases to give a real opinion about the details.

Re: connect() access bytes after socket address

I agree they should be consistent. Note that sendto and sendmsg are consistent with connect, rather than with bind.

Re: [PATCH, HURD][RFC] hurdselect: Step7x, almost complete rewrite finished

Then you have to convince the Linux man page and the python3.2 developers too. From python3.2: ./Include/fileobject.h: #define _PyIsSelectable_fd(FD) (((FD) = 0) ((FD) FD_SETSIZE)) The fd value itself has to be FD_SETSIZE, since indexing is zero-origin; so that code is right. The nfds

Re: [PATCH] simplify ulimit implementation

First do a commit that is nothing but the rename. That won't affect any configuration. Then do a commit adding the missing #include (and test it by locally removing the bsd file and doing a Hurd build). Finally, do a commit removing the bsd file. Thanks, Roland

Re: [PATCH,HURD] implement syncfs

The top line of every new file is a descriptive comment. You don't need #include errno.h in that file.

Re: [PATCH,HURD] implement syncfs

+/* Make all changes done to all files on the file system associated + with FD actually appear on disk. */ +int +syncfs (int fd) +{ + /* This is not actually synchronous; we don't wait. */ + error_t err = HURD_DPORT_USE (fd, __file_syncfs (port, 0, 0)); Note that syncfs in

Re: [PATCH] simplify ulimit implementation

sysdeps/posix is appropriate because it's implemented in terms of POSIX interfaces. It's bad to lose any functionality, though __UL_GETMAXBRK actually being used seems a bit unlikely. But it's easy enough to add it. So I'd do: First commit: move file verbatim to sysdeps/posix/. Second commit:

Re: [PATCH,HURD] fix muntrace with mmap-less libio

That change is good but it needs a comment. You don't need to go into great detail, just say that we call fprintf+fclose after clearing the hooks to match how mtrace called fopen+fprintf before setting them. Thanks, Roland

Re: [PATCH,HURD] implement syncfs

That's fine.

Re: [PATCH] simplify ulimit implementation

I don't think losing __UL_GETMAXBRK is really a problem. The reason for removing it was not specific to Linux, just to the implementation being in a shared library. It could be implemented in a shared library, at the cost of a GOT reloc for _etext to get the main executable's value (or

Re: [PATCH,HURD] fix muntrace with mmap-less libio

That is fine as is, though it's preferable to use C99-style inline declarations.

Re: [PATCH,HURD] hurd: compliance fixes for ptsname_r

That looks fine to me.

Re: [PATCH, HURD] ignore Mach kernel headers in check-local-headers.sh

Looks fine.

Re: Rewriting hurdselect.c: How to detect that a file descriptor has disappeared?

The construct used in hurdselect is the mach_msg() function: __mach_msg (msg.head, MACH_RCV_MSG | options, 0, sizeof msg, portset, to, MACH_PORT_NULL) This function call only has parameters set for reading. Can a subsequent call using MACH_SEND_MSG parameters and messages be used to find

Re: [PATCH.HURD] fix fdatasync/fsync if file_sync is not supported

That's fine.

Re: [PATCH.HURD] fix fdatasync/fsync if file_sync is not supported

AIUI, POSIX says there can be other, implementation-defined errors. That's true. But when POSIX specifies a particular error code for a particular condition, then you must yield the specified error code for that situation. If this is arising for something like using a file-oriented call on an

Re: [PATCH,HURD] ptrace: use __hurd_fail for EOPNOTSUPP

OK

Re: [PATCH.HURD] fix fdatasync/fsync if file_sync is not supported

We don't generally handle MIG_BAD_ID. That error indicates a server not implementing the protocol for which it's being used, which is a server bug. If anything, we'd translate that to EGRATUITOUS in the general case, and perhaps to EOPNOTSUPP in particular cases where it's not an ironclad part of

Re: Checks for getcwd(NULL, 0) and get_current_dir_name()

I'm pretty sure we were the first to support that behavior. (GNU has had a strong commitment to avoiding static limits from the beginning.) Not that it matters for choosing a feature macro name. The best names for such things are purely descriptive rather than referring to a system by name

Re: RFC: filesystem-specific pathconf replies

I think you need to explain the rationale more thoroughly. If the only pathconf parameters that might vary by filesystem implementation are ones that libdiskfs has (or can easily have) other information about, then I think it's better not to add this new flexibility. It's just an opportunity for

Re: [PATCH,HURD] getconf: fix the value of _CS_PATH

I don't think /usr/ucb has existed or been in the canonical PATH on modern BSD systems for some years now. I've just verified that the current NetBSD and FreeBSD sources do not use it. So I've just removed sysdeps/unix/bsd/confstr.h instead. Thanks, Roland 2012-10-03 Roland McGrath rol

Re: [PATCH] diskfs/pathconf: handle _PC_2_SYMLINKS

That doesn't look right to me. diskfs_shortcut_symlink means that the filesystem implementation has its own way to store symlinks. A Hurd filesystem supports symlinks either if there is a first-class storage mechanism like that, or if the filesystems supports storing passive translator records

Re: [PATCH,HURD] mknod: allow to create also sockets

To be honest, I was making tst-mknodat.c pass on Hurd; if it does not make sense that mknod can create sockets, then that test should be removed, since all it does is testing the creation of a single socket. I think the intent of the change is to test the mknodat interface, not any

Re: [PATCH,HURD] mknod: allow to create also sockets

What's the point of ever creating a local-domain socket node with mknod? They are created on demand when you use bind.

Re: [PATCH,HURD] mknod: allow to create also sockets

That change looks fine if the test still passes on Linux.

Re: lookup behaviour with root directory

O_DIRECTORY is not part of any Hurd RPC protocol. The implementation in __hurd_file_name_lookup is the only place that's intended to grok it. The problem seems to be in the server dir_lookup code that is skipping leading slashes. I really don't know why that is there at all. If it serves some

Re: PTHREAD_CANCEL_HURD

The problem with that is, if a Hurd server internally calls a function that is a cancellation point, the calling thread will automatically exit before having a chance to reply to the client. A Hurd-specific type should allow the safe use of more standard functions. I see. So the meaning of

Re: PTHREAD_CANCEL_HURD

How would that make Hurd servers behave ? Would client receive the ECANCELED error ? Isn't it better to just completely ignore the cancellation everywhere except where hurd_condition_wait is called, as it is done currently ? That's certainly not what's done currently. hurd_thread_cancel

Re: [PATCH] generic empty __check_native implementation

That's fine. Please commit it. Thanks, Roland

Re: [PATCH,HURD] implement renameat

Make the top line of every new file a descriptive comment. The copyright line goes second. Otherwise that looks fine, so go ahead and commit it with that change. Thanks, Roland

Re: Hurd build system Makeconf

HURDLIBS is for things that are built in that source tree. If you're using a library that comes from the libc install or someplace like that, then -lfoo is the right way to use it.

Re: Warnings about error_t in glibc on GNU/Hurd

Grepping for 'case 0:' shows exactly 8 places where this warning should arise. One of those is the __hurd_fail inline in hurd.h, so that one instance probably generates the warning in many compilations. Most of these are switches with only a few cases where it would be easy to just change them

Re: [PATCH,HURD] sendto: do not crash when addr is NULL

Hm ok, I saw other cases of shadowing by internal subroutines, and assumed it was okay (since inside them you want to refer to the local err instead of the outermost one. It's not the worst thing ever, and we don't compile with -Wshadow. But shadowing is usually a good thing to avoid just to

Re: [PATCH,HURD] sendto: do not crash when addr is NULL

This looks fine to me.

Re: [PATCH, HURD] hurd: recvfrom(): take into account null address ports

The change itself looks fine to me. In a log entry, write a local variable name as FOO rather than `foo'. Thanks, Roland

Re: [PATCH,HURD] _hurd_select: check for invalid parameter values

* hurd/hurdselect.c (_hurd_select): Return EINVAL for negative `timeout' values. Return EINVAL for `nfds' values either negative or greater than FD_SETSIZE. In a log entry, write a local variable name as FOO rather than `foo'. + to = timeout-tv_sec * 1000 + +

Re: [PATCH,HURD] hurd: compliance fixes for getlogin_r

libc code can use C99 freely these days, so use an inline initializing declaration rather than pre-declaring a new variable. Hm ok; is it bad if I leave them as it is, for now? It's not terrible but there is no reason to let new code in that is not in optimal style, and it's trivial to fix

Re: [PATCH,HURD] hurd: compliance fixes for ptsname_r

Ok, I see that its `buf' argument is marked nonnull. I added that check because I saw the gnulib test for it explicitly checking that ptsname_r(fd, NULL, 0) would be properly failing with EINVAL (and the man page even explicitly mention that return value, unlike with basically most of the

Re: [PATCH,HURD] llistxattr + lremovexattr

Those look fine to me.

Re: [PATCH,HURD] comment out PF_LINK/AF_LINK

We don't support AF_CHAOS or AF_IPX either. Programs should just use proper checks for what they use (i.e. an autoconf-style check for 'struct sockaddr_dl' or the header that defines it), rather than #ifdef AF_*. Thanks, Roland

Re: [PATCH,HURD] sendto: do not crash when addr is NULL

That's almost right, but you should avoid calling __mach_port_deallocate if APORT is MACH_PORT_NULL. Also, avoid shadowing the local variable ERR with one of the same name in the subfunction. Thanks, Roland

Re: [PATCH,HURD] sendto: do not crash when addr is NULL

Put the name of a local variable in all caps when mentioning it in the log entry or comments. Initializing ERR at the top is confusingly subtle. Instead, you make the code that actually cares look like: if (addr == NULL || addr-sun_family == AF_LOCAL) err = 0; else

Re: [PATCH,HURD] Add SysV SHM support

I can't see how this patch could apply to the trunk code. Please submit a patch that is verified to do so. 2005-07-11 Marcus Brinkmann mar...@gnu.org Note for the actual commit: we now use the date of merge rather than the original date in the ChangeLog entry. * hurd/Makefile

Re: [PATCH,HURD] hurd: compliance fixes for getgroups

Since I see you already have copyright paperwork and you're doing more than just the one change, would you like to get set up to commit yourself? Given also my contributions so far, I guess that I should better need review for now, no? Everybody needs review. Getting set up to do your

Re: __thread errno (was: [SCM] glibc maintenance branch, tschwinge/Roger_Whittaker, updated. glibc-2.12-3577-g5b1f2ae)

I think the right thing to do is first get abilist data into the tree for the Hurd configuration based on the libc builds that you've used to create a lot of existing binaries. Then check-abi will always tell you if a change is a problem. Thanks, Roland

  1   2   3   4   5   6   7   8   9   10   >