Re: GSoC ShlibMemLoad

2008/7/4 Andreas Kupries <andreask@...>:
>
>> >> They all have only one actual function greet(). This function get pid
>> >> of the process which calls it and tries to write it to stdout.
>> >> libwrite_simple makes it in the easiest possible way: just uses one
>> >> write sys call.
>> >> libwrite_global makes it similarly, but a buffer is global now.
>> >> libwrite_fun calls another function (fill_str to fill buffer with data)
>> >> These three libraries seems to be working fine.
>> >> The fourth library libprintf tries to make the same thing easier and
>> >> use printf instead of write. Anyway, it does not work. I get a
>> >> segmentation fault (the same happens when I substitute printf for any
>> >> other functions from stdio.h like puts).
>>
>> >> I do not know what may be wrong but I will try to work on it. Maybe
>> >> the problem is in function load_needed_objects(Obj_Entry *) which is
>> >> called by elf_dlopen, but I still do not know why it works for the
>> >> first three libraries. They use functions from unistd.h.
>>
>> >I can't say at the moment. It seems that you haven't committed all the
>> >changes yet, so I have can't see what was done.
>>
>> >For example, it is not clear if you are using the OS dlsym() already, or
>> >not.
>>
>> >Best guess I have right now, is that it might be that your non-working
>> >library depends on some other library FOO instead of just libc. And while
>> >libc symbols are present the FOO is not loaded (yet) and thus its symbols
>> >are not present either?
>>
>> As far as I know printf function is in libc as well. I also tried to
>> compile libprintf.c to a program and run it with strace. The only
>> library which was loaded was libc. Function load_needed_objects said
>> it needed only libc...
>> When I look at the output of elf_dlopen it seems that printf
>> symbol is founded.
>> I also wrote another simple library: libcos.c. It calls cos function
>> defined in math.h. This library has to be linked with libm (-lm). And
>> rtld copes with this library...
>> Another simple library libstrcpy whch uses strcpy also works.
>> So I still have no idea what is the difference between libprintf and
>> those other libraries which works.
>
> While walking to the office I managed to come up with a number of additional
> ideas ...
>
> printf is different from the other functions in two respects.
>
>        It takes a variable number of arguments,
> and     it operates at a higher IO level than write and consorts.
>
>        Both might be a possible source of the problem I guess.
>        Although I have no idea of how that could be.
>
> Things to consider:
>
>        - Does using 'sprintf()' (+write) work ?
>                sprintf is also varargs, but doesn't do any I/O
sprintf does not work
>
>        - Does 'fprintf()' work ?
>                It is like printf, i.e. varargs and highlevel I/O
>                However it explicitly takes an output argument.
>                printf (...) is like fprintf (stdout, ...).
fprintf does not work
>        - Does fflush() work?
>                Highlevel I/O, but no varargs. It is also outside
>                of the printf family of functions in general.
fflush surprisingly works...
Anyway, the problem is not in varargs, because I also tried with
functions like putchar, puts, etc and they all does not work.
>
> To anybody, are there varargs functions in libc outside of the printf family
> which could be used to probe the problem further?
>
>
> General background for the Tcl-core guys just coming in on the thread ...
>
>        This is Google Summer of Code Project 'Loading a shared library from
> memory'.
>        The svn repository for all relevant sources is at
>        http://svn.assembla.com/svn/gsoc2008-tcl_dynamic_libraries/
>
>        Daniel is currently experimenting with FreeBSD's (*) runtime ld (aka
> "rtld")
>        This is in essence the "ld.so" used to load regular libraries from disk,
> and
>
>        Daniel's basic idea is that we should be able to modify this in only a few
>        places to get it to process a memory block holding a library, and hook to
> other
>        parts of Tcl and the OS.
>
>        He is currently testing the basic setup, getting to know the sources and
> its
>        structure, and getting it to work for regular loading.
>
>        From the above, most of the test libraries can be loaded fine, some of them
>        crash however and he is working on finding out why.
>
>
> (*)     While glibc has the same functionality and sources available it is under
> GPL, which does not mesh nicely with our BSD world. FreeBSD's code and
> license does.
>
> --
>        Andreas Kupries <andreask@...>
>        Developer @ http://www.ActiveState.com
>        Tel: +1 778-786-1122
>
>

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08