| Age | Commit message (Collapse) | Author |
|---|
|
The last uses of PTHREAD_IN_LIBC is where it should have been
__PTHREAD_NPTL/HTL. The latter was not conveniently available everywhere.
Defining it from config.h makes things simpler.
|
|
The canonical lock ordering for stream list processing is
locking list_all_lock first, then individual streams as needed.
The fclose implementation reversed that, and the freopen
implementation performed list operations under the reverse order,
too.
Unlinking in fclose was already unconditional, and the early unlinking
looks unnecessary: _IO_file_close_it would call it even for
!_IO_IS_FILEBUF streams.
There is still a remaining concurrency defect because
_IO_new_file_init_internal links in the stream before it is
fully initialized, and it is not locked at this point.
Reviewed-by: Arjun Shankar <arjun@redhat.com>
|
|
This is needed for the recently added EXIT_UNSUPPORTED return value.
Message-ID: <20260118174700.495539-1-aurelien@aurel32.net>
|
|
|
|
And use the new __pthread_descriptor_valid function that checks
for 'joinstate' to get the thread state instead of 'tid'. The
joinstate is set by the kernel when the thread exits.
Checked on x86_64-linux-gnu.
Reviewed-by: Florian Weimer <fweimer@redhat.com>
|
|
The use-after-free described in BZ#19951 is due to the use of two
different PD fields, 'joinid' and 'cancelhandling', to describe the
thread state and to synchronise the calls of pthread_join,
pthread_detach, pthread_exit, and normal thread exit.
Any state change may require checking both fields atomically to handle
partial state (e.g., pthread_join() with a cancellation handler to
issue a 'joinstate' field rollback).
This patch uses a different PD member with 4 possible states (JOINABLE,
DETACHED, EXITING, and EXITED) instead of the pthread 'tid' field, with
the following logic:
1. On pthread_create, the initial state is set either to JOINABLE or
DETACHED depending on the pthread attribute used.
2. On pthread_detach, a CAS is issued on the state. If the CAS fails,
the thread is already detached (DETACHED) or being terminated (EXITING).
For the former, an EINVAL is returned; for the latter, pthread_detach
should be responsible for joining the thread (and for deallocating any
internal resources).
3. In the exit phase of the wrapper function for the thread start routine
(reached either if the thread function has returned, pthread_exit has
been called, or cancellation handled has been acted upon), we issue a
CAS on state to set it to the EXITING mode.
If the thread is previously in DETACHED mode, the thread is responsible
for deallocating any resources; otherwise, the thread must be joined
(detached threads cannot deallocate themselves immediately).
4. The clear_tid_field on 'clone' call is changed to set the new 'state'
field on thread exit (EXITED). This state is only reached at thread
termination.
5. The pthread_join implementation is now simpler: the futex wait is done
directly on thread state, and there is no need to reset it in case of
timeout since the state is now set either by pthread_detach() or by the
kernel on process termination.
The race condition on pthread_detach is avoided with a single atomic
operation on the PD state: once the mode is set to THREAD_STATE_DETACHED, it
is up to the thread itself to deallocate its memory (done during the exit
phase at pthread_create()).
Also, the INVALID_NOT_TERMINATED_TD_P is removed since a negative yid is
not possible, and the macro is not used anywhere.
This change triggers an invalid C11 thread test: it creates a thread that
detaches, and after a timeout, the creating thread checks whether the join
fails. The issue is that once thrd_join() is called, the thread's lifetime
is not defined.
Checked on x86_64-linux-gnu, i686-linux-gnu, aarch64-linux-gnu,
arm-linux-gnueabihf, and powerpc64-linux-gnu.
Reviewed-by: Florian Weimer <fweimer@redhat.com>
|
|
thrd_{create,detach,exit,join}.
mtx_{init,destroy,lock,trylock,unlock,timeelock}.
cnd_{broadcast,destroy,init,signal,timewait,wait,destroy}
tss_{create,delete,get,set}. call_once.
Message-ID: <20251121191336.1224485-1-gfleury@disroot.org>
|
|
There is no new symbol version because of the compatibility symbol
status.
|
|
The support for lock elision was already deprecated with glibc 2.42:
commit 77438db8cfa6ee66b3906230156bdae11c49a195
"Mark support for lock elision as deprecated."
See also discussions:
https://sourceware.org/pipermail/libc-alpha/2025-July/168492.html
This patch removes the architecture specific support for lock elision
for x86, powerpc and s390 by removing the elision-conf.h, elision-conf.c,
elision-lock.c, elision-timed.c, elision-unlock.c, elide.h, htm.h/hle.h files.
Those generic files are also removed.
The architecture specific structures are adjusted and the elision fields are
marked as unused. See struct_mutex.h files.
Furthermore in struct_rwlock.h, the leftover __rwelision was also removed.
Those were originally removed with commit 0377a7fde6dfcc078dda29a1225d7720a0931357
"nptl: Remove rwlock elision definitions"
and by chance reintroduced with commit 7df8af43ad1cd8ce527444de50bee6f35eebe071
"nptl: Add struct_rwlock.h"
The common code (e.g. the pthread_mutex-files) are changed back to the time
before lock elision was introduced with the x86-support:
- commit 1cdbe579482c07e9f4bb3baa4864da2d3e7eb837
"Add the low level infrastructure for pthreads lock elision with TSX"
- commit b023e4ca99f5e81f90d87d23cd267ef2abd2388c
"Add new internal mutex type flags for elision."
- commit 68cc29355f3334c7ad18f648ff9a6383a0916d23
"Add minimal test suite changes for elision enabled kernels"
- commit e8c659d74e011346785355eeef03b7fb6f533c61
"Add elision to pthread_mutex_{try,timed,un}lock"
- commit 49186d21ef2d87986bccaf0a7c45c48c91b265f3
"Disable elision for any pthread_mutexattr_settype call"
- commit 1717da59aed9612becd56aaa1249aac695af4c8a
"Add a configure option to enable lock elision and disable by default"
Elision is removed also from the tunables, the initialization part, the
pretty-printers and the manual.
Some extra handling in the testsuite is removed as well as the full tst-mutex10
testcase, which tested a race while enabling lock elision.
I've also searched the code for "elision", "elide", "transaction" and e.g.
cleaned some comments.
I've run the testsuite on x86_64 and s390x and run the build-many-glibcs.py
script.
Thanks to Sachin Monga, this patch is also tested on powerpc.
A NEWS entry also mentions the removal.
Reviewed-by: Wilco Dijkstra <Wilco.Dijkstra@arm.com>
|
|
C23 adds once_flag, ONCE_FLAG_INIT and call_once to stdlib.h (in C11
they were only in threads.h, in C23 they are in both headers; this
change came from N2840). Implement this change, with a
bits/types/once_flag.h header for the common type and initializer
definitions.
Note that there's an omnibus bug (bug 33001) that covers more than
just these missing definitions.
This doesn't seem a significant enough feature to be worth mentioning
in NEWS.
ISO C is not concerned with whether functions are in libc or
libpthread, but POSIX links this to what header they are declared in,
so functions declared in stdlib.h are supposed to be in libc.
However, the current edition of POSIX is based on C17; hopefully Hurd
glibc will have completed the merge of libpthread into libc (in
particular, moving call_once) well before a future edition of POSIX
based on C23 (or a later version of ISO C) is released.
Tested for x86_64 and x86.
|
|
Both NPTL and HTL support PTHREAD_PROCESS_SHARED, and since the removal of
the NaCL port there are no other pthread implementations.
|
|
Message-ID: <20250817104023.91919-8-gfleury@disroot.org>
|
|
Message-ID: <20250817104023.91919-5-gfleury@disroot.org>
|
|
Update tst-fopen-threaded.c to call support_create_temp_directory to
create a temporary directory and open "file" in the temporary directory,
instead of using /tmp/openclosetest and leaving it behind.
This partially fixes BZ #33182.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
|
|
|
|
And add extra checks to enable for binutils 2.45 and if the architecture
explicitly enables it. When SFrame is disabled, all the related code
is also not enabled for backtrace() and _dl_find_object(), so SFrame
backtracking is not used even if the binary has the SFrame segment.
This patch also adds some other related fixes:
* Fixed an issue with AC_CHECK_PROG_VER, where the READELF_SFRAME
usage prevented specifying a different readelf through READELF
environment variable at configure time.
* Add an extra arch-specific internal definition,
libc_cv_support_sframe, to disable --enable-sframe on architectures
that have binutils but not glibc support (s390x).
* Renamed the tests without the .sframe segment and move the
tst-backtrace1 from pthread to debug.
* Use the built compiler strip to remove the .sframe segment,
instead of the system one (which might not support SFrame).
Checked on x86_64-linux-gnu and aarch64-linux-gnu.
Reviewed-by: Sam James <sam@gentoo.org>
|
|
It requires $(shared-thread-library). Fixes 0c342594237.
Checked on a i686-gnu build.
|
|
The BZ 32653 fix (12a497c716f0a06be5946cabb8c3ec22a079771e) kept the
stack pointer zeroing from make_main_stack_executable on
_dl_make_stack_executable. However, previously the 'stack_endp'
pointed to temporary variable created before the call of
_dl_map_object_from_fd; while now we use the __libc_stack_end
directly.
Since pthread_getattr_np relies on correct __libc_stack_end, if
_dl_make_stack_executable is called (for instance, when
glibc.rtld.execstack=2 is set) __libc_stack_end will be set to zero,
and the call will always fail.
The __libc_stack_end zero was used a mitigation hardening, but since
52a01100ad011293197637e42b5be1a479a2f4ae it is used solely on
pthread_getattr_np code. So there is no point in zeroing anymore.
Checked on x86_64-linux-gnu and i686-linux-gnu.
Reviewed-by: Sam James <sam@gentoo.org>
|
|
There is a spelling mistake in a puts statement. Fix it.
Signed-off-by: Colin Ian King <colin.i.king@gmail.com>
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
|
|
The fread race checker looks for EOF in every thread, which is incorrect
since threads calling fread successfully could lag behind and read the
EOF condition, resulting in multiple threads thinking that they
encountered an EOF.
Only look for EOF condition if fread fails to read a char. Also drop
the clearerr() since it could mask the failure of another reader, thus
hiding a test failure.
Finally, also check for error in the stream for completeness.
Signed-off-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
Reviewed-by: Florian Weimer <fweimer@redhat.com>
|
|
The SIGCANCEL signal handler should not issue __syscall_do_cancel,
which calls __do_cancel and __pthread_unwind, if the cancellation
is already in proces (and libgcc unwind is not reentrant). Any
cancellation signal received after is ignored.
Checked on x86_64-linux-gnu and aarch64-linux-gnu.
Tested-by: Aurelien Jarno <aurelien@aurel32.net>
Reviewed-by: Florian Weimer <fweimer@redhat.com>
|
|
Do not add the pthread_atfork routine again in nptl/Makefile,
instead rely on sysdeps/pthread/Makefile for the integration
(as this is the directory that contains the source file).
In sysdeps/pthread/Makefile, add to static-only-routines.
Reviewed-by: Joseph Myers <josmyers@redhat.com>
|
|
sysdeps/pthread/sem_open.c: call pthread_setcancelstate directely
since forward declaration is gone on hurd too
Message-ID: <20250201080202.494671-1-gfleury@disroot.org>
|
|
Adding some basic tests for fopen, testing different modes, stream
positioning and concurrent read/write operation on files.
Reviewed-by: DJ Delorie <dj@redhat.com>
|
|
|
|
Use empty initializer to silence GCC 4.9 or older:
getaddrinfo.c: In function ‘gaih_inet’:
getaddrinfo.c:1135:24: error: missing braces around initializer [-Werror=missing-braces]
/ sizeof (struct gaih_typeproto)] = {0};
^
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
Reviewed-by: Sam James <sam@gentoo.org>
|
|
This reverts commit 8aa2a9e0339215012354f3c4a262edda838134e8.
as not all targets need braces.
|
|
Add braces to silence GCC 4.9 or older:
getaddrinfo.c: In function ‘gaih_inet’:
getaddrinfo.c:1135:24: error: missing braces around initializer [-Werror=missing-braces]
/ sizeof (struct gaih_typeproto)] = {0};
^
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
Reviewed-by: Sam James <sam@gentoo.org>
|
|
All the existing glibc tests of sem_trywait are single-threaded. Add
one that calls sem_trywait and sem_post in separate threads.
Tested for x86_64.
|
|
Add a threaded test for pthread_spin_trylock attempting to lock already
acquired spin lock and checking for correct return code.
Reviewed-by: Florian Weimer <fweimer@redhat.com>
|
|
As noted by Adhemerval, we already have a tst-sem17 in nptl.
Tested for x86_64.
|
|
A static analyzer apparently reported an uninitialized use of the
variable result in sem_open in the case where the file is required to
exist but does not exist.
The report appears to be correct; set result to SEM_FAILED in that
case, and add a test for it.
Note: the test passes for me even without the sem_open fix, I guess
because result happens to get value SEM_FAILED (i.e. 0) when
uninitialized.
Tested for x86_64.
|
|
Add basic tests of pthread_mutexattr_gettype and
pthread_mutexattr_settype with each valid mutex kind, plus test for
EINVAL with an invalid mutex kind.
Tested for x86_64.
|
|
The pthread_timedjoin_np and pthread_clockjoin_np functions do not
check that a valid time has been specified. The documentation for
these functions in the glibc manual isn't sufficiently detailed to say
if they should, but consistency with POSIX functions such as
pthread_mutex_timedlock and pthread_cond_timedwait strongly indicates
that an EINVAL error is appropriate (even if there might be some
ambiguity about exactly where such a check should go in relation to
other checks for whether the thread exists, whether it's immediately
joinable, etc.). Copy the logic for such a check used in
pthread_rwlock_common.c.
pthread_join_common had some logic calling valid_nanoseconds before
commit 9e92278ffad441daf588ff1ff5bd8094aa33fbfd, "nptl: Remove
clockwait_tid"; I haven't checked exactly what cases that detected.
Tested for x86_64 and x86.
|
|
The current racy approach is to enable asynchronous cancellation
before making the syscall and restore the previous cancellation
type once the syscall returns, and check if cancellation has happen
during the cancellation entrypoint.
As described in BZ#12683, this approach shows 2 problems:
1. Cancellation can act after the syscall has returned from the
kernel, but before userspace saves the return value. It might
result in a resource leak if the syscall allocated a resource or a
side effect (partial read/write), and there is no way to program
handle it with cancellation handlers.
2. If a signal is handled while the thread is blocked at a cancellable
syscall, the entire signal handler runs with asynchronous
cancellation enabled. This can lead to issues if the signal
handler call functions which are async-signal-safe but not
async-cancel-safe.
For the cancellation to work correctly, there are 5 points at which the
cancellation signal could arrive:
[ ... )[ ... )[ syscall ]( ...
1 2 3 4 5
1. Before initial testcancel, e.g. [*... testcancel)
2. Between testcancel and syscall start, e.g. [testcancel...syscall start)
3. While syscall is blocked and no side effects have yet taken
place, e.g. [ syscall ]
4. Same as 3 but with side-effects having occurred (e.g. a partial
read or write).
5. After syscall end e.g. (syscall end...*]
And libc wants to act on cancellation in cases 1, 2, and 3 but not
in cases 4 or 5. For the 4 and 5 cases, the cancellation will eventually
happen in the next cancellable entrypoint without any further external
event.
The proposed solution for each case is:
1. Do a conditional branch based on whether the thread has received
a cancellation request;
2. It can be caught by the signal handler determining that the saved
program counter (from the ucontext_t) is in some address range
beginning just before the "testcancel" and ending with the
syscall instruction.
3. SIGCANCEL can be caught by the signal handler and determine that
the saved program counter (from the ucontext_t) is in the address
range beginning just before "testcancel" and ending with the first
uninterruptable (via a signal) syscall instruction that enters the
kernel.
4. In this case, except for certain syscalls that ALWAYS fail with
EINTR even for non-interrupting signals, the kernel will reset
the program counter to point at the syscall instruction during
signal handling, so that the syscall is restarted when the signal
handler returns. So, from the signal handler's standpoint, this
looks the same as case 2, and thus it's taken care of.
5. For syscalls with side-effects, the kernel cannot restart the
syscall; when it's interrupted by a signal, the kernel must cause
the syscall to return with whatever partial result is obtained
(e.g. partial read or write).
6. The saved program counter points just after the syscall
instruction, so the signal handler won't act on cancellation.
This is similar to 4. since the program counter is past the syscall
instruction.
So The proposed fixes are:
1. Remove the enable_asynccancel/disable_asynccancel function usage in
cancellable syscall definition and instead make them call a common
symbol that will check if cancellation is enabled (__syscall_cancel
at nptl/cancellation.c), call the arch-specific cancellable
entry-point (__syscall_cancel_arch), and cancel the thread when
required.
2. Provide an arch-specific generic system call wrapper function
that contains global markers. These markers will be used in
SIGCANCEL signal handler to check if the interruption has been
called in a valid syscall and if the syscalls has side-effects.
A reference implementation sysdeps/unix/sysv/linux/syscall_cancel.c
is provided. However, the markers may not be set on correct
expected places depending on how INTERNAL_SYSCALL_NCS is
implemented by the architecture. It is expected that all
architectures add an arch-specific implementation.
3. Rewrite SIGCANCEL asynchronous handler to check for both canceling
type and if current IP from signal handler falls between the global
markers and act accordingly.
4. Adjust libc code to replace LIBC_CANCEL_ASYNC/LIBC_CANCEL_RESET to
use the appropriate cancelable syscalls.
5. Adjust 'lowlevellock-futex.h' arch-specific implementations to
provide cancelable futex calls.
Some architectures require specific support on syscall handling:
* On i386 the syscall cancel bridge needs to use the old int80
instruction because the optimized vDSO symbol the resulting PC value
for an interrupted syscall points to an address outside the expected
markers in __syscall_cancel_arch. It has been discussed in LKML [1]
on how kernel could help userland to accomplish it, but afaik
discussion has stalled.
Also, sysenter should not be used directly by libc since its calling
convention is set by the kernel depending of the underlying x86 chip
(check kernel commit 30bfa7b3488bfb1bb75c9f50a5fcac1832970c60).
* mips o32 is the only kABI that requires 7 argument syscall, and to
avoid add a requirement on all architectures to support it, mips
support is added with extra internal defines.
Checked on aarch64-linux-gnu, arm-linux-gnueabihf, powerpc-linux-gnu,
powerpc64-linux-gnu, powerpc64le-linux-gnu, i686-linux-gnu, and
x86_64-linux-gnu.
[1] https://lkml.org/lkml/2016/3/8/1105
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
|
|
Remove local FAIL macro in favor to FAIL_EXIT1 from <support/check.h>,
which provides equivalent reporting, with the name of the file and the
line number within of the failure site additionally included. Remove
FAIL_ERR altogether and include ": %m" explicitly with the format string
supplied to FAIL_EXIT1 as there seems little value to have a separate
macro just for this.
Reviewed-by: DJ Delorie <dj@redhat.com>
|
|
Starting from glibc 2.1, crt1.o contains _IO_stdin_used which is checked
by _IO_check_libio to provide binary compatibility for glibc 2.0. Add
crt1-2.0.o for tests against glibc 2.0. Define tests-2.0 for glibc 2.0
compatibility tests. Add and update glibc 2.0 compatibility tests for
stderr, matherr and pthread_kill.
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
|
|
Fall back to ppoll if ppoll_time64 fails with ENOSYS.
Fixes commit 370da8a121c3ba9eeb2f13da15fc0f21f4136b25 ("nptl: Fix
tst-cancel30 on sparc64").
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
|
|
It was raised on libc-help [1] that some Linux kernel interfaces expect
the libc to define __USE_TIME_BITS64 to indicate the time_t size for the
kABI. Different than defined by the initial y2038 design document [2],
the __USE_TIME_BITS64 is only defined for ABIs that support more than
one time_t size (by defining the _TIME_BITS for each module).
The 64 bit time_t redirects are now enabled using a different internal
define (__USE_TIME64_REDIRECTS). There is no expected change in semantic
or code generation.
Checked on x86_64-linux-gnu, i686-linux-gnu, aarch64-linux-gnu, and
arm-linux-gnueabi
[1] https://sourceware.org/pipermail/libc-help/2024-January/006557.html
[2] https://sourceware.org/glibc/wiki/Y2038ProofnessDesign
Reviewed-by: DJ Delorie <dj@redhat.com>
|
|
Both tst-sigset2 and tst-signal1 expectes that SIGINT disposition
is set to SIG_DFL.
|
|
|
|
[BZ #30789]
When invoking sem_open with O_CREAT as one of its flags, we'll end up
in the second part of sem_open's "if ((oflag & O_CREAT) == 0 || (oflag
& O_EXCL) == 0)", which means that we don't expect the semaphore file
to exist.
In that part, open_flags is initialized as "O_RDWR | O_CREAT | O_EXCL
| O_CLOEXEC" and there's an attempt to open(2) the file, which will
likely fail because it won't exist. After that first (expected)
failure, some cleanup is done and we go back to the label "try_again",
which lives in the first part of the aforementioned "if".
The problem is that, in that part of the code, we expect the semaphore
file to exist, and as such O_CREAT (this time the flag we pass to
open(2)) needs to be cleaned from open_flags, otherwise we'll see
another failure (this time unexpected) when trying to open the file,
which will lead the call to sem_open to fail as well.
This can cause very strange bugs, especially with OpenMPI, which makes
extensive use of semaphores.
Fix the bug by simplifying the logic when choosing open(2) flags and
making sure O_CREAT is not set when the semaphore file is expected to
exist.
A regression test for this issue would require a complex and cpu time
consuming logic, since to trigger the wrong code path is not
straightforward due the racy condition. There is a somewhat reliable
reproducer in the bug, but it requires using OpenMPI.
This resolves BZ #30789.
See also: https://bugs.launchpad.net/ubuntu/+source/h5py/+bug/2031912
Signed-off-by: Sergio Durigan Junior <sergiodj@sergiodj.net>
Co-Authored-By: Simon Chopin <simon.chopin@canonical.com>
Co-Authored-By: Adhemerval Zanella Netto <adhemerval.zanella@linaro.org>
Fixes: 533deafbdf189f5fbb280c28562dd43ace2f4b0f ("Use O_CLOEXEC in more places (BZ #15722)")
|
|
Since the _FORTIFY_SOURCE feature uses some routines of Glibc, they need to
be excluded from the fortification.
On top of that:
- some tests explicitly verify that some level of fortification works
appropriately, we therefore shouldn't modify the level set for them.
- some objects need to be build with optimization disabled, which
prevents _FORTIFY_SOURCE to be used for them.
Assembler files that implement architecture specific versions of the
fortified routines were not excluded from _FORTIFY_SOURCE as there is no
C header included that would impact their behavior.
Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
|
|
With fortification enabled, read calls return result needs to be checked,
has it gets the __wur macro enabled.
Note on read call removal from sysdeps/pthread/tst-cancel20.c and
sysdeps/pthread/tst-cancel21.c:
It is assumed that this second read call was there to overcome the race
condition between pipe closure and thread cancellation that could happen
in the original code. Since this race condition got fixed by
d0e3ffb7a58854248f1d5e737610d50cd0a60f46 the second call seems
superfluous. Hence, instead of checking for the return value of read, it
looks reasonable to simply remove it.
Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
|
|
With fortification enabled, fgets calls return result needs to be checked,
has it gets the __wur macro enabled.
Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
|
|
Previously, the exit function was used, but this causes the test to
block (until the timeout) once exit is changed to lock stdio streams
during flush.
|
|
With fortification enabled, few function calls return result need to be
checked, has they get the __wur macro enabled.
Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
|
|
Using write without cheks leads to warn unused result when __wur is
enabled.
Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
|
|
|
|
Fix unused result warnings, detected when _FORTIFY_SOURCE is enabled in
glibc.
Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
|
