Does anyone here understand DUMPBIN outout ?
CodeGuru Home VC++ / MFC / C++ .NET / C# Visual Basic VB Forums Developer.com
Results 1 to 6 of 6

Thread: Does anyone here understand DUMPBIN outout ?

  1. #1
    John E is offline Elite Member Power Poster
    Join Date
    Apr 2001
    Location
    Manchester, England
    Posts
    4,235

    Does anyone here understand DUMPBIN outout ?

    I'm building a DLL using VC++8 (Visual Studio 2005). Let's call it Dll-A. It gets linked to the symbols library for another DLL (let's call it Dll-B). My Debug version builds fine but when I try to build the Release version I get a couple of unresolved externals. I used DUMBIN to show me what was in Dll-B. I dumped both the Debug version and Release version and expected to find a couple of missing functions in the Release version. But in fact, both builds had the same exported functions.

    Interestingly, I can link the Release build of Dll-A to the Debug build for Dll-B so I figured there might be some kind of name mangling difference for the functions that can't be found. I viewed them in a Differ and here's what I found:-

    DEBUG version of Dll-B (a dump of one particular function)
    70 45 0000137A ?connect@signal_base@sigc@@IAE?AV?$_Iterator@$00@?$list@Vslot_base@sigc

    RELEASE version of Dll-B (a dump of the corresponding function in my Release build)
    70 45 000017F0 ?connect@signal_base@sigc@@IAE?AV?$_Iterator@$0A@@?$list@Vslot_base@sigc
    Each actual entry is a lot longer than that. I've only shown the first bit of the line as an example. Notice the sections highlighted in blue. Wherever there's a function that can't be found, the function signature is subtlely different, as highlighted. Does anyone know what the difference means? I can't see any obvious difference in the project's settings - expect for the usual stuff such as the Release version being optimized and not having any Debug information. But the settings are all the ones that I normally use and I've never had this problem before...
    "A problem well stated is a problem half solved. - Charles F. Kettering

  2. #2
    Join Date
    Apr 2000
    Location
    Belgium (Europe)
    Posts
    3,798

    Re: Does anyone here understand DUMPBIN outout ?

    They use different instances of the Iterator template.
    the debug version returns a Iterator<0> while the release returns a Iterator<1>

  3. #3
    John E is offline Elite Member Power Poster
    Join Date
    Apr 2001
    Location
    Manchester, England
    Posts
    4,235

    Re: Does anyone here understand DUMPBIN outout ?

    Thanks for the clue. I'm amazed at what actually caused the problem but I guess it'll make sense to the guys here.

    What happened was that Dll-B (the DLL being linked to) had been built with the pre-processor directive _SECURE_SCL=0 whereas Dll-A (the new one I was building) didn't specify anything for _SECURE_SCL, so I guess the default must be '1'.

    I've no idea why I build my Release versions with _SECURE_SCL=0. It must be because of some esoteric problem I encountered a long time ago - but it's interesting to know that if I build C++ DLL's with checked iterators enabled, they all need to have the same setting. My natural assumption would have been that it's okay for some DLL's to have the check enabled and others to have it disabled but obviously, it's not that simple!

    For some reason I seem to build my Debug code with _SECURE_SCL=1 and my Release code with _SECURE_SCL=0. Maybe I should review that...
    "A problem well stated is a problem half solved. - Charles F. Kettering

  4. #4
    Join Date
    Apr 2000
    Location
    Belgium (Europe)
    Posts
    3,798

    Re: Does anyone here understand DUMPBIN outout ?

    those are the defaults.
    debug code without optimisations gets bounds checking enabled (by default).
    release code with optimisations gets the bounds checks disabled (assumed you tested your code in a debug build). you'll have to explicitely enable it in release builds if that's what you want.


    in any case, when dealing with dll's, you can only safely call one dll to another if they're built as a unit. When compiled and released separately... you shouldn't even make assumptions that they are using the same instance of the C++ runtime. If you're returning templates, then you're going to be in for trouble if you didn't build both dll's with compatible settings. (as you discovered).

  5. #5
    Join Date
    Oct 2008
    Posts
    1,090

    Re: Does anyone here understand DUMPBIN outout ?

    Quote Originally Posted by OReubens View Post
    release code with optimisations gets the bounds checks disabled (assumed you tested your code in a debug build). you'll have to explicitely enable it in release builds if that's what you want.
    actually, this is true since vc2010 only. Previous versions had it turned on by default in release too ...

  6. #6
    John E is offline Elite Member Power Poster
    Join Date
    Apr 2001
    Location
    Manchester, England
    Posts
    4,235

    Re: Does anyone here understand DUMPBIN outout ?

    Quote Originally Posted by superbonzo View Post
    actually, this is true since vc2010 only. Previous versions had it turned on by default in release too ...
    Ah... that's probably why I explicitly turned it off.! I'm using VC2005 for this particular project.
    "A problem well stated is a problem half solved. - Charles F. Kettering

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  


Azure Activities Information Page

Windows Mobile Development Center


Click Here to Expand Forum to Full Width

This is a CodeGuru survey question.


Featured


HTML5 Development Center