decorated dll function -> undecorated ?

Martin Richter

Nein. Man benötigt dazu keine def Datei.
1. extern "C" sorgt dafür dass der Name nicht in C++ Manier gemangelt wird.
2. Ohne DEF Datei bleibt evtl. ein Underbar '_' übrig.
3. Aber auch den bekommt man ohne DEF Datei weg.
Siehe:
http://blog.m-ri.de/index.php/2008/02/22/vs-tipps-tricks-benoetigt-man-eigentlich-noch-def-dateien/

7x7-7

Hallo Martin Richter,
vielen Dank für den Hinweis – ich habe mal versucht, die in Ihrem Blog skizzierte Herangehensweise nachzuvollziehen. Leider habe ich vermutlich etwas nicht verstanden, denn es gibt folgende Fehlermeldung:
MathfuncDll.obj : fatal error LNK1276: Ungültige =-Direktive gefunden. Sie beginnt nicht mit "/".

Wie in dem Blog skizziert habe ich zunächst die zu exportierende Funktion folgendermaßen definiert (ich bin immer noch bei dem anfangs zitierten M$ Beispiel)
Klasse:

// MathFuncsDll.h
namespace MathFuncs
{
class MyMathFuncs
    {
    public:		
	 __declspec(dllexport) double Add(double a, double b);

    *
    *
    *
   };
}

/********************************************
#include "MathfuncDll.h"
#include <stdexcept>
using namespace std;
namespace MathFuncs
{

//#pragma comment(linker, "/EXPORT:Add = ?Add@MyMathFuncs@MathFuncs@@QAENNN@Z")
 __declspec(dllexport) double MyMathFuncs::Add(double a, double b)
    {
        return a + b;
    }

*
*
*
}

dumpbin -exports "file.dll" liefert:
1 0 00011159 ?Add@MyMathFuncs@MathFuncs@@QAENNN@Z = @ILT+340(?Add@MyMathFuncs@MathFuncs@@QAENNN@Z)

Ich habe anschließend, wie im Blog skizziert, den decorated name per copy &paste entnommen und in die pragma zeile eingefügt und die __declspec(dllexport) Anweisung in der Klasse sowie vor der Funktionsdeklartion entfernt.

#pragma comment(linker, "/EXPORT:Add = ?Add@MyMathFuncs@MathFuncs@@QAENNN@Z")
 double MyMathFuncs::Add(double a, double b)
    {
        return a + b;
    }

..und dann den Fehler:LNK1276 erhalten.

Verraten Sie doch bitte, wo der Fehler liegt.

MfG

Bashar

Eine nichtstatische Memberfunktion als extern "C"? Würde mich wundern, wenn das geht. Der primäre Zweck von extern "C" ist nicht, die Namen aufzuhübschen, sondern ein Symbol von einem in C geschriebenen Modul aus zugänglich zu machen. C kann aber keine Memberfunktionen aufrufen, also sollte extern "C" in dem Fall keine Wirkung haben. Versuch es mal mit einer freien Funktion oder wenigstens mit einer statischen Memberfunktion.

hustbaer

@7x7-7
Vergleich mal

/EXPORT:Add = ?Add@MyMathFuncs@MathFuncs@@QAENNN@Z

und

/EXPORT:Add=?Add@MyMathFuncs@MathFuncs@@QAENNN@Z

Fällt dir was auf?

ps: wir sind hier alle per Du. Ich werde dich daher duzen. Wäre nett wenn du das selbe machst, das "Sie" wirkt hier sehr befremdlich.

7x7-7

Hallo Martin Richter,

wie es aussieht hatte ich ein Leerzeichen zu viel - so funktioniert es nun:

#pragma comment(linker, "/export:Add=?Add@MyMathFuncs@MathFuncs@@QAENNN@Z")
double MyMathFuncs::Add(double a, double b)
    {
        return a + b;
    }

Leider enthält das das dumpbin – exports „file.dll“ Ergebnis immer noch einen Verweis auf die kryptische Funktionsbezeichnung (genau wie bei der def -Datei Vorgehensweise):

4 0 00011159 Add = @ILT+340(?Add@MyMathFuncs@MathFuncs@@QAENNN@Z)

Kann man den decortaed name hinter dem "=" unterdrücken ?

MfG

7x7-7

Hallo hustbaer,

vielen Dank für den Hinweis - ich habe ihn vermutlich nicht rechtzeitig gesehen, während ich noch an meiner Antwort herumformuliert hatte.

Aber meine ursprüngliche Frage ist immer noch aktuell..:)

MfG

7x7-7

Hallo Martin Richter,

ich habe mal ein wenig mit Deiner Methode weiter herumexperimentiert und bin durch Zufall auf den „Punkt“ gekommen:

#pragma comment(linker, "/export:Add=..")
double MyMathFuncs::Add(double a, double b)
    {
        return a + b;
    }

Ich habe zwar keine Ahnung, was diese Option bewirkt, aber die Funktion kann ich trotzdem mit einer anderen Anwendung, in die das Dll eingebunden habe laden und benutzen.
dumpbin –exports „file.dll“ liefert nun: 4 0 Add (forwarded to ..)
Zumindest ist dieser kryptische Name hinter dem “=” verschwunden – nur das “Add” jetzt zu „.“ weitergeleitet wurde. Es muss doch irgendetwas geben, um sämtliche Zusatzinformation gänzlich zu unterdrücken, so dass einfach nur dasteht: Add – meinetwegen auch: 4 0 Add.
MFG

7x7-7

Hallo Martin Richter,

Deine Variante ist doch perfekt – ich habe jetzt noch diesen Beitrag: http://stackoverflow.com/questions/2804893/c-dll-export-decorated-mangled-names
berücksichtigt (Projekt- Eigenschaftenseiten-> Linker->Debugging -> Debuginfo generieren -> Nein).
Jetzt ist alles so wie ich es haben wollte. Ich habe auch nochmal die Variante mit der Def- Datei getestet – auch in diesem Fall kann die „zusätzliche Information“, die mit dumpbin –exports „fill.dll“ ursprünglich im Debug Modus angezeigt wird, unterdrückt werden.

Also vielen Dank für alle Hinweise – ich glaube das Problem ist gelöst.

MfG

Martin Richter

Das mit den Debug-Infos ist doch totaler Quatsch.

1. Sind diese nur in der PDB Datei drinund die wird nicht aufgelöst.
2. Dumpbin benutzt diese aber wenn sie da sind.
3. Ohne Debug Infos kannst Du keine Crashes verfolgen und Minidumps analysieren.
4. Ist mir eigentlich nicht klar, wass das bezwecken soll.

7x7-7

Hallo Martin Richter,

ja Du hast natürlich recht: Die Information hinter dem Exportnamen vom Typ „ =decorated name“ ist im file.pdb gespeichert – wusste ich vorher leider nicht. Solange diese Datei an ihrem Ort verweilt, spielt es wohl auch keine Rolle, wo man das dll auf dem Computer hin kopiert – die decorated name Infos werden über dumpbin –exports „file.dll“angezeigt. So dachte ich zumindest vorher, ausschließen zu können, dass eben nicht derartige Infos in einer anderen Datei gespeichert sind und dachte daher ferner, dass mit der von mir erstellten Dll irgendetwas nicht stimmt. Naja falschgedacht.
Löscht oder verschiebt man die pdb Datei jedoch, so sieht das dumpbin –exports „file.dll“ Ergebnis aus, wie bei käuflich erworbenen dll’s.
Das wusste ich vorher nicht – Danke für die Info.

MfG

decorated dll function -&gt; undecorated ?

decorated dll function -> undecorated ?