Displaying 14 results from an estimated 14 matches for "__libc_stack_end".
2006 Jul 28
3
R uses private function in libc (PR#9107)
Full_Name: Quanah Gibson-Mount
Version: 2.3.0, 2.3.1
OS: Linux
Submission from: (NULL) (171.66.155.86)
libc used to export the symbol:
__libc_stack_end;
however, newer versions of libc no longer export it. R has some serious
problems around this, because the code has:
# ifdef linux
extern void * __libc_stack_end;
# endif
and
#if defined(linux)
R_CStackStart = (uintptr_t) __libc_stack_end;
#elif defined(HAVE_KERN_USRSTACK)
in r-2.3.1/sr...
2020 Feb 28
2
Demotion of shared symbols resolved from the dynamic linker.
On PowerPC we have a failing address sanitizer test when linking with LLD.
The issue is that the symbol '__libc_stack_end' is resolved to an undefined
weak symbol when linking with LLD but not when linking (with the exact same
command/input) with other linkers. Tracing the symbol I see it is resolved
to a definition in the dynamic linker as expected:
/home/sfertile/LLVM_MonoRepo/build/lib/clang/11.0.0/lib/linux/l...
2016 Feb 01
1
Wrong config check for __libc_stack_end
...No, it's actually very crucial as it is used to detect stack overflows.
> Cheers,
> Simon
Well, I think you misunderstood what I meant to say (or then I'm
happy for clarification if I misunderstood you) :
The #ifdef ... #elseif ... #else ... # endif
branch which *uses* the __libc_stack_end "variable" would
hopefully be a speedup in comparison with the alternatives; from
system.c mentioned above:
#if defined(HAVE_LIBC_STACK_END)
R_CStackStart = (uintptr_t) __libc_stack_end;
#elif defined(HAVE_KERN_USRSTACK)
{
/* Borrowed from mzscheme/gc/os_dep.c */
int nm[2] =...
2016 Feb 01
3
Wrong config check for __libc_stack_end
...a private glibc symbol in R.
>>
>> In R 3.2.3, it seems that configure is trying to test for
>> it on Linux. It apparently fails to accurately test (as
>> demonstrated by the link error), perhaps because the test
>> program does not actually *use* __libc_stack_end so it
>> gets optimized out. (See line 35500 or so in
>> R-3.2.3/configure.) Ideally, the test program would
>> check that a pointer to __libc_stack_end is non-null, but
>> that's an autoconf bug.
So, ideally someone who knows autoconf much better than...
2016 Feb 01
0
Wrong config check for __libc_stack_end
...a private glibc symbol in R.
>>>
>>> In R 3.2.3, it seems that configure is trying to test for
>>> it on Linux. It apparently fails to accurately test (as
>>> demonstrated by the link error), perhaps because the test
>>> program does not actually *use* __libc_stack_end so it
>>> gets optimized out. (See line 35500 or so in
>>> R-3.2.3/configure.) Ideally, the test program would
>>> check that a pointer to __libc_stack_end is non-null, but
>>> that's an autoconf bug.
>
> So, ideally someone who knows autoconf much be...
2016 Feb 01
0
Wrong config check for __libc_stack_end
...;>>
>>>>> In R 3.2.3, it seems that configure is trying to test for
>>>>> it on Linux. It apparently fails to accurately test (as
>>>>> demonstrated by the link error), perhaps because the test
>>>>> program does not actually *use* __libc_stack_end so it
>>>>> gets optimized out. (See line 35500 or so in
>>>>> R-3.2.3/configure.) Ideally, the test program would
>>>>> check that a pointer to __libc_stack_end is non-null, but
>>>>> that's an autoconf bug.
>>>
>>>...
2016 Feb 01
3
Wrong config check for __libc_stack_end
...bol in R.
>>>>
>>>> In R 3.2.3, it seems that configure is trying to test for
>>>> it on Linux. It apparently fails to accurately test (as
>>>> demonstrated by the link error), perhaps because the test
>>>> program does not actually *use* __libc_stack_end so it
>>>> gets optimized out. (See line 35500 or so in
>>>> R-3.2.3/configure.) Ideally, the test program would
>>>> check that a pointer to __libc_stack_end is non-null, but
>>>> that's an autoconf bug.
>>
>> So, ideally someone who...
2016 Jan 28
2
Abuse of a private glibc symbol in R 3.2.3
...ought to my attention that this is a (very longstanding)
abuse of a private
glibc symbol in R.
In R 3.2.3, it seems that configure is trying to test for it on Linux.
It apparently fails to accurately test (as demonstrated by the link error),
perhaps because the test program does not actually *use* __libc_stack_end
so it gets optimized out. (See line 35500 or so in R-3.2.3/configure.)
Ideally, the test program would check that a pointer to __libc_stack_end
is non-null, but that's an autoconf bug.
A work around was to 'export r_cv_libc_stack_end=no' before configuring R.
However, there are a coupl...
2016 Feb 01
3
Wrong config check for __libc_stack_end
...gt;>>>> In R 3.2.3, it seems that configure is trying to test for
>>>>>> it on Linux. It apparently fails to accurately test (as
>>>>>> demonstrated by the link error), perhaps because the test
>>>>>> program does not actually *use* __libc_stack_end so it
>>>>>> gets optimized out. (See line 35500 or so in
>>>>>> R-3.2.3/configure.) Ideally, the test program would
>>>>>> check that a pointer to __libc_stack_end is non-null, but
>>>>>> that's an autoconf bug.
>>&...
2008 Jun 07
1
Fail to call AC_CACHE_CHECK on R 2.7.0 for Solaris
...ar to me that AC_CACHE_CHECK needs to be run in order
that r_cv_iconv_latin will be set properly. But looking at
configure.ac, I think AC_CACHE_CHECK is only called on Linux, and not
on Solaris. Obviously this could explain why this bit of Sage works on
Linux, but not Solaris.
## check for visible __libc_stack_end on Linux
case "${host_os}" in
linux*)
AC_CACHE_CHECK([for visible __lib_stack_end],
[r_cv_libc_stack_end],
[AC_RUN_IFELSE([AC_LANG_SOURCE([[
#include "confdefs.h"
#include <stdlib.h>
extern void * __libc_stack_end;
So it seems to me this will never work, as...
2016 Jan 29
0
Abuse of a private glibc symbol in R 3.2.3
...is is a (very longstanding)
> abuse of a private
> glibc symbol in R.
>
> In R 3.2.3, it seems that configure is trying to test for it on Linux.
> It apparently fails to accurately test (as demonstrated by the link error),
> perhaps because the test program does not actually *use* __libc_stack_end
> so it gets optimized out. (See line 35500 or so in R-3.2.3/configure.)
> Ideally, the test program would check that a pointer to __libc_stack_end
> is non-null, but that's an autoconf bug.
>
> A work around was to 'export r_cv_libc_stack_end=no' before configuring R.
&g...
2006 Apr 11
4
Stack checking, core dumps, and embedding R
I will say this first -- I can't copy/paste the error message from the
screen, so it's being retyped. Errors might occur. SORRY.
I've been experiencing some interesting stack warnings recently when
moving from R 2.2.x to the R 2.3.0 series and the R 2.4.0 series. In
particular, I'm getting warnings of "Error: C stack usage is too close
to the limit" before
2006 Oct 03
1
R-2.4.0 is released
.../Fortran code can be
run' has been improved as on one system that test passed but
the Fortran run-time library was broken.
o A precious configure variable DEFS can be set to pass defines
(e.g. -DUSE_TYPE_CHECKING_STRICT) to C code when compiling R.
o There is now a test for visible __libc_stack_end on Linux
systems (since it is not visible on some recent glibc's
built from the sources).
o MacOS X 10.4 and higher now use two-level namespaces, single
module in a shared library and allow undefined symbols to be
resolved at run-time. This implies that common symbols are now
allowed...
2006 Oct 03
1
R-2.4.0 is released
.../Fortran code can be
run' has been improved as on one system that test passed but
the Fortran run-time library was broken.
o A precious configure variable DEFS can be set to pass defines
(e.g. -DUSE_TYPE_CHECKING_STRICT) to C code when compiling R.
o There is now a test for visible __libc_stack_end on Linux
systems (since it is not visible on some recent glibc's
built from the sources).
o MacOS X 10.4 and higher now use two-level namespaces, single
module in a shared library and allow undefined symbols to be
resolved at run-time. This implies that common symbols are now
allowed...