unresolved symbol & __nw__.... - HP UX

This is a discussion on unresolved symbol & __nw__.... - HP UX ; I have ran into a problem recently with a c++ idiom for keeping classes off the heap. For example, in our shared library we have something like this: class DoStuffClass { public: DoStuffClass() {...} // methods that do the actual ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: unresolved symbol & __nw__....

  1. unresolved symbol & __nw__....

    I have ran into a problem recently with a c++ idiom for keeping classes
    off the heap.

    For example, in our shared library we have something like this:

    class DoStuffClass
    {
    public:
    DoStuffClass() {...}
    // methods that do the actual stuff here...
    private:
    void* operator new(size_t size);
    void operator delete(void* p){}
    };

    I know this isn't fool-proof, but this is how the code is written.
    Recently when trying to do some testing the runtime failure of:

    /usr/lib/dld.sl: Unresolved symbol: __nw__5DoStuffClassSFUl (code)
    from ./libsharedlib.sl

    this __nw__5DoStuffClassSFUI is operator new(), but we are not making
    that call. It appears the compiler is making this call in various
    places - e.g. in a copy constructor? That doesn't make any sense to me
    yet, but that is what i see. I would assume the object owning the
    DoStuffClass has already been allocated, an the copy ctor would simply
    do a placement new on the offset of the containing class.

    I'm working on trying to get a simplified case to post, but so far the
    only way i can even get a reference to __nw__DoS.. is to explicitly
    call the operator new().

    Any body have words of advice? I'll try to get a smaller case to post
    tomorrow.

    thanks,
    tim


  2. Re: unresolved symbol & __nw__....

    tim.wojtaszek@gmail.com wrote:
    : I have ran into a problem recently with a C++ idiom for keeping classes
    : off the heap.

    This won't work for aC+ for PA.

    : private:
    : void* operator new(size_t size);
    : void operator delete(void* p){}

    You must define these operators. I.e. make them call abort.

    : /usr/lib/dld.sl: Unresolved symbol: __nw__5DoStuffClassSFUl (code)
    : this __nw__5DoStuffClassSFUI is operator new(), but we are not making
    : that call. It appears the compiler is making this call in various

    All aC++ constructors have 3 entry points, one does allocation and that
    calls operator new.

    This has been solved for aCC6 on IPF.

    : I'm working on trying to get a simplified case to post, but so far the
    : only way i can even get a reference to __nw__DoS.. is to explicitly
    : call the operator new().
    : tim

    You get the reference by calling the constructor when it isn't inlined.

    You may want to consider subscribing to CXX-DEV for aC++ questions:
    http://h21007.www2.hp.com/dspp/comm/...,1273,,00.html

  3. Re: unresolved symbol & __nw__....

    Marty Freitas wrote:
    > tim.wojtaszek@gmail.com wrote:
    > : I have ran into a problem recently with a C++ idiom for keeping classes
    > : off the heap.
    >
    > This won't work for aC+ for PA.


    But this is the oddest thing. We have to branches, the same compiler
    and system. There has been some code changes between them but nothing
    that seems like it would effect this, that is nothing is calling new
    anywhere for this object. The old branch works today, the new branch
    is failling?

    So it seems it works under some conditions it does work.


    >
    > : private:
    > : void* operator new(size_t size);
    > : void operator delete(void* p){}
    >
    > You must define these operators. I.e. make them call abort.


    This is probably what we will need to do. We would prefer a
    compile-time solution but i realize now that the current solution is
    not completely compile time due to the one constructor that is
    allocation memory. So a class can call new itself, but it can't be
    called externally by anyone. I think we can live with that.

    >
    > : /usr/lib/dld.sl: Unresolved symbol: __nw__5DoStuffClassSFUl (code)
    > : this __nw__5DoStuffClassSFUI is operator new(), but we are not making
    > : that call. It appears the compiler is making this call in various
    >
    > All aC++ constructors have 3 entry points, one does allocation and that
    > calls operator new.
    >
    > This has been solved for aCC6 on IPF.
    >
    > : I'm working on trying to get a simplified case to post, but so far the
    > : only way i can even get a reference to __nw__DoS.. is to explicitly
    > : call the operator new().
    > : tim
    >
    > You get the reference by calling the constructor when it isn't inlined.


    ah..good answer.
    >
    > You may want to consider subscribing to CXX-DEV for aC++ questions:
    > http://h21007.www2.hp.com/dspp/comm/...,1273,,00.html


    signed up, thanks.


  4. Re: unresolved symbol & __nw__....

    I'm still unsatisfied with what the dynamic loader is doing. Is there
    anyway to determine how/why it believes certain symbols are needed?

    I've tried looking with nm at the symbols as they occur in the library
    and there are only 2 places. One where the ctors and dtors are
    located, and another in an entry of unsat symbols.

    So i'm am confused why the dld doesn't simply mark these symbols as
    unreachable and continue? According to the linker and libraries user
    guide on the PA 32 system this is how it is suppose to work (page 181).
    For 64-bit it seems to be different, but i'll cross that bridge when i
    have to.

    For now, it appears that i can use chatr and set the executable as
    "nonfatal" for the interm until i fully understand the issue. Luckily
    this is currently just needed for integration testing so i have some
    time to work it out.

    thanks,
    tim

    NOTE: i will cross post this question to HPUX-DEVTOOLS because it is
    more related to the linker and symbol resolution than c++ specific, but
    i though i would put what i got working for me up.)


  5. Re: unresolved symbol & __nw__....

    tim wrote:
    : I'm still unsatisfied with what the dynamic loader is doing. Is there
    : anyway to determine how/why it believes certain symbols are needed?

    If there is an unsat for a symbol in an aC++ shared lib, it must be
    satisfied, if its address is taken.

    : I've tried looking with nm at the symbols as they occur in the library
    : and there are only 2 places. One where the ctors and dtors are
    : located, and another in an entry of unsat symbols.

    nm(1) is the wrong tool to look at PA32 shared libs.
    Use "/usr/ccs/bin/odump -slimport -slexport" instead.
    If you have both definitions and uses for the symbol, I don't see why you
    should have a problem??

    : So I'm confused why the dld doesn't simply mark these symbols as
    : unreachable and continue?

    It doesn't know they are unreachable. Advanced AI technology is needed to
    determine this.

    : According to the linker and libraries user
    : guide on the PA 32 system this is how it is suppose to work (page 181).

    I assume it is this one?
    Resolution of Unsatisfied Shared Library References
    http://docs.hp.com/en/B2355-90655/B2355-90655.pdf

    aC++ is special and defeats Smartbind. And it isn't available for PA64 or
    IPF.

    : NOTE: I will cross post this question to HPUX-DEVTOOLS because it is
    : more related to the linker and symbol resolution than C++ specific
    : tim

    Probably not really, it is aC++ specific.

+ Reply to Thread