dlopen

dlopen

[Jorrit Tyberghein]

Hi,

How can I use dlopen/dlsym/dlcose from CygWinB19 with EGCS 1.1?
I can't find a reference to dlopen in any of the include files although it seems
to be in some of the executables/libraries?

Greetings and thanks in advance,

--
==============================================================================
Jorrit.Tyberghein@uz.kuleuven.ac.be, University Hospitals KU Leuven BELGIUM

"One minute I'm just another rabbit and happy about it, next minute
*whazaam*, I'm thinking. That's a major drawback if you're looking for
happiness as a rabbit, let me tell you. You want grass and sex, not
thoughts like 'What's it all about, when you get right down to it?'"
        -- (Terry Pratchett, Moving Pictures)
==============================================================================



-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: dlopen

[Gary V. Vaughan]

Jorrit Tyberghein wrote:
> 
> How can I use dlopen/dlsym/dlcose from CygWinB19 with EGCS 1.1?
> I can't find a reference to dlopen in any of the include files 
> although it seems to be in some of the executables/libraries?

The dlfcn.h file from the source distribution never made it into
the cdk.exe.  You need to get the cygwin32 sources from the same
place as you got the cdk and copy the dlfcn.h file into
$CYGWIN_ROOT/H-i386-cygwin32/i386-cygwin32/include.  Then dlopen
and friend will (mostly) work as usual.

Geoffrey, I notice that the dlopen emulation doesn't handle a NULL
argument as per the POSIX spec (i.e. return an introspective handle
to the current process), yet the win32 GetModuleHandle does... will this
be fixed for b20?  Too late for a patch?

Cheers,
	Gary V. Vaughan
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: dlopen

[Geoffrey Noer]

On Fri, Oct 30, 1998 at 12:19:55PM +0000, Gary V. Vaughan wrote:
>
> Geoffrey, I notice that the dlopen emulation doesn't handle a NULL
> argument as per the POSIX spec (i.e. return an introspective handle
> to the current process), yet the win32 GetModuleHandle does... will this
> be fixed for b20?  Too late for a patch?

Yep, much too late.  I will gladly take a patch after b20 is out
however...

-- 
Geoffrey Noer
noer@cygnus.com
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

dlopen patch [was Re: dlopen]

[Gary V. Vaughan]

Geoffrey Noer wrote:
>
> On Fri, Oct 30, 1998 at 12:19:55PM +0000, Gary V. Vaughan wrote:
> >
> > Geoffrey, I notice that the dlopen emulation doesn't handle a NULL
> > argument as per the POSIX spec (i.e. return an introspective handle
> > to the current process), yet the win32 GetModuleHandle does... will
> > this be fixed for b20?  Too late for a patch?
>
> Yep, much too late.  I will gladly take a patch after b20 is out
> however...

Better late than never?  Diffs attached.  Interestingly, this doesn't
seem to fix my particular problem -- but unless there is funkiness with
casting from HMODULE (dlopen) to void* (dlsym) to HINSTANCE
(GetProcAddress), then by inspection it really ought to work, according
to the Borland Win32 API docs.

I guess my implementation is awry somehow.

Cheers,
	Gary V. Vaughan
--- dlfcn.cc.orig	Tue Nov 10 11:58:45 1998
+++ dlfcn.cc	Tue Nov 10 12:07:11 1998
@@ -127,9 +127,21 @@ get_full_path_of_dll (const char* str)
 void *
 dlopen (const char *name, int)
 {
-  const char *fullpath = get_full_path_of_dll (name);
-  DllList::the().currentDlOpenedLib (fullpath);
-  void *ret = (void *) LoadLibrary (fullpath);
+  void *ret = 0;
+
+  if (!name)
+    {
+      // handle for the current module
+      ret = (void *) GetModuleHandle (0);
+    }
+  else
+    {
+      // handle for the named library
+      const char *fullpath = get_full_path_of_dll (name);
+      DllList::the().currentDlOpenedLib (fullpath);
+      ret = (void *) LoadLibrary (fullpath);
+    }
+
   if (!ret)
     set_dl_error ("dlopen");
   debug_printf ("ret %p", ret);

RE: dlopen patch [was Re: dlopen]

[Christian Jullien]

> Better late than never?  Diffs attached.  Interestingly, this doesn't
> seem to fix my particular problem -- but unless there is funkiness with
> casting from HMODULE (dlopen) to void* (dlsym) to HINSTANCE
> (GetProcAddress), then by inspection it really ought to work, according
> to the Borland Win32 API docs.
>
> I guess my implementation is awry somehow.
>
> Cheers,
> 	Gary V. Vaughan

Thank you for your post but the problem if (much ?) more complex.

Your patch, the same I've already tested before, is not suffisent.
dlsym supports a NULL handle (no needs to dlopen first), you can fix this
with :

void *
dlsym (void *handle, const char *name)
{
-  void * ret = (void *) GetProcAddress (handle, name);
+  void * ret = 0;
+
+  if( handle )
+        ret = (void *) GetProcAddress (handle, name);
+  else  ret = (void *) GetProcAddress (GetModuleHandle(), name);

  if (!ret)
    set_dl_error ("dlsym");
  debug_printf ("ret %p", ret);
  return ret;
}

But it does not work since all symbols MUST be exported (am I right ?). In
my special case I can't export all symbols,
I've also a lot (>= 50000) generated assembler lines.

The HUGLY things I've made to work is to link my program 3 (THREE) times !!

1) 1st pass, I link my program with a dummy nlist.c file with :

   struct {
   	unsigned long s_add;
   	char*	      s_type;
   	char*	      s_name;
   } _nlist_tab[] = {
   	{ 0x00000000, "?", (char*)0 }
   };

2) then I make a 2nd link filling _nlist_tab[] with

   nm myapp.exe | sed -f C/nlist.sed | grep "0x0" >> nlist.c

   nlist.sed:
   s/^\([0-9A-Fa-f]*\) \([DT]\) *\([_A-Za-z0-9]*\).*$/ { 0x\1, "\2",
"\3" },/g

   nlist.c becomes :

   struct {
	unsigned long s_add;
	char*	      s_type;
	char*	      s_name;
   } _nlist_tab[] = {
	{ 0x0041adb8, "T", "_BnAdd" },
	{ 0x0041ad90, "T", "_BnAddCarry" },
	{ 0x0041acc8, "T", "_BnAndDigits" },
	...
   	{ 0x00000000, "?", (char*)0 }
   };

   This second link makes my program have the good size with _nlist_tab


3) I make the final link with the same command again

   nm myapp.exe | sed -f C/nlist.sed | grep "0x0" >> nlist.c

   this time it fills _nlist_tab with the good address VALUES.


In my case, the dlsym equivalent is simply (:-<)

unsigned long
my_dlsym( char* strg )
{
	extern struct {
		unsigned long s_add;
		char*	      s_type;
		char*	      s_name;
	} _nlist_tab[];

	/* s_type is not used in my case, a dicotomic search could be used */

	int i;
	for( i = 0 ; _nlist_tab[i].s_name != 0 ; i++ )
		if( strcmp( _nlist_tab[i].s_name, strg ) == 0 )
			return( _nlist_tab[i].s_add );

	return 0;

}

I guess that the same result could be found by plugging a subset of nm tool
but
I had no time (or energy) to inspect this way yet.

If you have a better solution I will be happy to test it (and/or to improve
it).

Thanks

Christian Jullien

-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

RE: dlopen patch [was Re: dlopen]

[Mumit Khan]

[-- Attachment #1: Type: text/plain, Size: 960 bytes --]

"Christian Jullien" <Eligis@wanadoo.fr> writes:
> 
> But it does not work since all symbols MUST be exported (am I right ?). In
> my special case I can't export all symbols,
> I've also a lot (>= 50000) generated assembler lines.

That's correct. Of course, the solution is simple since all you need to 
do is to link with an export file (dlltool can create that easily), and 
with Gary's patch you can dlopen/dlsym the function quite easily.

> If you have a better solution I will be happy to test it (and/or to improve
> it).

I'm attaching a trivial example (to run this, you have to have Gary's
patch or wait for b20.1). Please let me know if this doesn't work for
your application.

btw, a good example for this is in Perl's configuration, where perl is
built as an exportable executable. You can also use dllwrap (with a
few extra semi-documented flags), but it's just as easy doing it using
the simple Makefile included in my example.

Regards,
Mumit


[-- Attachment #2: exp-exe.tar.gz --]
[-- Type: application/x-gzip, Size: 688 bytes --]

RE: dlopen patch [was Re: dlopen]

[Christian Jullien]

It could works but not for me !!!
I have ~50000 lines or so automatically generated .s files from a virtual
machine called LLM3 and I must also have access to my assembler symbols.
For an historical reason, all public assembler symbols have NO leading '_'
(i.e. foo is
just called 'foo' not '_foo').
It's the way it works on Linux, SCO, Solaris, unixware, DOS, NT, ...
On unix systems, it just works fine with 'old' nlist interface or more
modern dlopen/dlsym calls. On DOS, NT I've made the same hugly hack with (2
additional links).
Here, of course, dlltool removes leading '_' to match the name you wrote,
not the internal one.
On link, I just got 'foo' undefined because it assumes it's _foo and _foo is
not defined.
I'm so sade.


> -----Original Message-----
> From: Mumit Khan [ mailto:khan@xraylith.wisc.edu ]
> Sent: Monday, November 16, 1998 8:16 AM
> To: Christian Jullien
> Cc: Gary V. Vaughan; Geoffrey Noer; Jorrit Tyberghein;
> gnu-win32@cygnus.com
> Subject: RE: dlopen patch [was Re: dlopen]
>
>
> "Christian Jullien" <Eligis@wanadoo.fr> writes:
> >
> > But it does not work since all symbols MUST be exported (am I
> right ?). In
> > my special case I can't export all symbols,
> > I've also a lot (>= 50000) generated assembler lines.
>
> That's correct. Of course, the solution is simple since all you need to
> do is to link with an export file (dlltool can create that easily), and
> with Gary's patch you can dlopen/dlsym the function quite easily.
>
> > If you have a better solution I will be happy to test it
> (and/or to improve
> > it).
>
> I'm attaching a trivial example (to run this, you have to have Gary's
> patch or wait for b20.1). Please let me know if this doesn't work for
> your application.
>
> btw, a good example for this is in Perl's configuration, where perl is
> built as an exportable executable. You can also use dllwrap (with a
> few extra semi-documented flags), but it's just as easy doing it using
> the simple Makefile included in my example.
>
> Regards,
> Mumit
>
>

-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".