public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
From: Mumit Khan <khan@xraylith.wisc.EDU>
To: Emanuele ALIBERTI <ealiberti@hotmail.com>
Cc: cygwin@sourceware.cygnus.com
Subject: Re: Dlls @n symbols
Date: Sun, 27 Jun 1999 12:24:00 -0000	[thread overview]
Message-ID: <199906271923.OAA08470@mercury.xraylith.wisc.edu> (raw)
In-Reply-To: <19990627155629.39032.qmail@hotmail.com>

Emanuele ALIBERTI <ealiberti@hotmail.com> writes:
> > > The goal for me is:
> > > 1. NOT having mangled names in the exports table
> > > 2. having an import library which lets ld lookup mangled names
> > > 3. having finally an application that imports UNmangled names
> > >
> > > I succeeded only with step 1.
> >
> >I don't understand (2) and (3). Could you please elaborate, with examples,
> >and then we can discuss if they're feasible or not. If these steps are
> >not possible with MSVC or Borland, chances are it won't be easily doable
> >or practical in GNU tools either.
> 
> Here is a full not working example. Perhaps I use dlltool the wrong way. (2) 
> is: test.a seems not having symbols for Foo@0 and Bar@24. If I uncomment 
> mangled names in the DEF file, they get defined, but appear also in the 
> DLL's exports table. (3) is: if I define the mangled names in the DEF, then 
> ld creates the application, but its imports table contains mangled names, 
> not clean names, so having a clean exports table in the DLL is useless!

Again, I'm unsure as to what you're trying to achieve here. If you tell 
the import library NOT to have mangled names, your client code won't link.
That's how things work (and so does MSVC, which is the native reference
implementation on windows32).

The reason to have "clean" names in the export list is simple -- so you
can use LoadLibrary. If you only need to use LoadLibrary, then you can
use the clean names. So have both in the export list! What's the big deal?

One way to achieve both is the following (and that's how MSVC developers
do this in case you're interested): Have two different export def files,
one for creating the DLL, and the other for creating the import library.
When creating the DLL, use the aliasing mechanism to get only clean names;
when creating the import library, using Foo@<n> etc and use -k to have
@<n> linkable symbols that point to export symbol without the @<n>, ie.,
the "clean" names.

Let me ask the same question I had the last time -- can you do what you
want with MSVC? If so, how?

If you feel like it's not doing the right thing, please feel free to 
start digging into binutils sources and see if you can help improve
it.

Regards,
Mumit


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

WARNING: multiple messages have this Message-ID
From: Mumit Khan <khan@xraylith.wisc.EDU>
To: Emanuele ALIBERTI <ealiberti@hotmail.com>
Cc: cygwin@sourceware.cygnus.com
Subject: Re: Dlls @n symbols
Date: Wed, 30 Jun 1999 22:10:00 -0000	[thread overview]
Message-ID: <199906271923.OAA08470@mercury.xraylith.wisc.edu> (raw)
Message-ID: <19990630221000.jDX5ZnA3_AL4xRYiqKlaAltqsCcImDWMvlOjXgj37iE@z> (raw)
In-Reply-To: <19990627155629.39032.qmail@hotmail.com>

Emanuele ALIBERTI <ealiberti@hotmail.com> writes:
> > > The goal for me is:
> > > 1. NOT having mangled names in the exports table
> > > 2. having an import library which lets ld lookup mangled names
> > > 3. having finally an application that imports UNmangled names
> > >
> > > I succeeded only with step 1.
> >
> >I don't understand (2) and (3). Could you please elaborate, with examples,
> >and then we can discuss if they're feasible or not. If these steps are
> >not possible with MSVC or Borland, chances are it won't be easily doable
> >or practical in GNU tools either.
> 
> Here is a full not working example. Perhaps I use dlltool the wrong way. (2) 
> is: test.a seems not having symbols for Foo@0 and Bar@24. If I uncomment 
> mangled names in the DEF file, they get defined, but appear also in the 
> DLL's exports table. (3) is: if I define the mangled names in the DEF, then 
> ld creates the application, but its imports table contains mangled names, 
> not clean names, so having a clean exports table in the DLL is useless!

Again, I'm unsure as to what you're trying to achieve here. If you tell 
the import library NOT to have mangled names, your client code won't link.
That's how things work (and so does MSVC, which is the native reference
implementation on windows32).

The reason to have "clean" names in the export list is simple -- so you
can use LoadLibrary. If you only need to use LoadLibrary, then you can
use the clean names. So have both in the export list! What's the big deal?

One way to achieve both is the following (and that's how MSVC developers
do this in case you're interested): Have two different export def files,
one for creating the DLL, and the other for creating the import library.
When creating the DLL, use the aliasing mechanism to get only clean names;
when creating the import library, using Foo@<n> etc and use -k to have
@<n> linkable symbols that point to export symbol without the @<n>, ie.,
the "clean" names.

Let me ask the same question I had the last time -- can you do what you
want with MSVC? If so, how?

If you feel like it's not doing the right thing, please feel free to 
start digging into binutils sources and see if you can help improve
it.

Regards,
Mumit


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

  reply	other threads:[~1999-06-27 12:24 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-06-27  8:57 Emanuele ALIBERTI
1999-06-27 12:24 ` Mumit Khan [this message]
1999-06-30 22:10   ` Mumit Khan
1999-06-30 22:10 ` Emanuele ALIBERTI
  -- strict thread matches above, loose matches on Subject: below --
1999-08-08 14:58 Emanuele ALIBERTI
1999-08-31 23:49 ` Emanuele ALIBERTI
1999-07-08  4:41 Emanuele ALIBERTI
1999-07-31 18:34 ` Emanuele ALIBERTI
1999-07-05 23:21 Emanuele ALIBERTI
1999-07-06 11:16 ` Mumit Khan
1999-07-31 18:34   ` Mumit Khan
1999-07-31 18:34 ` Emanuele ALIBERTI
1999-07-03  5:29 Emanuele ALIBERTI
1999-07-03  9:17 ` DJ Delorie
1999-07-31 18:34   ` DJ Delorie
1999-07-31 18:34 ` Emanuele ALIBERTI
1999-06-24 10:54 Jim Roy
1999-06-24 11:17 ` Mumit Khan
1999-06-30 22:10   ` Mumit Khan
1999-06-30 22:10 ` Jim Roy
1999-06-24  0:15 Emanuele ALIBERTI
1999-06-24 11:23 ` Mumit Khan
1999-06-30 22:10   ` Mumit Khan
1999-06-30 22:10 ` Emanuele ALIBERTI
1999-06-23  0:09 Emanuele ALIBERTI
1999-06-23  9:08 ` Mumit Khan
1999-06-30 22:10   ` Mumit Khan
1999-06-30 22:10 ` Emanuele ALIBERTI
1999-06-22 13:42 Suhaib M. Siddiqi
1999-06-30 22:10 ` Suhaib M. Siddiqi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=199906271923.OAA08470@mercury.xraylith.wisc.edu \
    --to=khan@xraylith.wisc.edu \
    --cc=cygwin@sourceware.cygnus.com \
    --cc=ealiberti@hotmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).