Age | Commit message (Collapse) | Author |
|
pthread_mutex functions such as pthread_cond_wait(), pthread_mutex_unlock() return
errors after PTHREAD_PRIO_INHERIT is enabled
Reference:
https://sourceware.org/bugzilla/show_bug.cgi?id=18463
Upstream patches:
https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=f0e3925bf3b8df6940c3346db17e42615979d458
https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=13cb8f76da9d9420330796f469dbf10643ba5b12
https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=23b5cae1af04f2d912910fdaf73cb482265798c1
https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=ed19993b5b0d05d62cc883571519a67dae481a14
https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=2e4cf778972573221e9b87fd992844ea9b67b9bf
https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=abff18c0c6055ca5d1cd46923fd1205c057139a5
This issue is Morty specific (glibc 2.24).
The issue is no longer present in glibc 2.25 (master branch).
Signed-off-by: Catalin Enache <catalin.enache@windriver.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
|
|
arm: mark __startcontext as .cantunwind, GNU
CVE: CVE-2016-6323
Signed-off-by: Andrej Valek <andrej.valek@siemens.com>
Signed-off-by: Pascal Bach <pascal.bach@siemens.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
|
|
[BZ 20116] -- https://sourceware.org/bugzilla/show_bug.cgi?id=20116
The commit documents the ownership rules around 'struct pthread' and
when a thread can read or write to the descriptor. With those ownership
rules in place it becomes obvious that pd->stopped_start should not be
touched in several of the paths during thread startup, particularly so
for detached threads. In the case of detached threads, between the time
the thread is created by the OS kernel and the creating thread checks
pd->stopped_start, the detached thread might have already exited and the
memory for pd unmapped. As a regression test we add a simple test which
exercises this exact case by quickly creating detached threads with
large enough stacks to ensure the thread stack cache is bypassed and the
stacks are unmapped. Before the fix the testcase segfaults, after the
fix it works correctly and completes without issue.
For a detailed discussion see:
https://www.sourceware.org/ml/libc-alpha/2017-01/msg00505.html
(cherry-picked from commit f8bf15febcaf137bbec5a61101e88cd5a9d56ca8)
Signed-off-by: Yuanjie Huang <yuanjie.huang@windriver.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
|
|
Signed-off-by: Jérémy Rosen <jeremy.rosen@smile.fr>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
The ELF specification indicates symbol resolution should be breadth first, not
depth first.
The dl-deps.c: dl_build_locale_scope function is processing in a depth first
mode. This is causes certain symbols to be incorrectly reported when
LD_TRACE_PRELINKING=1 is enabled.
See glibc BZ #20488 for more information.
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
glibc 2.24 is released now
https://www.sourceware.org/ml/libc-alpha/2016-08/msg00212.html
Signed-off-by: Khem Raj <raj.khem@gmail.com>
|
|
Drop upstreamed patch
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
The nativesdk libc when used by buildtools has a hard requirement on supporting
a UTF-8 locale because Python 3 needs a UTF-8 locale. However we currently only
ship the C locale, which means that Python attempts to lookup the user's locale
(for example, en_NZ.UTF-8) in the locale archive under it's prefix it fails and
falls back to C. This the results in Python using ASCII instead of UTF-8 for
file encoding, and bitbake breaks.
Th obvious solution would be to ship all locales, but this would add
approximately 250MB to the size of the buildtools tarball (which is currently
around 30MB). Generating a binary locale archive reduces this down to 100MB,
but this is still a drastic increase in footprint. If we ship a subset of
locales in the tarball then there will be users whose locale isn't in the
tarball, and they'll have to change their locale to an "approved" one, which
isn't the best of messages to send to new users.
The alternative is to tell the nativesdk libc that the locale archive isn't
under it own prefix but is in fact at /usr/lib/locale/locale-archive, so the
buildtools libc uses the host locale archive. The locale archive format appears
to be at least fairly stable: our glibc 2.24 can read the locale archive
generated by glibc 2.17 (Centos 7).
[ YOCTO #9775 ]
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
glibc master added the EM_METAG tag but didn't add the relocation defines.
However the kernel tooling only checks for EM_METAG when defining its own values
so scripts/recordmcount ends up using R_META_* symbols without their definition.
Whilst the kernel can and should be fixed, this breaks all users of recordmcount
so patch elf.h to add the values.
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
- libc-package.bbclass: Do not use --old-style
This option has been dropped from latest glibc
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|