Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Development mailing list

Subject: Re: [OMPI devel] [OMPI svn] svn:open-mpi r22014
From: Jeff Squyres (jsquyres_at_[hidden])
Date: 2009-09-30 06:01:10


I still don't think these need to be DECLSPEC. Debuggers can find
local symbols (including static symbols). Sun was having a problem
with the Intel compilers because the function was being inlined -- and
therefore the symbol didn't exist at all.

Removing the "static" was a simple optimization to force the intel
compiler to *not* inline the function. That's all.

We should *not* be exposing the MPIR_Breakpoint function to user
applications who -lmpi. That is what putting DECLSPEC there will do.

I believe that the DECLSPEC should be removed.

On Sep 30, 2009, at 12:08 AM, George Bosilca wrote:

> Ethan is right. The MPIR_Breakpoint function will be queried by your
> preferred parallel debugger, in order to set a breakpoint. Therefore,
> to allow the debuggers to be able to find the function we have to make
> sure it is externally visible, i.e. flagged with OMPI_DECLSPEC (for
> the one in libmpi) and with ORTE_DECLSPEC for the one in libopen-rte.
> And yes, we really need the *_DECLSPEC to make it visible, extern is
> not enough.
>
> Moreover, looking in the ompi/debugger/debugger.h file I realized that
> the two functions declared inside are flagged OMPI_DECLSPEC when they
> should not have been, as these two functions are not called from
> outside the libmpi.
>
> Please try r22032.
>
> george.
>
> On Sep 29, 2009, at 17:55 , Jeff Squyres wrote:
>
> > On Sep 29, 2009, at 5:30 PM, Ralph Castain wrote:
> >
> >> The issue isn't why or why not static, Jeff - the issue is that we
> >> get
> >> a compiler warning whenever we do a developer build.
> >>
> >
> > Right. The initial issue was the static-ness, though -- Ethan
> > removed the static because some compilers were effectively inlining
> > the function (and therefore removing the symbol from the library,
> > making the parallel debugger attach stuff not work) presumably
> > because a) the function was static, b) the function was short with
> > no side effects, and c) the function was only called once within
> > that .c file.
> >
> > Removing the "static" from the function prototype violated those
> > assumptions so that it could no longer be inlined (And therefore the
> > symbol definitely appears in the library). But then we ran across
> > the "must be prototyped" warning.
> >
> > That's where all this came from. :-)
> >
> > So -- I still don't think we need to DECLSPEC the prototype. :-)
> >
> >> On Sep 29, 2009, at 2:32 PM, Jeff Squyres wrote:
> >>
> >> > I don't think we need to DECLSPEC it, do we? We don't need (or
> >> > want) this symbol to be visible at the link level when user apps
> >> > link against libmpi. You might want to put in a comment about
> why
> >> > it's not static so that we don't repeat this conversation again
> >> next
> >> > year. ;-)
> >> >
> >> > I think not having it DECLSPEC'ed should still work for the
> >> debugger
> >> > (since it worked before when it was static), but if you could
> test
> >> > it to be sure, that would be great...
> >>
> >
> >
> > --
> > Jeff Squyres
> > jsquyres_at_[hidden]
> >
> > _______________________________________________
> > devel mailing list
> > devel_at_[hidden]
> > http://www.open-mpi.org/mailman/listinfo.cgi/devel
>
> _______________________________________________
> devel mailing list
> devel_at_[hidden]
> http://www.open-mpi.org/mailman/listinfo.cgi/devel
>

-- 
Jeff Squyres
jsquyres_at_[hidden]