Re: Android native build of GCC
On February 15, 2015 12:57:18 PM CST, Alexander Monakov wrote: > > >On Sun, 15 Feb 2015, Cyd Haselton wrote: > >> On Sun, Feb 15, 2015 at 12:41 PM, Cyd Haselton >wrote: >> >> *snip* >> > >> >> So to obtain the pointer to >> >> dlopen the code like above can use dlsym(RTLD_DEFAULT, "dlopen"), >but not >> >> RTLD_NEXT (the loader precedes the fakeroot library in the lookup >chain). >> >> >> *snip* >> >> Just a quick update: RTLD_DEFAULT is definitely not the solution >here >> as it results in a segfault when libfakechroot loads. Perhaps a >> different RTLD_FLAG was meant? > >I think you need to use RTLD_DEFAULT only when resolving "dlopen", and >keep >RTLD_NEXT for all other symbol names (unless later on you run into >other >symbols with similar behavior). Something like > > ... = dlsym(strcmp(name, "dlopen") ? RTLD_NEXT : RTLD_DEFAULT, name); > >Alexander I believe that worked perfectly; compiling Python no longer causes fakechroot to throw an undefined reference to dlopen(). Many, many thanks. For my future reference, are there recommended references/documentation for Android's linker in particular and dynamic linking, shared/static libraries, and symbol resolution in general...other than man dlopen/dlsym/etc? -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
gcc-5-20150215 is now available
Snapshot gcc-5-20150215 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/5-20150215/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 5 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 220718 You'll find: gcc-5-20150215.tar.bz2 Complete GCC MD5=cbb40c78025841bde8e96b8801e13e6c SHA1=7d4be570bbb192a7678f3a9d77e86dd4d7ba3492 Diffs from 5-20150208 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-5 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
mfentry example
Hello,
I'm trying to do a live update of a function without killing or
stopping the program. This is a single threaded application which runs
something similar to the below code. Maximum time is spent in the
while(1) loop.
What i want to do is compile with gcc-4.8 with -pg and -mfentry and
then call function g() and then do the int y=x*3 and everything else.
I have thought of an idea about registering a sigHandler and then
setjmp/longjmp to g.. Please note i'm trying to fix some bugs here
without stopping the process.
I want to do something akin to Kgraft/Kpatch or Erlang's dynamic
updation system.
Can you please help me by throwing some light on this .
cat testxyz.c
#include
void g(int x)
{
new code that fixes some bugs
}
void f(int x)
{
int y=x*3;
printf("y on entry is 9\n");
int i=0;
while(1)
{
sleep(5);
i++;
printf("i now is %d\n",i);
}
return ;
}
int main()
{
f(3);
return 0;
}
Re: Android native build of GCC
On Sun, Feb 15, 2015 at 1:14 PM, Alexander Monakov wrote:
>
>
> On Sun, 15 Feb 2015, Cyd Haselton wrote:
>
>> On Sun, Feb 15, 2015 at 11:53 AM, Alexander Monakov
>> wrote:
>> >> Given that info...and in spite of my aforementioned limited knowledge I
>> >> went back to take another look at the source and found this in
>> >> libfakechroot.c
>> >>
>> >> /bld/fakechrt/fakechroot-2.16 $ grep -C 4 dlsym src/libfakechroot.c
>> >> /* Lazily load function */
>> >> LOCAL fakechroot_wrapperfn_t fakechroot_loadfunc (struct
>> >> fakechroot_wrapper * w)
>> >> {
>> >> char *msg;
>> >> if (!(w->nextfunc = dlsym(RTLD_NEXT, w->name))) {;
>> >> msg = dlerror();
>> >> fprintf(stderr, "%s: %s: %s\n", PACKAGE, w->name, msg != NULL ?
>> >> msg : "unresolved symbol");
>> >> exit(EXIT_FAILURE);
>> >> }
>> >>
>> >> I'm fairly certain I remember reading something about Android and lazy
>> >> function loadinghow it doesn't handle it well or does so differently
>> >> from standard Linux builds. At any rate, I believe the above code is
>> >> responsible for those annoying 'fakechroot: undefined reference to dlopen'
>> >> errors, so I'll see if I can fix that.
>> >
>> > In Android's Bionic libc, the implementation of dlopen() resides in the
>> > dynamic loader, and not present in libdl.so.
>>
>> Yet in Android's NDK documentation, they state that in order to use
>> dlopen() functionality in native code you must link against libdl and
>> include dlfcn.h. Why would this be the case if the dlopen()
>> implementation is not in libdl?
>> (documentation link: http://www.kandroid.org/ndk/docs/STABLE-APIS.html)
>
> That's the standard way of using dlopen, i.e. same as you would do it on Linux
> with glibc for example. So the link merely says that you can get dlopen the
> same way as usual.
>
> The difference is that Android's libdl only contains stub symbols for
> dlopen&co, and the real symbols can be looked up in the dynamic loader. That
> RTLD_NEXT does not work for obtaining a pointer for dlopen, as it works on
> glibc, is quite unfortunate, and probably a bug in Bionic.
>
> Alexander
Would it have anything to do with Android's symbol searching method?
I.e. a library must be explicitly linked and loaded if needed; on load
a library won't look to already loaded libraries to resolve symbols?
Re: Android native build of GCC
On Sun, 15 Feb 2015, Cyd Haselton wrote:
> On Sun, Feb 15, 2015 at 11:53 AM, Alexander Monakov
> wrote:
> >> Given that info...and in spite of my aforementioned limited knowledge I
> >> went back to take another look at the source and found this in
> >> libfakechroot.c
> >>
> >> /bld/fakechrt/fakechroot-2.16 $ grep -C 4 dlsym src/libfakechroot.c
> >> /* Lazily load function */
> >> LOCAL fakechroot_wrapperfn_t fakechroot_loadfunc (struct
> >> fakechroot_wrapper * w)
> >> {
> >> char *msg;
> >> if (!(w->nextfunc = dlsym(RTLD_NEXT, w->name))) {;
> >> msg = dlerror();
> >> fprintf(stderr, "%s: %s: %s\n", PACKAGE, w->name, msg != NULL ?
> >> msg : "unresolved symbol");
> >> exit(EXIT_FAILURE);
> >> }
> >>
> >> I'm fairly certain I remember reading something about Android and lazy
> >> function loadinghow it doesn't handle it well or does so differently
> >> from standard Linux builds. At any rate, I believe the above code is
> >> responsible for those annoying 'fakechroot: undefined reference to dlopen'
> >> errors, so I'll see if I can fix that.
> >
> > In Android's Bionic libc, the implementation of dlopen() resides in the
> > dynamic loader, and not present in libdl.so.
>
> Yet in Android's NDK documentation, they state that in order to use
> dlopen() functionality in native code you must link against libdl and
> include dlfcn.h. Why would this be the case if the dlopen()
> implementation is not in libdl?
> (documentation link: http://www.kandroid.org/ndk/docs/STABLE-APIS.html)
That's the standard way of using dlopen, i.e. same as you would do it on Linux
with glibc for example. So the link merely says that you can get dlopen the
same way as usual.
The difference is that Android's libdl only contains stub symbols for
dlopen&co, and the real symbols can be looked up in the dynamic loader. That
RTLD_NEXT does not work for obtaining a pointer for dlopen, as it works on
glibc, is quite unfortunate, and probably a bug in Bionic.
Alexander
Re: Android native build of GCC
On Sun, 15 Feb 2015, Cyd Haselton wrote: > On Sun, Feb 15, 2015 at 12:41 PM, Cyd Haselton wrote: > > *snip* > > > >> So to obtain the pointer to > >> dlopen the code like above can use dlsym(RTLD_DEFAULT, "dlopen"), but not > >> RTLD_NEXT (the loader precedes the fakeroot library in the lookup chain). > >> > *snip* > > Just a quick update: RTLD_DEFAULT is definitely not the solution here > as it results in a segfault when libfakechroot loads. Perhaps a > different RTLD_FLAG was meant? I think you need to use RTLD_DEFAULT only when resolving "dlopen", and keep RTLD_NEXT for all other symbol names (unless later on you run into other symbols with similar behavior). Something like ... = dlsym(strcmp(name, "dlopen") ? RTLD_NEXT : RTLD_DEFAULT, name); Alexander
Re: Android native build of GCC
On Sun, Feb 15, 2015 at 12:41 PM, Cyd Haselton wrote: *snip* > >> So to obtain the pointer to >> dlopen the code like above can use dlsym(RTLD_DEFAULT, "dlopen"), but not >> RTLD_NEXT (the loader precedes the fakeroot library in the lookup chain). >> *snip* Just a quick update: RTLD_DEFAULT is definitely not the solution here as it results in a segfault when libfakechroot loads. Perhaps a different RTLD_FLAG was meant?
Re: Android native build of GCC
On Sun, Feb 15, 2015 at 11:53 AM, Alexander Monakov wrote:
>> Given that info...and in spite of my aforementioned limited knowledge I
>> went back to take another look at the source and found this in
>> libfakechroot.c
>>
>> /bld/fakechrt/fakechroot-2.16 $ grep -C 4 dlsym src/libfakechroot.c
>> /* Lazily load function */
>> LOCAL fakechroot_wrapperfn_t fakechroot_loadfunc (struct fakechroot_wrapper
>> * w)
>> {
>> char *msg;
>> if (!(w->nextfunc = dlsym(RTLD_NEXT, w->name))) {;
>> msg = dlerror();
>> fprintf(stderr, "%s: %s: %s\n", PACKAGE, w->name, msg != NULL ? msg
>> : "unresolved symbol");
>> exit(EXIT_FAILURE);
>> }
>>
>> I'm fairly certain I remember reading something about Android and lazy
>> function loadinghow it doesn't handle it well or does so differently
>> from standard Linux builds. At any rate, I believe the above code is
>> responsible for those annoying 'fakechroot: undefined reference to dlopen'
>> errors, so I'll see if I can fix that.
>
> In Android's Bionic libc, the implementation of dlopen() resides in the
> dynamic loader, and not present in libdl.so.
Yet in Android's NDK documentation, they state that in order to use
dlopen() functionality in native code you must link against libdl and
include dlfcn.h. Why would this be the case if the dlopen()
implementation is not in libdl?
(documentation link: http://www.kandroid.org/ndk/docs/STABLE-APIS.html)
> So to obtain the pointer to
> dlopen the code like above can use dlsym(RTLD_DEFAULT, "dlopen"), but not
> RTLD_NEXT (the loader precedes the fakeroot library in the lookup chain).
>
> The preceding discussion seems to have libc and libdl switched. Normally the
> implementation of dlopen is found in libdl.so, but not in libc.so.
>
So in standard Linux builds, libc.so doesn't contain the dlopen()
implementation...as in Android?
> Hope that helps,
> Alexander
It saves me a lot of time poring through reams of speculation,
verbiage and complicated example code about Android's sparse
documentation so, thanks.
Re: Android native build of GCC
> Given that info...and in spite of my aforementioned limited knowledge I
> went back to take another look at the source and found this in
> libfakechroot.c
>
> /bld/fakechrt/fakechroot-2.16 $ grep -C 4 dlsym src/libfakechroot.c
> /* Lazily load function */
> LOCAL fakechroot_wrapperfn_t fakechroot_loadfunc (struct fakechroot_wrapper *
> w)
> {
> char *msg;
> if (!(w->nextfunc = dlsym(RTLD_NEXT, w->name))) {;
> msg = dlerror();
> fprintf(stderr, "%s: %s: %s\n", PACKAGE, w->name, msg != NULL ? msg :
> "unresolved symbol");
> exit(EXIT_FAILURE);
> }
>
> I'm fairly certain I remember reading something about Android and lazy
> function loadinghow it doesn't handle it well or does so differently
> from standard Linux builds. At any rate, I believe the above code is
> responsible for those annoying 'fakechroot: undefined reference to dlopen'
> errors, so I'll see if I can fix that.
In Android's Bionic libc, the implementation of dlopen() resides in the
dynamic loader, and not present in libdl.so. So to obtain the pointer to
dlopen the code like above can use dlsym(RTLD_DEFAULT, "dlopen"), but not
RTLD_NEXT (the loader precedes the fakeroot library in the lookup chain).
The preceding discussion seems to have libc and libdl switched. Normally the
implementation of dlopen is found in libdl.so, but not in libc.so.
Hope that helps,
Alexander
Re: Segmentation fault with unique_ptr
13.02.2015 16:04, tassos_souris writes: > Compile with: g++-4.9 -std=c++14 -g -o main main.cpp > and run with ./main. I get segfault. gdb in bt shows that the segfault > happens inside unique_ptr destructor. So it is not a memory issue. > Also since the code runs with less size (i.e size=1000 no problem) i assume > that something is wrong with unique_ptr and not my code. That's of course > only an assumption don't get me wrong :) The destructor of struct node calls the destructor of it's "next" member, which is std::unique_ptr, so you get a chain of recursive calls, and when it gets too deep, you simply run out of stack (you could check it by setting a breakpoint on node::~node and stepping through it several times, looking at the backtrace each time). Here is what I get with GCC 4.8.2, -std=c++11: #0 singly_linked_list_2::node::~node (this=0x6511b0, __in_chrg=) at ./stack_fail.cc:8 #1 0x00400db8 in std::default_delete::operator() (this=0x6511d8, __ptr=0x6511b0) at /usr/include/c++/4.8.2/bits/unique_ptr.h:67 #2 0x00400a07 in std::unique_ptr >::~unique_ptr (this=0x6511d8, __in_chrg=) at /usr/include/c++/4.8.2/bits/unique_ptr.h:184 #3 0x00400d94 in singly_linked_list_2::node::~node (this=0x6511d0, __in_chrg=) at ./stack_fail.cc:8 #4 0x00400db8 in std::default_delete::operator() (this=0x6511f8, __ptr=0x6511d0) at /usr/include/c++/4.8.2/bits/unique_ptr.h:67 #5 0x00400a07 in std::unique_ptr >::~unique_ptr (this=0x6511f8, __in_chrg=) at /usr/include/c++/4.8.2/bits/unique_ptr.h:184 #6 0x00400d94 in singly_linked_list_2::node::~node (this=0x6511f0, __in_chrg=) at ./stack_fail.cc:8 #7 0x00400db8 in std::default_delete::operator() (this=0x651218, __ptr=0x6511f0) at /usr/include/c++/4.8.2/bits/unique_ptr.h:67 #8 0x00400a07 in std::unique_ptr >::~unique_ptr (this=0x651218, __in_chrg=) at /usr/include/c++/4.8.2/bits/unique_ptr.h:184 #9 0x00400d94 in singly_linked_list_2::node::~node (this=0x651210, __in_chrg=) at ./stack_fail.cc:8 #10 0x00400db8 in std::default_delete::operator() (this=0x7fffe410, __ptr=0x651210) at /usr/include/c++/4.8.2/bits/unique_ptr.h:67 #11 0x00400a07 in std::unique_ptr >::~unique_ptr (this=0x7fffe410, __in_chrg=) at /usr/include/c++/4.8.2/bits/unique_ptr.h:184 #12 0x00400962 in singly_linked_list_2::~singly_linked_list_2 (this=0x7fffe400, __in_chrg=) at ./stack_fail.cc:19 #13 0x004007ae in main () at ./stack_fail.cc:40 As we see, the recursion depth is linear WRT list size. At higher optimization levels the tail call gets optimized, and this problem does not occur, but in general it's better not to rely on this. -- Regards, Mikhail Maltsev
Re: Android native build of GCC
On February 14, 2015 5:08:23 AM CST, Andrew Haley wrote:
>On 13/02/15 22:40, Cyd Haselton wrote:
>> Somehow these calls are passed to libc by the wrapper including the
>dlopen() call...which fails because it should be passed to libdl on
>android.
>>
>> How the wrapper points to libc I have no idea. Why the wrapper
>around dlopen doesn't pick up 0n the linked libdl.so...again, I have no
>idea. Someone with better knowledge of fakechroot internals, symbols
>and linking will have to tackle this.
>
>Ah, I think I might know. When you call dlsym() you have the option
>of passing a handle to the library you want to search. Usually
>dlsym() searches all loaded libraries, but it's possible that
>libfakechroot specifies that only libc is searched.
>
>Andrew.
Given that info...and in spite of my aforementioned limited knowledge I went
back to take another look at the source and found this in libfakechroot.c
/bld/fakechrt/fakechroot-2.16 $ grep -C 4 dlsym src/libfakechroot.c
/* Lazily load function */
LOCAL fakechroot_wrapperfn_t fakechroot_loadfunc (struct fakechroot_wrapper * w)
{
char *msg;
if (!(w->nextfunc = dlsym(RTLD_NEXT, w->name))) {;
msg = dlerror();
fprintf(stderr, "%s: %s: %s\n", PACKAGE, w->name, msg != NULL ? msg :
"unresolved symbol");
exit(EXIT_FAILURE);
}
I'm fairly certain I remember reading something about Android and lazy function
loadinghow it doesn't handle it well or does so differently from standard
Linux builds. At any rate, I believe the above code is responsible for those
annoying 'fakechroot: undefined reference to dlopen' errors, so I'll see if I
can fix that.
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: --disable-shared bootstrap dies building libcc1
On 14.2.2015 03:10, Alan Modra wrote: > On both x86_64-linux and powerpc64-linux, a --disable-shared bootstrap > dies with linker errors when building libcc1.so. You can't build a > shared library using objects from the static libstdc++ (or any other > library built without -fpic/-fPIC). > > OK, so there is a workaround, specify --disable-plugin too, but > shouldn't this be automatic if --disable-shared is given? > Shouldn't static libstdc++ be built with the PIC options regardless of --disable-shared? I can imagine people wanting to link static libraries into their own shared libraries. -- VZ signature.asc Description: OpenPGP digital signature
