Re: Report proper errors from the loadlibrary loader.

2010-01-11 Thread Peter Rosin

Den 2010-01-04 21:48 skrev Ralf Wildenhues:

Hi Peter,

* Peter Rosin wrote on Sat, Jan 02, 2010 at 04:02:57AM CET:

Please consider the attached patch.

I'm just about to go skiing for a week or so, so I'll push when I get
back if this patch is blessed (knock wood) after I leave...


Well happy new year and hope you had a fun time in the snow!


That I did, and so did the kids, the weather was superb, a bit on the
cold side though (-20 to -30 degrees C or so). But sunny (the sky was
clear), no wind and very dry so therefore not unbearable...


What does this patch and its followup fix get us?  What behavior changed
in relation to previous code, and if this is fixing a bug, is there need
and chance to test for it?


Previously the reported error was a plain "can't open the module" or
"symbol not found", even though the system might have reported why it
could not open the library or not find the symbol. I would say it's
about the same as using dlerror when present in the dlopen loader.

It would be possible to test if the reported error is not "can't open
the module" / "symbol not found", under the assumption that it is
un likely for Microsoft/Wine to have used those exact words and case,
but that would require some way to check if the used loader was in
fact the loadlibrary loader and skip if not. I don't know how to do
the last part (Cygwin uses .dll for its dlopen loader, so that check
is a no-no).


(honest questions, not trying to criticise the patch in any way)


No problem, and cheers,
Peter

--
They are in the crowd with the answer before the question.
> Why do you dislike Jeopardy?




Re: libtool, llvm-gcc, failing C++ exceptions

2010-01-11 Thread Ralf Wildenhues
Hi Bob,

* Bob Friesenhahn wrote on Mon, Jan 11, 2010 at 05:32:15AM CET:
> On Sun, 10 Jan 2010, Ralf Wildenhues wrote:
> >>
> >>My main comment is that it would be useful if the thrown class is
> >>derived from std:exception (or one of its standard derived classes)
> >>in order to flush out any issues which may stem from possible
> >>partial template instantiation in libstdc++ (or pre-compiled
> >>headers) as well as in the test translation unit.
> >
> >OK, sounds useful.  Would that entail more than just something like
> >this incremental addition?
> 
> I think that the virtual what() method needs to be provided or else
> you have only a partially implemented class:
[...]

Yup, indeed.  And we need to provide a throw()-qualified destructor as
well.

> But this is a better class to test with since it uses more standard
> library stuff and is therefore more likely to fail if something is
> wrong:
[...]

Thanks.  I'm pushing the test with this incremental addition squashed
into the first iteration of the patch, and listing you as second author.

Cheers,
Ralf

diff --git a/tests/exceptions.at b/tests/exceptions.at
index d551cb8..920b30e 100644
--- a/tests/exceptions.at
+++ b/tests/exceptions.at
@@ -29,7 +29,19 @@ AT_KEYWORDS([libltdl])
 CPPFLAGS="$LTDLINCL $CPPFLAGS"
 
 AT_DATA([module.h],
-[[class modexc { };
+[[#include 
+#include 
+class modexc : public std::exception {
+public:
+  modexc (std::string str) : message (str) { }
+  ~modexc () throw () { }
+  virtual const char *what () const throw ()
+  {
+return message.c_str ();
+  }
+private:
+  std::string message;
+};
 extern "C" int modfoo () throw (modexc);
 ]])
 
@@ -39,7 +51,7 @@ AT_DATA([module.cpp],
 
 int modbar (void) throw (modexc)
 {
-  throw modexc ();
+  throw modexc ("exception in module");
 }
 
 extern "C"
@@ -48,16 +60,28 @@ int modfoo (void) throw (modexc)
   try {
 modbar ();
   }
-  catch (modexc) {
-std::cerr << "caught inside module\n";
-throw modexc ();
+  catch (modexc e) {
+std::cerr << "caught inside module: " << e.what () << '\n';
+throw modexc ("exception from module");
   }
   return 0;
 }
 ]])
 
 AT_DATA([lib.h],
-[[class libexc { };
+[[#include 
+#include 
+class libexc : public std::exception {
+public:
+  libexc (std::string str) : message (str) { }
+  ~libexc () throw () { }
+  virtual const char *what () const throw ()
+  {
+return message.c_str ();
+  }
+private:
+  std::string message;
+};
 int libfoo () throw (libexc);
 ]])
 
@@ -67,7 +91,7 @@ AT_DATA([lib.cpp],
 
 int libbar (void) throw (libexc)
 {
-  throw libexc ();
+  throw libexc ("exception in library");
 }
 
 int libfoo (void) throw (libexc)
@@ -75,9 +99,9 @@ int libfoo (void) throw (libexc)
   try {
 libbar ();
   }
-  catch (libexc) {
-std::cerr << "caught inside lib\n";
-throw libexc ();
+  catch (libexc e) {
+std::cerr << "caught inside lib: " << e.what () << '\n';
+throw libexc ("exception from library");
   }
   return 0;
 }
@@ -87,14 +111,26 @@ AT_DATA([main.cpp],
 [[#include 
 #include 
 #include 
+#include 
+#include 
 #include "lib.h"
 #include "module.h"
 
-class exc { };
+class exc : public std::exception {
+public:
+  exc (std::string str) : message (str) { }
+  ~exc () throw () { }
+  virtual const char *what () const throw ()
+  {
+return message.c_str ();
+  }
+private:
+  std::string message;
+};
 
 int foo (void) throw (exc)
 {
-  throw exc ();
+  throw exc ("exception in program");
   return 0;
 }
 
@@ -104,8 +140,8 @@ int exceptions_in_prog (void)
   try {
 foo ();
   }
-  catch (exc) {
- std::cerr << "caught\n";
+  catch (exc e) {
+ std::cerr << "caught: " << e.what () << '\n';
 return 0;
   }
   return 1;
@@ -117,8 +153,8 @@ int exceptions_in_lib (void)
   try {
 libfoo ();
   }
-  catch (libexc) {
- std::cerr << "caught\n";
+  catch (libexc e) {
+ std::cerr << "caught: " << e.what () << '\n';
 return 0;
   }
   return 1;
@@ -161,7 +197,8 @@ int exceptions_in_module (void)
   try {
 (*pf) ();
   }
-  catch (modexc) {
+  catch (modexc e) {
+std::cerr << "caught: " << e.what () << '\n';
 if (lt_dlclose (handle))
   {
 std::cerr << "dlclose failed: " << lt_dlerror () << '\n';




Re: libtool, llvm-gcc, failing C++ exceptions

2010-01-11 Thread Charles Wilson
Ralf Wildenhues wrote:
> Yup, indeed.  And we need to provide a throw()-qualified destructor as
> well.

A word of warning: not all implementations of std::exception use the
'throw' specifier on the virtual what() method. So, if you add it on
your derived class but the base class doesn't have it, you may get
[errors|warnings|pain].

Not sure what to do about it, short of adding a configure test...

--
Chuck





Re: libtool, llvm-gcc, failing C++ exceptions

2010-01-11 Thread Ralf Wildenhues
Hi Charles,

* Charles Wilson wrote on Tue, Jan 12, 2010 at 12:42:21AM CET:
> Ralf Wildenhues wrote:
> > Yup, indeed.  And we need to provide a throw()-qualified destructor as
> > well.
> 
> A word of warning: not all implementations of std::exception use the
> 'throw' specifier on the virtual what() method. So, if you add it on
> your derived class but the base class doesn't have it, you may get
> [errors|warnings|pain].
> 
> Not sure what to do about it, short of adding a configure test...

The test is currently skipped if the compiler doesn't like main.cpp
(which already exposes this API), so we should be safe there but not
test on as many systems as we could.  I added that for those kinds of
issues, but primarily for the older, pre-standard C++ compilers that
don't grok namespaces etc.

A missing throw() on virtual what() is a violation of ISO C++98 however.

Cheers,
Ralf