|
Home > Archive > Unix Programming > July 2006 > Possible to do the equivalent of dlopen with an executable (i.e., not shared lib) ?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Possible to do the equivalent of dlopen with an executable (i.e., not shared lib) ?
|
|
| Kenny McCormack 2006-07-19, 1:40 pm |
| Is it possible to do the equivalent of dlopen with an executable (i.e.,
not shared lib) ?
When I try to dlopen() an (dynamically linked) executable program, I get
a NULL return and the following error from dlerror():
ld.so.1: ./myprog: elf error: ../path/something: not a shared or
relocatable object: Error 0
which is, of course, perfectly reasonable. But, ISTR, that it was
somehow possible to do the same thing (i.e., execute routines stored
within) a regular executable as well. Am I remembering wrong?
| |
| Pascal Bourguignon 2006-07-19, 1:40 pm |
| gazelle@xmission.xmission.com (Kenny McCormack) writes:
> Is it possible to do the equivalent of dlopen with an executable (i.e.,
> not shared lib) ?
>
> When I try to dlopen() an (dynamically linked) executable program, I get
> a NULL return and the following error from dlerror():
>
> ld.so.1: ./myprog: elf error: ../path/something: not a shared or
> relocatable object: Error 0
>
> which is, of course, perfectly reasonable. But, ISTR, that it was
> somehow possible to do the same thing (i.e., execute routines stored
> within) a regular executable as well. Am I remembering wrong?
It's more complicated, but with enough work, it should be doable.
Firs tyou need to know what is the format of the excutable file
(a.out, elf, cof, etc). Then locate a library allowing you to load
it, find symbols, relocate it, dynamically link it with the libraries
it needs, etc, and eventually you may be able to call some function
from the executable.
But really, it would be easier to type make in the source directory of
the program, and then to build a dynamic library from the .o files
remaining...
--
__Pascal Bourguignon__ http://www.informatimago.com/
"You can tell the Lisp programmers. They have pockets full of punch
cards with close parentheses on them." --> http://tinyurl.com/8ubpf
| |
| Michael Vilain 2006-07-19, 1:40 pm |
| In article <e9lp08$rig$1@news.xmission.com>,
gazelle@xmission.xmission.com (Kenny McCormack) wrote:
> Is it possible to do the equivalent of dlopen with an executable (i.e.,
> not shared lib) ?
>
> When I try to dlopen() an (dynamically linked) executable program, I get
> a NULL return and the following error from dlerror():
>
> ld.so.1: ./myprog: elf error: ../path/something: not a shared or
> relocatable object: Error 0
>
> which is, of course, perfectly reasonable. But, ISTR, that it was
> somehow possible to do the same thing (i.e., execute routines stored
> within) a regular executable as well. Am I remembering wrong?
I've never heard of this capability. AFAIK, you can only link to shared
libraries, not executables. Time for a rethink on what you're trying to
do.
--
DeeDee, don't press that button! DeeDee! NO! Dee...
| |
| Pascal Bourguignon 2006-07-19, 1:40 pm |
| Michael Vilain <vilain@spamcop.net> writes:
> In article <e9lp08$rig$1@news.xmission.com>,
> gazelle@xmission.xmission.com (Kenny McCormack) wrote:
>
>
> I've never heard of this capability. AFAIK, you can only link to shared
> libraries, not executables. Time for a rethink on what you're trying to
> do.
Well, if gdb can do it:
[pjb@thalassa tmp]$ gdb ./a
GNU gdb 5.3
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i586-suse-linux"...
(gdb) break main
Breakpoint 1 at 0x804834b
(gdb) run
Starting program: /tmp/a
Breakpoint 1, 0x0804834b in main ()
(gdb) print fact(5)
$1 = 120
(gdb) shell cat a.c
int fact(int x){return((1==x)?(1) x*fact(x-1)));}
int main(void){return(fact(1));}
(gdb) quit
A debugging session is active.
Do you still want to close the debugger?(y or n) y
[pjb@thalassa tmp]$
--
__Pascal Bourguignon__ http://www.informatimago.com/
You never feed me.
Perhaps I'll sleep on your face.
That will sure show you.
| |
| Casper H.S. Dik 2006-07-19, 1:40 pm |
| gazelle@xmission.xmission.com (Kenny McCormack) writes:
>Is it possible to do the equivalent of dlopen with an executable (i.e.,
>not shared lib) ?
>When I try to dlopen() an (dynamically linked) executable program, I get
>a NULL return and the following error from dlerror():
>ld.so.1: ./myprog: elf error: ../path/something: not a shared or
>relocatable object: Error 0
>which is, of course, perfectly reasonable. But, ISTR, that it was
>somehow possible to do the same thing (i.e., execute routines stored
>within) a regular executable as well. Am I remembering wrong?
THe typical problem is that an executable is often not relocatable and
that it would be mapped on top of the current executable because of
overlapping address ranges; all processes are mapped at the same start
address on most systems.
So ld.so complains because an executable cannot be relocated.
Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
| |
| Kenny McCormack 2006-07-19, 7:25 pm |
| In article <87r70hmsb7.fsf@thalassa.informatimago.com>,
Pascal Bourguignon <pjb@informatimago.com> wrote:
>gazelle@xmission.xmission.com (Kenny McCormack) writes:
>
>
>It's more complicated, but with enough work, it should be doable.
>Firs tyou need to know what is the format of the excutable file
>(a.out, elf, cof, etc). Then locate a library allowing you to load
>it, find symbols, relocate it, dynamically link it with the libraries
>it needs, etc, and eventually you may be able to call some function
>from the executable.
>
>But really, it would be easier to type make in the source directory of
>the program, and then to build a dynamic library from the .o files
>remaining...
The problem is, of course, that the executable does not come with
source. Therefore, cannot re-compile, cannot "re-think what I am trying
to do".
And, FYI, the platform in question is Solaris.
I suppose I need to do some googling; just wanted to check to make sure
it wasn't something obvious that I was overlooking.
| |
| Barry Margolin 2006-07-20, 1:47 am |
| In article <87mzb5mq8z.fsf@thalassa.informatimago.com>,
Pascal Bourguignon <pjb@informatimago.com> wrote:
> Michael Vilain <vilain@spamcop.net> writes:
>
>
>
> Well, if gdb can do it:
gdb doesn't do it by linking the executable into its process. It runs
the executable in a separate process and controls/monitors it using
ptrace() (or something equivalent with /proc).
--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***
| |
| davids@webmaster.com 2006-07-20, 7:51 am |
|
Michael Vilain wrote:
> I've never heard of this capability. AFAIK, you can only link to shared
> libraries, not executables. Time for a rethink on what you're trying to
> do.
On Windows, DLLs and executables are almost identical. Executables can
even export functions that can be called the same way functions in a
DLL are called -- it's just almost never done.
If you think about it, there's really no special reason they need to be
different. They both need to be mapped and executed. They both contain
functions that need to be exported (otherwise, how could a DLL call a
function in the executable that called it?). They both need
initialization code to initialize their memory space and global objects
when they're loaded. And so on.
It just so happens that on most UNIXes, they are very different.
DS
| |
| Casper H.S. Dik 2006-07-20, 7:51 am |
| Paul Pluzhnikov <ppluzhnikov-nsp@charter.net> writes:
>gazelle@xmission.xmission.com (Kenny McCormack) writes:
[vbcol=seagreen]
>On Linux, "dlopen(NULL, ...)" returns you the handle to the main
>executable. This handle works fine for subsequent dlsym()s,
>provided the exe exports the function you need in its dynamic symbol
>table ("nm -D a.out").
Since Linux is generally a clone of the Solaris interface but than
usually some revs behind, the same mechanism also works for Solaris:
THere are several options in Solaris:
dlopen(NULL):
If the value of pathname is 0, dlopen() provides a handle on
a set of global symbol objects. These objects consist of the
original program image file, any dependencies loaded at pro-
gram startup, and any objects loaded using dlopen() with the
RTLD_GLOBAL flag. Because the latter set of objects can
change during process execution, the set identified by han-
dle can also change dynamically.
or fetch dlsym using a special object:
RTLD_DEFAULT
RTLD_NEXT
RTLD_SELF
Casper
| |
| Kenny McCormack 2006-07-20, 1:23 pm |
| In article <44bf707f$0$31650$e4fe514c@news.xs4all.nl>,
Casper H.S. Dik <Casper.Dik@Sun.COM> wrote:
>Paul Pluzhnikov <ppluzhnikov-nsp@charter.net> writes:
>
>
>
>
>Since Linux is generally a clone of the Solaris interface but than
>usually some revs behind, the same mechanism also works for Solaris:
Yes, but as you (I believe it was you) correctly surmised a response or
two back, the issue is that I want to have, essentially, 2 executables
running at once - i.e., a program that I write (in C, that compiles to
an ELF executable) that calls routines in another ELF executable.
I'm well aware of the dlopen(NULL) thing, but it doesn't apply here.
Note, incidentally, given that other posters have mentioned Windows and
made comparisons thereto, that the actual origin of this problem is:
I have an application which ships in both Windows and Solaris flavors
and I am able to do this thing in the Windows version (it is supported
there).
And, therefore, I'd like to be able to do the same in the Solaris version.
| |
| Seongbae Park 2006-07-22, 7:38 am |
| Kenny McCormack wrote:
....
> Yes, but as you (I believe it was you) correctly surmised a response or
> two back, the issue is that I want to have, essentially, 2 executables
> running at once - i.e., a program that I write (in C, that compiles to
> an ELF executable) that calls routines in another ELF executable.
>
> I'm well aware of the dlopen(NULL) thing, but it doesn't apply here.
>
> Note, incidentally, given that other posters have mentioned Windows and
> made comparisons thereto, that the actual origin of this problem is:
> I have an application which ships in both Windows and Solaris flavors
> and I am able to do this thing in the Windows version (it is supported
> there).
>
> And, therefore, I'd like to be able to do the same in the Solaris version.
Hm. I think, you can build both programs as shared libraries -
I think it's possible to execute a shared library directly with some
extra tricks
(you may need to wrap them inside a shell script, etc, etc).
Would it help ?
If you absolutely need one file to be both executable AND dlopen()'ed.
I think it's a lost cause, at least on Solaris,
mainly because executables are - unless you can hack up the
compiler/crt
- linked with code that have absolute addresses built in,
meaning that you can not load two executables in the same address space
because of address conflict (e.g. both executables will want to be
mapped
to the same virtual address range, or at least they will have some
overlap
- which it is possible to avoid by throwing different options to the
compiler
and the linker on some other platforms
but at least not readily on Solaris as far as I know).
Seongbae
|
|
|
|
|