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 a
> 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 dl_aux
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 and
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 blank line there. A C
That looks OK to me.
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
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.
> 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 ar
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
relatively
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
> --- 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 lib
> +# 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 /
I don't have any problem with it on principle or anything, but could you
say exactly what this is fixing in practical terms?
> +#if defined __USE_EXTERN_INLINES && defined _LIBC && !defined NOT_IN_libc
NOT_IN_libc is obsolete. It's now spelled !IS_IN (libc).
Please confirm that you've tested th
> 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
>
> 2014-08-31 Samuel Thibault
>
> 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 line between the (opt
> > + "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 m
> This is what I had put, is some information still missing?
Oh, was that in the message? I must have missed it because I didn't see a
ChangeLog header.
> * sysdeps/mach/hurd/fork.c (__fork): Lock SS->lock around __proc_dostop()
> call.
Don't use () as if it were part of a function name. Othe
Fix comment formatting, put space before paren, write a ChangeLog entry.
That looks fine. I don't think anybody cares about the freeze for
Hurd-only code, so go ahead and commit it.
> + 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)
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 b
> Ok, so that will be something like this.
Yes.
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
> On Thu, Jul 10, 2014 at 02:21:06PM -0700, Roland McGrath wrote:
> > Is the SIGCHLD set with SA_RESTART?
>
> >From what I see, no.
Then potentially getting EINTR from lots of calls is what's expected.
The program should be fixed to use SA_RESTART if it is not expecti
> 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, b
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 not
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.
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.
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 th
You need to take care for the cases that might be (now or in the future)
using ifunc.
> Roland McGrath, le Fri 20 Dec 2013 13:05:42 -0800, a
> 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?
>
> 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 i
> 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 dynami
The linker is supposed to define those symbols automagically.
Did it break?
> 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.
> 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
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.
> 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 sysdeps/mach/hurd/dl-s
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
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.
> 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 transl
> 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?
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.
Split-stack is fundamentally incompatible with __hurd_threadvar_location et
al (and cthreads). We won't ever be able to use split-stack until we
change to a proper thread-pointer-based implementation
(i.e. segment-register based stuff for i386).
> 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
> 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.
This change doesn't make any sense to me. The explanation refers to /proc,
which is wholly irrelevant to libc internals.
> OK to commit?
>
> * sysdeps/mach/hurd/i386/init-first.c (init1): Use
> __executable_start symbol intsead instead of _start.
OK.
> I'd suggest to go with the simple ESUCCESS instead of spending some more
> months ;-) thinking about a "more suitable" name.
That is indisputably reasonable, but I did just find myself spending a few
minutes thinking about what name would be more suitable. ;-)
> + /* Avoid warning: case v
> 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)
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.
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.
OK
> 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.
Y
> 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.
> 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.
What for?
If you want something like this, why does it belong in the microkernel?
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
The history is that I added the EIEIO constant and its perror text
just because I thought of the joke. For that purpose, translations
that are similarly humorous in any culturally meaningful way would be
appropriate. However, we then assigned an actual meaning to EIEIO in
the Hurd, that being "ca
Could be. I need to see the full patch changing all the cases
to give a real opinion about the details.
> 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
> 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
I agree they should be consistent. Note that sendto and sendmsg are
consistent with connect, rather than with bind.
> 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
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
That looks fine to me.
That is fine as is, though it's preferable to use C99-style inline
declarations.
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
conversely
That's fine.
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
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: ad
> > +/* 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 t
The top line of every new file is a descriptive comment.
You don't need #include in that file.
Looks fine.
> 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 t
That's fine.
> 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
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
OK
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
anywa
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 fo
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
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 ge
That change looks fine if the test still passes on Linux.
What's the point of ever creating a local-domain socket node with mknod?
They are created on demand when you use bind.
> 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
particu
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 v
> 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 c
> 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 o
Why add a new cancellation type? PTHREAD_CANCEL_DEFERRED is already fine.
You just need an extension function that is like pthread_testcancel but
clears and returns the state instead of triggering cancellation handlers.
That's fine. Please commit it.
Thanks,
Roland
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
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.
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 to
Those look fine to me.
In a log entry, write a local variable name as FOO rather than `foo'.
Write 'remaining != NULL' in tests. Fix the existing cases while you're
there.
If the second __gettimeofday calls, return failure as it did before.
Since I've just seen it repeated here and in your select change, it seems
wor
> 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
> > 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 t
> * 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 +
1 - 100 of 1261 matches
Mail list logo
