Dynamic libraries generated for windows by i686-w64-mingw32-g++ may provide c++ symbols or refer to c++ symbols from other dynamic libraries. When running `i686-w64-mingw32-objdump -x -C gnu-v3` on such a dynamic library does not print out the demangled symbol name. How to reproduce: 1. downloaded appended dll.a 2. run i686-w64-mingw32-objdump -x --demangle=gnu-v3 libgmpxx-4.dll | gawk '$3 ~ /basic_string/ { print $3}' _ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE10_M_disposeEv _ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE10_M_replaceEjjPKcj _ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE9_M_appendEPKcj _ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE9_M_mutateEjjPKcj _Z24__gmp_istream_set_digitsRNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEERSiRcRbi The referenced symbols are valid c++ symbols as shown below: i686-w64-mingw32-objdump -x --demangle=gnu-v3 libgmpxx-4.dll | gawk '$3 ~ /basic_string/ { print $3}' | c++filt std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_dispose() std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_replace(unsigned int, unsigned int, char const*, unsigned int) std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_append(char const*, unsigned int) std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_mutate(unsigned int, unsigned int, char const*, unsigned int) __gmp_istream_set_digits(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&, std::basic_istream<char, std::char_traits<char> >&, char&, bool&, int) It would be nice if objdump could output the symbols demangled if desired.
(In reply to Ralf Habacker from comment #0) > When running `i686-w64-mingw32-objdump -x -C gnu-v3` on such a dynamic > library does not print out the demangled symbol name. Hmm - tricky. The issue is that these symbol names are printed out by an internal function of the BFD library (pe_print_idata to be exact) which does not have access to the do_demangle or the demangle_flags variables which are set in objdump.c... Given that the symbols can be demangled via the command line that you use in the description, it seems to me that fixing the BFD library is not that important. If we did fix the library, the best solution, imho, would be to add a callback function for printing symbol names. Then any bfd function that displays symbols could call it, allowing any user of the bfd library to decide how symbol names are display.
(In reply to Nick Clifton from comment #1) Hi Nick, thanks for investigating. > Given that the symbols can be demangled via the command line that you use > in the description, it seems to me that fixing the BFD library is not that > important. In this case, it would be good if objdump would give a warning that this option is not supported (or abort), as the user might get unexpected results when running e.g. objdump -x -C gnu-v3 xxx.dll | grep <myclass::myfunc> If nothing is output, it is assumed that the named method is not imported or exported. Instead, it is simply not de-mangled.
Hi Ralf, OK, what do you think of the uploaded patch ? If objdump is run with the -p/-x and -C/--demangle options then it will display: objdump: Warning: demangling is not supported for symbol names displayed in private headers In addition it updates the documentation, so that the description of objdump's -C option includes a mention of this limitation. Whilst testing this patch I did find one other problem however. Because some PE symbols have prefixes the demangler can be confused. For example: % x86_64-w64-mingw32-objdump --syms --demangle=gnu-v3 libgmpxx-4.dll | grep _ZN [131](sec 8)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x00000000000003e8 __imp__ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE9_M_appendEPKcy [134](sec 8)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x00000000000003f0 __imp__ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE9_M_mutateEyyPKcy ..etc.. So maybe the warning needs to be extended ? Cheers Nick
Created attachment 14651 [details] Proposed patch