DBX showing incorrect values in shared library built with -g

Question

-bash-3.2$ uname -a
SunOS b2s-sol10spr-1 5.10 Generic_147147-26 sun4v sparc sun4v
-bash-3.2$ dbx -V
Sun DBX Debugger 8.0 SunOS_sparc 2014/10/21
For information about new features see `help changes'
To remove this message, put `dbxenv suppress_startup_message 8.0' in your .dbxrc
(dbx)

I'm getting a weird issue where the debugger is just showing completely wrong values for function parameters & local/member variables.

Here's a sample backtrace

=>[1] SQLGetDiagRecW(HandleType = -28417, Handle = 0x480000000101dfc1, RecNumber = -12288, Sqlstate = (nil), NativeError = 0xffffffff7fffdf, MessageText = 0x9100000001002bbd, BufferLength = -9583, TextLength = 0x380000000101da91), line 3154 in "CInterface.cpp"
  [2] extract_diag_error_w(htype = 3, handle = 0x3, connection = 0x1014d32c0, head = 0x101e5a5e0, return_code = -1, save_to_diag = 0), line 4447 in "__info.c"
  [3] function_return_ex(level = 3, handle = 0x101e5a1a0, ret_code = -1, save_to_diag = 0), line 4863 in "__info.c"
  [4] SQLExecDirectW(statement_handle = 0x101e5a1a0, statement_text = 0x101dacde0, text_length = -3), line 442 in "SQLExecDirectW.c"
  <truncated>

Frame 1 is in the problematic shared library, while the other frames are in the unixODBC libodbc.so

If we look at the code for extract_diag_error_w (you can get the code from http://www.unixodbc.org/unixODBC-2.3.1.tar.gz, the following snippet is from DriverManager/__info.c )

ret = SQLGETDIAGRECW( connection,
                head -> handle_type,
                handle,
                rec_number,
                sqlstate,
                &native,
                msg1,
                sizeof( msg1 ),
                &len );

Note that we have, elsewhere

#define SQLGETDIAGRECW(con,typ,han,rn,st,nat,msg,bl,tlp)\
                                    (con->functions[77].funcW)\
                                        (typ,han,rn,st,nat,msg,bl,tlp)

in dbx, if I go to frame 2 and print head -> handle_type, I get 3, but if I go to frame 1 and print HandleType, I get -28417.

I'd expect dbx, if it can't find the value (due to optimization or w/e, even though this was a debug build), to tell me so (<value optimized out> or somesuch). Also, every value I look at seems to be wrong (I've confirmed that the debugger is lying to me via control flow, there's code like if (x < 0) throw ...; where dbx claims it's some negative number, but the exception doesn't get thrown.

The problematic shared libary was built on another machine (while unixODBC was built locally), so maybe that's involved? It was also built w/ gcc, where I used the default compiler when building unixODBC (though I think it's also w/ gcc, since they both have a dependency on libgcc_s.so.1)

Any suggestions? (I'd guess updating dbx might work, but it would be difficult in this environment).

edit: Here's an example w/ local variables

(dbx) next
t@1 (l@1) stopped in Simba::Support::ODBCStringConverter::ConvertWStringToSQLWCHARString at line 64 in file "ODBCStringConverter.cpp"
   64       simba_int32 length = in_length;
(dbx) next
t@1 (l@1) stopped in Simba::Support::ODBCStringConverter::ConvertWStringToSQLWCHARString at line 66 in file "ODBCStringConverter.cpp"
   66       if (0 == in_length)
(dbx) print length
length = 11
(dbx) print in_length
in_length = 419430399
(dbx) next
t@1 (l@1) stopped in Simba::Support::ODBCStringConverter::ConvertWStringToSQLWCHARString at line 73 in file "ODBCStringConverter.cpp"
   73       else if (SIMBA_NTS == in_length)
(dbx) next
t@1 (l@1) stopped in Simba::Support::ODBCStringConverter::ConvertWStringToSQLWCHARString at line 79 in file "ODBCStringConverter.cpp"
   79       simba_int32 bufferBytes = length;
(dbx) next
t@1 (l@1) stopped in Simba::Support::ODBCStringConverter::ConvertWStringToSQLWCHARString at line 80 in file "ODBCStringConverter.cpp"
   80       if (!in_isLengthInBytes)
(dbx) print bufferBytes
bufferBytes = 1744830464
(dbx)

edit 2: Here's how the troublesome library was built (need to rebuild unixODBC, will do that later).

Example command for compiling one of the .cpp files (I removed a bunch of include directories)

/opt/csw/gcc4/bin/g++ -DSIZEOF_LONG_INT=8 -DSQL_WCHART_CONVERT -DHAVE_MEMMOVE -m64 -fPIC -pthread  -Wall -Wno-unknown-pragmas -DSIMBA -D_REENTRANT -DCLUNIX -DNDEBUG -D_POSIX_PTHREAD_SEMANTICS  -O0 -g -D_DEBUG  -c Common/QSTableMetadataFile.cpp -o Common/QSTableMetadataFile_solaris10sparc_gcc4_9_debug64.cpp.o

Command used to link (removed a bunch of .o files)

/opt/csw/gcc4/bin/g++ -DSIMBA -D_REENTRANT -m64 -fPIC -pthread  -Wall -Wno-unknown-pragmas  -lrt   -O0 -g  -shared -L/bamboo/bamboo-agent-home/xml-data/build-dir/ThirdParty/icu/53.1.x/solaris10sparc/gcc4_9/release64/lib -lstdc++ -licudata_sb64 -licui18n_sb64 -licuuc_sb64 -lpthread -lm -lsocket -lnsl -Wl,-M,exports_SunOS.map -Wl,-zallextract,/bamboo/bamboo-agent-home/xml-data/build-dir/SimbaEngine/Maintenance/10.1/Product/Lib/solaris10sparc/gcc4_9/debug64/libSimbaDSI.a,/bamboo/bamboo-agent-home/xml-data/build-dir/SimbaEngine/Maintenance/10.1/Product/Lib/solaris10sparc/gcc4_9/debug64/libSimbaSupport.a,/bamboo/bamboo-agent-home/xml-data/build-dir/SimbaEngine/Maintenance/10.1/Product/Lib/solaris10sparc/gcc4_9/debug64/libAEProcessor.a,/bamboo/bamboo-agent-home/xml-data/build-dir/SimbaEngine/Maintenance/10.1/Product/Lib/solaris10sparc/gcc4_9/debug64/libCore.a,/bamboo/bamboo-agent-home/xml-data/build-dir/SimbaEngine/Maintenance/10.1/Product/Lib/solaris10sparc/gcc4_9/debug64/libDSIExt.a,/bamboo/bamboo-agent-home/xml-data/build-dir/SimbaEngine/Maintenance/10.1/Product/Lib/solaris10sparc/gcc4_9/debug64/libExecutor.a,/bamboo/bamboo-agent-home/xml-data/build-dir/SimbaEngine/Maintenance/10.1/Product/Lib/solaris10sparc/gcc4_9/debug64/libParser.a,/bamboo/bamboo-agent-home/xml-data/build-dir/SimbaEngine/Maintenance/10.1/Product/Lib/solaris10sparc/gcc4_9/debug64/libSimbaODBC.a -Wl,-zweakextract  -o ../Bin/solaris10sparc/gcc4_9/debug64/libQuickstart64.so