Re: GSoC ShlibMemLoad

> >> 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

	- 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, ...).

	- Does fflush() work?
		Highlevel I/O, but no varargs. It is also outside
		of the printf family of functions in general.

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