I am dealing with a pesky compilation/linker error involving C++ homebrew compiled for the Game Boy Advance. While my library, libsaturn, is getting compiled fine with the proper C++ symbols, the compiler seems to be discarding the namespace qualifiers given in the header files for the library and just placing in undefined symbols as if they had C linkage. I have inspected the object code files using nm and confirmed that this is the case.
This is the full repository for the program I am trying to build, although I have provided snippets below. Compiling the repository requires a devkitARM installation and Node.js; I have only ensured things work on Linux sadly.
I originally encountered this problem with devkitARM r46, but unfortunately dialing things back to r45 does not alleviate the issue. I have had the code combed over by several peers of mine and they have found nothing out-of-the-ordinary with my config.
This is the code I am dealing with. I’m afraid it isn’t going to be all that useful considering I have very little idea where the source of the issue lies, but regardless…
src/mainloop.cc
bool saturn::mainloop( )
{
return false;
}
include/saturn/mainloop.hh
namespace saturn
{
bool mainloop( );
}
test/src/main.cc
int main( )
{
while(!saturn::mainloop( ))
{
// Do something here
}
return 0;
}
alex#henen-nesw saturn $ arm-none-eabi-nm -pC /tmp/saturn-buildtool/code/test+src+main.cc.o
00000000 T main
U init
U halt
U mainloop
alex#henen-nesw saturn $ arm-none-eabi-nm -pC libsaturn.a
src+bios.cc.o:
00000000 T bios::halt()
U _sat__bios_halt
00000014 T bios::softReset()
U _sat__bios_soft_reset
00000028 T bios::waitInterrupt(unsigned long, unsigned long)
U _sat__bios_intr_wait
0000004c T bios::waitVblank()
U _sat__bios_vblank_intr_wait
src+bootsector.s.o:
00000000 T __start
000000c0 T _sat__rom_start
000000ec T _sat__irq_handler
U main
src+error.cc.o:
00000000 r kDispcntBgMode0
00000002 r kDispcntBgMode1
00000004 r kDispcntBgMode2
00000006 r kDispcntBgMode3
00000008 r kDispcntBgMode4
0000000a r kDispcntBgMode5
0000000c r kDispcntCgbMode
0000000e r kDispcntFrameSel
00000010 r kDispcntHblankIntv
00000012 r kDispcntObjVramDim
00000014 r kDispcntForceBlank
00000016 r kDispcntShowBg0
00000018 r kDispcntShowBg1
0000001a r kDispcntShowBg2
0000001c r kDispcntShowBg3
0000001e r kDispcntShowObj
00000020 r kDispcntShowWin0
00000022 r kDispcntShowWin1
00000024 r kDispcntShowObjWin
00000028 r ioDispcnt
0000002c r ioGreenswap
00000030 r kDispstatVblank
00000032 r kDispstatHblank
00000034 r kDispstatVcounter
00000036 r kDispstatVblankIrq
00000038 r kDispstatHblankIrq
0000003a r kDispstatVcounterIrq
0000003c r ioDispstat
00000040 r ioVcount
00000044 r kBgcntMosaic
00000046 r kBgcntPalMode4
00000048 r kBgcntPalMode8
0000004a r kBgcntOverflow
0000004c r ioBg0cnt
00000050 r ioBg1cnt
00000054 r ioBg2cnt
00000058 r ioBg3cnt
0000005c r ioBg0hofs
00000060 r ioBg0vofs
00000064 r ioBg1hofs
00000068 r ioBg1vofs
0000006c r ioBg2hofs
00000070 r ioBg2vofs
00000074 r ioBg3hofs
00000078 r ioBg3vofs
0000007c r ioBg2pa
00000080 r ioBg2pb
00000084 r ioBg2pc
00000088 r ioBg2pd
0000008c r ioBg2xL
00000090 r ioBg2xH
00000094 r ioBg2yL
00000098 r ioBg2yH
0000009c r ioBg3pa
000000a0 r ioBg3pb
000000a4 r ioBg3pc
000000a8 r ioBg3pd
000000ac r ioBg3xL
000000b0 r ioBg3xH
000000b4 r ioBg3yL
000000b8 r ioBg3yH
000000bc r ioWin0H
000000c0 r ioWin1H
000000c4 r ioWin0V
000000c8 r ioWin1V
000000cc r ioWinIn
000000d0 r ioWinOut
000000d4 r ioMosaic
000000d8 r ioBldcnt
000000dc r ioBldalpha
000000e0 r ioBldy
000000e4 r segBios
000000e8 r segEwram
000000ec r segIwram
000000f0 r segIo
000000f4 r segPal
00000000 b segPalBg
000000f8 r segPalObj
000000fc r segVram
00000004 b segVramBg
00000100 r segVramObj
00000104 r segOam
00000108 r segRom
0000010c r segSram
00000110 r ioDma0sad
00000114 r ioDma0dad
00000118 r ioDma0cntL
0000011c r ioDma0cntH
00000120 r ioDma1sad
00000124 r ioDma1dad
00000128 r ioDma1cntL
0000012c r ioDma1cntH
00000130 r ioDma2sad
00000134 r ioDma2dad
00000138 r ioDma2cntL
0000013c r ioDma2cntH
00000140 r ioDma3sad
00000144 r ioDma3dad
00000148 r ioDma3cntL
0000014c r ioDma3cntH
000000a0 t __static_initialization_and_destruction_0(int, int)
000000e4 t _GLOBAL__sub_I_error.cc
00000000 T saturn::error(saturn::Error)
src+init.cc.o:
00000000 T saturn::init()
U saturn::error(saturn::Error)
src+lowbios.s.o:
00000000 T _sat__bios_soft_reset
00000004 T _sat__bios_register_ram_reset
00000008 T _sat__bios_halt
0000000c T _sat__bios_stop
00000010 T _sat__bios_intr_wait
00000014 T _sat__bios_vblank_intr_wait
00000018 T _sat__bios_div
0000001c T _sat__bios_div_arm
00000020 T _sat__bios_sqrt
00000024 T _sat__bios_arc_tan
00000028 T _sat__bios_arc_tan2
0000002c T _sat__bios_cpu_set
00000030 T _sat__bios_cpu_fast_set
00000034 T _sat__bios_bg_affine_set
00000038 T _sat__bios_obj_affine_set
0000003c T _sat__bios_bit_unpack
00000040 T _sat__bios_lzss_decomp_wram
00000044 T _sat__bios_lzss_decomp_vram
00000048 T _sat__bios_huff_decomp
0000004c T _sat__bios_rl_decomp_wram
00000050 T _sat__bios_rl_decomp_vram
00000054 T _sat__bios_diff_8bit_unfilter_wram
00000058 T _sat__bios_diff_8bit_unfilter_vram
0000005c T _sat__bios_diff_16bit_unfilter
00000060 T _sat__bios_sound_bias
00000064 T _sat__bios_midi_key_to_freq
00000068 T _sat__bios_multi_boot
src+mainloop.cc.o:
00000000 T saturn::mainloop()
src+math.cc.o:
00000000 T saturn::divide(long, long)
U _sat__bios_div
00000030 T saturn::sqroot(unsigned long)
U _sat__bios_sqrt
00000050 T saturn::modulus(long, long)
src+memory.cc.o:
Thanks!
Here's a simplified build script that links the test program correctly: https://gist.github.com/nnevatie/9fe11e3933ed3f51e5344639c6881bd5
Related
I know there is already a lot of topics about this subject, however I didn't find in any of them the explanation to how it is possible to have one definition of an inline function per translation unit. I know that inline functions have external linkage, so when I call one inline function in different translation units they all reference the same function. I also know that in Linux the compiler registers inline function with the "W" symbol, so it is registered as a weak symbol (thanks to it the first definition encountered by the compiler of the inline function is the one considered). However whenever I use nm on the object files created by g++ in Windows there is no weak symbol attached to the function signature. How can the linker know which definition to consider and not to accuse of multiple definitions? (I don't show the linker's work but I tested it).
Here is some example code:
// main1.cpp
#include "main.hpp"
/* inline accepts one definition in each TU's */
inline void Test::hello_world()
{
std::cout << "Hello world" << std::endl;
}
/*void Test::hello_world()
{
std::cout << "Hello world" << std::endl;
}*/
extern void return_hello_world();
int main()
{
Test t;
t.hello_world();
return_hello_world();
return 0;
}
// main2.cpp
#include "main.hpp"
/* inline accepts one definition in each TU's */
inline void Test::hello_world()
{
std::cout << "Hello world" << std::endl;
}
/* void Test::hello_world()
{
std::cout << "Hello world" << std::endl;
} */
void return_hello_world()
{
Test t;
t.hello_world();
}
// main.hpp
#ifndef TEST
#define TEST
#include <iostream>
class Test
{
public:
void hello_world();
};
#endif
The results I receive are:
Windows:
Experimentation4> g++ -g -O0 -c main1.cpp main2.cpp
Experimentation4> nm main1.o
0000000000000000 b .bss
0000000000000000 d .ctors
0000000000000000 d .data
0000000000000000 N .debug_abbrev
0000000000000000 N .debug_aranges
0000000000000000 N .debug_frame
0000000000000000 N .debug_info
0000000000000000 N .debug_line
0000000000000000 N .debug_ranges
0000000000000000 N .debug_str
0000000000000000 p .pdata
0000000000000000 p .pdata$_ZN4Test11hello_worldEv
0000000000000000 r .rdata
0000000000000000 r .rdata$.refptr._ZSt4cout
0000000000000000 r .rdata$.refptr._ZSt4endlIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_
0000000000000000 r .rdata$zzz
0000000000000000 R .refptr._ZSt4cout
0000000000000000 R .refptr._ZSt4endlIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_
0000000000000000 t .text
0000000000000000 t .text$_ZN4Test11hello_worldEv
0000000000000000 r .xdata
0000000000000000 r .xdata$_ZN4Test11hello_worldEv
U __main
0000000000000029 t __tcf_0
0000000000000080 t _GLOBAL__sub_I_main
U _Z18return_hello_worldv
0000000000000044 t _Z41__static_initialization_and_destruction_0ii
0000000000000000 T _ZN4Test11hello_worldEv
U _ZNSolsEPFRSoS_E
U _ZNSt8ios_base4InitC1Ev
U _ZNSt8ios_base4InitD1Ev
U _ZSt4cout
U _ZSt4endlIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_
0000000000000000 r _ZStL19piecewise_construct
0000000000000000 b _ZStL8__ioinit
U _ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc
U atexit
0000000000000000 T main
Linux:
Experimentation2$ g++ -O0 -g -c main1.cpp main2.cpp
Experimentation2$ nm main1.o
U __cxa_atexit
U __dso_handle
0000000000000081 t _GLOBAL__sub_I_main
0000000000000000 T main
U __stack_chk_fail
U _Z18return_hello_worldv
0000000000000043 t _Z41__static_initialization_and_destruction_0ii
0000000000000000 W _ZN4Test11hello_worldEv
U _ZNSolsEPFRSoS_E
U _ZNSt8ios_base4InitC1Ev
U _ZNSt8ios_base4InitD1Ev
U _ZSt4cout
U _ZSt4endlIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_
0000000000000000 b _ZStL8__ioinit
U _ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc
Building an application linked with the default vcpkg build of boost on macos 10.14.1 yields the following errors:
Undefined symbols for architecture x86_64:
"boost::system::detail::system_category_instance", referenced from:
boost::system::system_category() in main.cxx.o
boost::asio::io_context::run() in main.cxx.o
boost::asio::detail::socket_ops::close(int, unsigned char&, bool, boost::system::error_code&) in main.cxx.o
boost::asio::detail::socket_holder::~socket_holder() in main.cxx.o
boost::asio::detail::reactive_socket_service_base::destroy(boost::asio::detail::reactive_socket_service_base::base_implementation_type&) in main.cxx.o
_main in main.cxx.o
boost::asio::ip::basic_resolver_iterator<boost::asio::ip::tcp> boost::asio::connect<boost::asio::ip::tcp, boost::asio::ip::basic_resolver_iterator<boost::asio::ip::tcp> >(boost::asio::basic_socket<boost::asio::ip::tcp>&, boost::asio::ip::basic_resolver_iterator<boost::asio::ip::tcp>, boost::asio::ip::basic_resolver_iterator<boost::asio::ip::tcp>) in main.cxx.o
...
"boost::system::detail::generic_category_instance", referenced from:
boost::system::generic_category() in main.cxx.o
ld: symbol(s) not found for architecture x86_64
collect2: error: ld returned 1 exit status
make[2]: *** [cleverly] Error 1
make[1]: *** [CMakeFiles/cleverly.dir/all] Error 2
make: *** [all] Error 2
If I'm reading the following correctly:
https://github.com/Microsoft/vcpkg/issues/4437
https://github.com/boostorg/system/issues/26
I assume boost must be recompiled with the same version of c++ as the application.
With vcpkg, how might one change the c++ standard used to compile the boost libraries?
Updates
libboost_system.a is indeed 64 bit.
lipo -info libboost_system.a
Non-fat file: libboost_system.a is architecture: x86_64
Linking commands when make is run with VERBOSE=1:
/usr/local/Cellar/cmake/3.12.4/bin/cmake -E cmake_link_script CMakeFiles/cleverly.dir/link.txt --verbose=1
/usr/local/bin/g++-HEAD -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk -Wl,-search_paths_first -Wl,-headerpad_max_install_names CMakeFiles/cleverly.dir/Users/sheel/Projects/sheeldme/cleverly-misogamist/source/main.cxx.o -o cleverly /opt/vcpkg/installed/x64-osx/debug/lib/libboost_system.a /opt/vcpkg/installed/x64-osx/debug/lib/libboost_filesystem.a /opt/vcpkg/installed/x64-osx/debug/lib/libboost_date_time.a /opt/vcpkg/installed/x64-osx/debug/lib/libboost_thread.a /opt/vcpkg/installed/x64-osx/debug/lib/libboost_regex.a /opt/vcpkg/installed/x64-osx/debug/lib/libboost_serialization.a /opt/vcpkg/installed/x64-osx/debug/lib/libboost_chrono.a /opt/vcpkg/installed/x64-osx/debug/lib/libboost_atomic.a
Symbol table through: objdump -t libboost_system.a
libboost_system.a(error_code.o): file format Mach-O 64-bit x86-64
SYMBOL TABLE:
0000000000016138 l __DATA,__bss __ZGVZNK5boost6system6detail22generic_error_category7messageEiE11unknown_err
0000000000016120 l __DATA,__bss __ZZNK5boost6system6detail22generic_error_category7messageEiE11unknown_err
0000000000001080 l __TEXT,__gcc_except_tab GCC_except_table0
0000000000016178 l __DATA,__bss __ZGVZN5boost6system6detail20generic_category_ncxEvE25generic_category_instance
0000000000016160 l __DATA,__bss __ZZN5boost6system6detail20generic_category_ncxEvE25generic_category_instance
0000000000016158 l __DATA,__bss __ZGVZN5boost6system6detail19system_category_ncxEvE24system_category_instance
0000000000016140 l __DATA,__bss __ZZN5boost6system6detail19system_category_ncxEvE24system_category_instance
0000000000001060 gw F __TEXT,__text __ZN5boost6system14error_category12std_categoryD0Ev
0000000000001050 gw F __TEXT,__text __ZN5boost6system14error_category12std_categoryD1Ev
0000000000000e90 g F __TEXT,__text __ZN5boost6system6detail19system_category_ncxEv
0000000000000f20 g F __TEXT,__text __ZN5boost6system6detail20generic_category_ncxEv
0000000000001030 gw F __TEXT,__text __ZN5boost6system6detail21system_error_categoryD0Ev
0000000000000f10 gw F __TEXT,__text __ZN5boost6system6detail21system_error_categoryD1Ev
0000000000000fb0 gw F __TEXT,__text __ZN5boost6system6detail22generic_error_categoryD0Ev
0000000000000fa0 gw F __TEXT,__text __ZN5boost6system6detail22generic_error_categoryD1Ev
0000000000001010 gw F __TEXT,__text __ZNK5boost6system14error_category10equivalentERKNS0_10error_codeEi
0000000000000fe0 gw F __TEXT,__text __ZNK5boost6system14error_category10equivalentEiRKNS0_15error_conditionE
0000000000001070 gw F __TEXT,__text __ZNK5boost6system14error_category12std_category4nameEv
0000000000000fd0 gw F __TEXT,__text __ZNK5boost6system14error_category23default_error_conditionEi
0000000000000220 g F __TEXT,__text __ZNK5boost6system6detail21system_error_category23default_error_conditionEi
0000000000001040 gw F __TEXT,__text __ZNK5boost6system6detail21system_error_category4nameEv
0000000000000e00 g F __TEXT,__text __ZNK5boost6system6detail21system_error_category7messageEi
0000000000000fc0 gw F __TEXT,__text __ZNK5boost6system6detail22generic_error_category4nameEv
0000000000000000 g F __TEXT,__text __ZNK5boost6system6detail22generic_error_category7messageEi
0000000000001148 gw __DATA,__const __ZTIN5boost12noncopyable_11noncopyableE
0000000000001220 gw __DATA,__const __ZTIN5boost6system14error_category12std_categoryE
0000000000001160 gw __DATA,__const __ZTIN5boost6system14error_categoryE
00000000000011e0 g __DATA,__const __ZTIN5boost6system6detail21system_error_categoryE
0000000000001180 g __DATA,__const __ZTIN5boost6system6detail22generic_error_categoryE
0000000000001280 gw __TEXT,__const __ZTSN5boost12noncopyable_11noncopyableE
00000000000012e0 gw __TEXT,__const __ZTSN5boost6system14error_category12std_categoryE
0000000000001260 gw __TEXT,__const __ZTSN5boost6system14error_categoryE
00000000000012b0 g __TEXT,__const __ZTSN5boost6system6detail21system_error_categoryE
0000000000001230 g __TEXT,__const __ZTSN5boost6system6detail22generic_error_categoryE
00000000000011f8 gw __DATA,__const __ZTVN5boost6system14error_category12std_categoryE
0000000000001198 g __DATA,__const __ZTVN5boost6system6detail21system_error_categoryE
0000000000001100 g __DATA,__const __ZTVN5boost6system6detail22generic_error_categoryE
0000000000000000 *UND* __Unwind_Resume
0000000000000000 *UND* __ZNSt3__112basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEE6assignEPKc
0000000000000000 *UND* __ZNSt3__112basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEEC1ERKS5_
0000000000000000 *UND* __ZNSt3__112basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEED1Ev
0000000000000000 *UND* __ZTVN10__cxxabiv117__class_type_infoE
0000000000000000 *UND* __ZTVN10__cxxabiv120__si_class_type_infoE
0000000000000000 *UND* __ZdlPv
0000000000000000 *UND* ___cxa_atexit
0000000000000000 *UND* ___cxa_begin_catch
0000000000000000 *UND* ___cxa_end_catch
0000000000000000 *UND* ___cxa_guard_acquire
0000000000000000 *UND* ___cxa_guard_release
0000000000000000 *UND* ___dso_handle
0000000000000000 *UND* ___gxx_personality_v0
0000000000000000 *UND* ___stack_chk_fail
0000000000000000 *UND* ___stack_chk_guard
0000000000000000 *UND* _free
0000000000000000 *UND* _malloc
0000000000000000 *UND* _strerror_r
Patch the file at vcpkg/ports/boost-modular-build-helper/CMakeLists.txt.
Patch the custom boost target with cxxstd= followed by the standard you wish to compile with.
Reference: https://github.com/Microsoft/vcpkg/issues/4476
Below is an excerpt of the hex dump of an unformatted Fortran file (generated by AERMOD compiled with gfortran):
00f3ee50: 0000da50 00b746d7 00000001 204c4c41 20202020 462df2dd 403f41fa c5f77f92...
00f4c886: 6a031d65 f2923f8c 658037cc 01813f8b 740e846e d7f83f8a 93a93e15 da503f89
00f4c8a8: 0000da50 00b746d8 00000001 204c4c41 20202020 1bce0f33 4040cf25 059a6d45...
00f5a2de: 04de57c7 6f803fa0 cc5e786d c1983f9e a6fd14ae 05803f9d 970266e8 da503f9c
00f5a300: 0000da50 00b74725 00000001 204c4c41 20202020 9e95fa2a 4087b60e ef189339...
00f67d36: 7d9a5b20 bbe53fd8 467cf2bf be063fd7 292414d4 0c943fd6 22a6cc90 da503fd5
00f67d58: 0000da50 00b74726 00000001 204c4c41 20202020 92ee2eb6 40868bcc 991a0bf2...
00f7578e: 128e3196 a8063fe2 2418d1d5 185e3fe1 49a7e799 009a3fe0 01ea4bf1 da503fdf
00f757b0: 0000da50 00b74727 00000001 204c4c41 20202020 00000000 00000000 00000000...
00f831e6: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 da500000
Each record starts with 0x0000da50, and ends with 0xda503f## (or 0xda500000 when it's a record full of zeroes). I understand that the compiler inserts four bytes at the beginning and end of each record to indicate its length.
I know from the documentation that all of the records have a constant length, and that the first 16 bytes of each record contain routine info such as counters and labels, but not any calculated data.
Now if you take the difference between the positions for two consecutive "start of record lines," you get 55896 (e.g., 0xf4c8a8 - 0xf3ee50 = 55896), and subtracting out the 8 bytes that the compiler added, you get 55888, or 0xda50. So there are only two bytes that are giving the actual record length.
What are the last four bytes of each record doing?
Update
I've found that the stray bytes only appear when certain column sizes are specified in xxd. Here are full hex dumps for a smaller file (generated using the same Fortran program), with two different column specifications (first with 16 octets, then with 25). Maybe it's an issue with xxd?
$ xxd -e -c16 test.pst
00000000: 00000250 00b74275 00000001 204c4c41 P...uB......ALL
00000010: 20202020 1273c268 4042050f 6ec665a7 h.s...B#.e.n
00000020: 404c165c 2e64c72d 40469557 87eefed5 \.L#-.d.W.F#....
00000030: 404d86c1 349e2405 40502c03 435bacfe ..M#.$.4.,P#..[C
00000040: 40501966 fe8ace3c 404e4ef7 7382fb52 f.P#<....NN#R..s
00000050: 404b73f0 01369ac9 4048029b 19a95098 .sK#..6...H#.P..
00000060: 40442608 39972ac4 403ff81f 87f5457a .&D#.*.9..?#zE..
00000070: 403760aa 0933541e 402e31cf 96229471 .`7#.T3..1.#q.".
00000080: 40201210 31afaa2e 400ab597 06b2618a .. #...1...#.a..
00000090: 3ff934b7 a5814a70 3ff6c2cf 13454924 .4.?pJ.....?$IE.
000000a0: 3ff6d543 9389bf37 3ff6db74 3630fe04 C..?7...t..?..06
000000b0: 3ff6d48e 0f5e2bc8 3ff6c0b8 fdbc2622 ...?.+^....?"&..
000000c0: 3ff6a063 a26cd9d4 3ff67447 150d1668 c..?..l.Gt.?h...
000000d0: 3ff63d53 37d9abef 3ff5fca5 b6c1bba5 S=.?...7...?....
000000e0: 3ff5b37e be32f197 3ff56334 586c0c65 ~..?..2.4c.?e.lX
000000f0: 3ff50d24 2bcc15c8 3ff4b2a7 15798027 $..?...+...?'.y.
00000100: 3ff4550a dca18880 3ff3f585 039bd6d6 .U.?.......?....
00000110: 3ff3953a 9221d30d 3ff33529 97fa7215 :..?..!.)5.?.r..
00000120: 3ff2d639 1909878a 3ff27931 4e95ad98 9..?....1y.?...N
00000130: 400b42d6 4641e3b8 400a4f52 c5ddb926 .B.#..AFRO.#&...
00000140: 40096e88 aa92c3ba 40089fd0 93f8d3c8 .n.#.......#....
00000150: 4007e269 749bbc48 40073588 afbbc2f8 i..#H..t.5.#....
00000160: 40069860 9005d1f8 40060a2a bde7eb31 `..#....*..#1...
00000170: 40058a27 3a0dc41a 400517a6 434deebc '..#...:...#..MC
00000180: 4004b202 77353ddd 400458a7 6920fdd8 ...#.=5w.X.#.. i
00000190: 40040b11 dccebcd6 4003c8cb c5b1ee47 ...#.......#G...
000001a0: 40039172 2388cc5f 400364b2 ce0c693f r..#_..#.d.#?i..
000001b0: 40034245 3c8b166d 400329f9 52837682 EB.#m..<.).#.v.R
000001c0: 40031ba7 377415b1 4003173a 3de1aa1e ...#..t7:..#...=
000001d0: 40031cab dbcb3888 40032c02 b5346967 ...#.8...,.#gi4.
000001e0: 40034558 b7f5a14d 400368d3 466d447d XE.#M....h.#}DmF
000001f0: 400396aa 6cd87c23 4003cf22 1ad6f796 ...##|.l"..#....
00000200: 40041292 57a28483 4004615f 63a836e2 ...#...W_a.#.6.c
00000210: 4004bc00 b4f68bf3 400522fb b5195f5e ...#.....".#^_..
00000220: 400596e7 1dd722b0 4006186a 5bf7aba7 ...#."..j..#...[
00000230: 4026b8df b0158858 402bd56c f3245c1f ..&#X...l.+#.\$.
00000240: 40310f07 e8781d38 4034d28c 97d0997b ..1#8.x...4#{...
00000250: 403a0634 00000250 4.:#P...
second:
$ xxd -e -c25 test.pst
00000000: 00000250 00b74275 00000001 204c4c41 20202020 1273c268 P.0fuB......ALL h.s..
00000019: a7404205 5c6ec665 2d404c16 572e64c7 d5404695 c187eefe .B86e.n\.L#-.d.W.F#......
00000032: 2405404d 2c03349e acfe4050 1966435b ce3c4050 4ef7fe8a M#4e.4.,P#..[Cf.P#<....NN
0000004b: 82fb5240 4b73f073 369ac940 48029b01 a9509840 44260819 #R40s.sK#..6...H#.P...&D#
00000064: 39972ac4 403ff81f 87f5457a 403760aa 0933541e 402e31cf .*71..?#zE...`7#.T3..1.#q
0000007d: 10962294 2e402012 9731afaa 8a400ab5 b706b261 703ff934 ."4a. #...1...#.a...4.?pJ
00000096: c2cfa581 49243ff6 d5431345 bf373ff6 db749389 fe043ff6 ..30.?$IE.C..?7...t..?..0
000000af: f6d48e36 5e2bc83f f6c0b80f bc26223f f6a063fd 6cd9d43f 6.a2?.+^....?"&..c..?..l.
000000c8: 3ff67447 150d1668 3ff63d53 37d9abef 3ff5fca5 b6c1bba5 Gt7eh...S=.?...7...?....~
000000e1: 973ff5b3 34be32f1 653ff563 24586c0c c83ff50d a72bcc15 ..b2.2.4c.?e.lX$..?...+..
000000fa: 80273ff4 550a1579 88803ff4 f585dca1 d6d63ff3 953a039b .?f3y..U.?.......?....:..
00000113: 21d30d3f f3352992 fa72153f f2d63997 09878a3f f2793119 ?.3f.)5.?.r..9..?....1y.?
0000012c: 4e95ad98 400b42d6 4641e3b8 400a4f52 c5ddb926 40096e88 ..ba.B.#..AFRO.#&....n.#.
00000145: d0aa92c3 c840089f 6993f8d3 484007e2 88749bbc f8400735 ..c2..#....i..#H..t.5.#..
0000015e: 9860afbb d1f84006 0a2a9005 eb314006 8a27bde7 c41a4005 ..0d.#....*..#1...'..#...
00000177: 0517a63a 4deebc40 04b20243 353ddd40 0458a777 20fdd840 :.69#..MC...#.=5w.X.#.. i
00000190: 40040b11 dccebcd6 4003c8cb c5b1ee47 40039172 2388cc5f ..b2.......#G...r..#_..#.
000001a9: 3f400364 45ce0c69 6d400342 f93c8b16 82400329 a7528376 d.1bi..EB.#m..<.).#.v.R..
000001c2: 15b14003 173a3774 aa1e4003 1cab3de1 38884003 2c02dbcb .#03t7:..#...=...#.8...,.
000001db: 34696740 034558b5 f5a14d40 0368d3b7 6d447d40 0396aa46 #g40.XE.#M....h.#}DmF...#
000001f4: 6cd87c23 4003cf22 1ad6f796 40041292 57a28483 4004615f #|e2"..#.......#...W_a.#.
0000020d: 0063a836 f34004bc fbb4f68b 5e400522 e7b5195f b0400596 6.22..#.....".#^_.....#."
00000226: 186a1dd7 aba74006 b8df5bf7 88584026 d56cb015 5c1f402b ..24.#...[..&#X...l.+#.\$
0000023f: 310f07f3 781d3840 34d28ce8 d0997b40 3a063497 00025040 ..00#8.x...4#{...4.:#P...
After a 16-byte preamble (ending with 202020), the output is supposed to be a sequence of 72 numbers. Since they take up 576 bytes, I'm guessing that they are double precision reals in Fortran:
36.03952 56.17470 45.16672 59.05278 64.68770 64.39687 60.61694 54.90578 48.02036 40.29712 31.96923 23.37760 15.09728 8.03528 3.33867 1.57537 1.42256 1.42707 1.42858 1.42689 1.42205 1.41416 1.40339 1.38997 1.37418 1.35632 1.33672 1.31571 1.29362 1.27076 1.24744 1.22393 1.20048 1.17730 1.15459 3.40764 3.28873 3.17897 3.07803 2.98555 2.90114 2.82440 2.75496 2.69246 2.63655 2.58692 2.54329 2.50540 2.47305 2.44602 2.42417 2.40736 2.39549 2.38850 2.38634 2.38900 2.39649 2.40886 2.42619 2.44857 2.47614 2.50907 2.54755 2.59180 2.64208 2.69868 2.76192 11.36108 13.91684 17.05872 20.82246 26.02424
Parsing the file with the perl unpack function I'm able to account for all of the bytes properly. It seems to just be a small glitch with xxd, when certain column sizes are used.
I have a massive C/C++ library that I'm trying to use through JNI for an Android project. It's comprised of several classes that were originally written for MFC and we've ported them over for execution on the Android environment.
The library builds fine (at least according to ndk-build). The size of the library is 56 MB in size.
When I call System.loadLibrary, the application terminates with the following being logged:
Fatal Signal 11 (SIGSEGV) at 0x00000004 (Code = 1), thread 16123
I performed an objdump on my library and there is nothing at 0004. Here's the first few lines of the dump :
DYNAMIC SYMBOL TABLE:
00000000 DF *UND* 00000000 __cxa_finalize
002fe600 g D .bss 00000000 __dso_handle
002f1e9c g D .init_array 00000000 __INIT_ARRAY__
002f20a4 g D .fini_array 00000000 __FINI_ARRAY__
0011dc58 g DF .text 000000ec WideToJava
00000000 DF *UND* 00000000 __android_log_print
0021f460 g DF .text 00000030 wcslen
00000000 DF *UND* 00000000 malloc
00000000 DF *UND* 00000000 free
0011dd44 g DF .text 000000e4 WideToJava2
0011de28 g DF .text 0000004e JavaToWSZ
0027443c g DF .text 0000001c _Znaj
0011dec4 w DF .text 00000018
I then performed a readelf to see if there is another library that needs to be loaded, listed here :
Dynamic section at offset 0x2d99e0 contains 28 entries:
Tag Type Name/Value
0x00000003 (PLTGOT) 0x2fe464
0x00000002 (PLTRELSZ) 776 (bytes)
0x00000017 (JMPREL) 0x11d4a0
0x00000014 (PLTREL) REL
0x00000011 (REL) 0x107770
0x00000012 (RELSZ) 89392 (bytes)
0x00000013 (RELENT) 8 (bytes)
0x6ffffffa (RELCOUNT) 11169
0x00000006 (SYMTAB) 0x128
0x0000000b (SYMENT) 16 (bytes)
0x00000005 (STRTAB) 0x31cd8
0x0000000a (STRSZ) 791389 (bytes)
0x00000004 (HASH) 0xf3038
0x00000001 (NEEDED) Shared library: [liblog.so]
0x00000001 (NEEDED) Shared library: [libandroid.so]
0x00000001 (NEEDED) Shared library: [libstdc++.so]
0x00000001 (NEEDED) Shared library: [libm.so]
0x00000001 (NEEDED) Shared library: [libc.so]
0x00000001 (NEEDED) Shared library: [libdl.so]
0x0000000e (SONAME) Library soname: [libCSEntry.so]
0x00000019 (INIT_ARRAY) 0x2f1e9c
0x0000001b (INIT_ARRAYSZ) 520 (bytes)
0x0000001a (FINI_ARRAY) 0x2f20a4
0x0000001c (FINI_ARRAYSZ) 12 (bytes)
0x00000016 (TEXTREL) 0x0
0x00000010 (SYMBOLIC) 0x0
0x0000001e (FLAGS) SYMBOLIC TEXTREL
0x00000000 (NULL) 0x0
Then I added those libraries before my call to loadLibrary :
public class ApplicationInterface
{
static
{
System.loadLibrary("log");
System.loadLibrary("android");
System.loadLibrary("stdc++");
System.loadLibrary("m");
System.loadLibrary("c");
System.loadLibrary("dl");
// when i call load library it blows up
System.loadLibrary("CSEntry");
}
// code
}
What's stranger is that there is a specific class that blows up this code. When I commented out the constructor to this class the library loads fine. I've verified that the constructor exists in the resulting library using objdump. I then proceeded to comment out the code in the constructor and it fails as well. Here's the offending code in the C++:
// Code
m_pPifFile = new CNPifFile(sPifFilePath);
m_pPifFile->SetAppType(ENTRY_TYPE);
m_pPifFile->SetAppFName(sApplicationFilename);
m_pPifFile->SetBinaryLoad(true);
// load the PIF file
if(m_pPifFile->LoadPifFile())
{
// PIF file loaded create a new Run App
// the offending line
m_pRunAplEntry = new CRunAplEntry(m_pPifFile);
// Code
RunAplEntry.h
class AFX_EXT_CLASS CRunAplEntry : public CRunApl
{
public:
CRunAplEntry(CNPifFile* pPifFile);
~CRunAplEntry();
// code
};
RunApl.h
class CLASS_DECL_ZBRIDGEO CRunApl : public CObject
{
public:
CRunApl();
virtual ~CRunApl();
// code
};
AFX_EXT_CLASS and CLASS_DECL_ZBRIDGEO are #defined to empty space.
We wrote a CObject equivalient for the Android NDK.
Here are the makefiles :
Application.mk
# set the platform to the latest processor type
APP_ABI := armeabi-v7a
# build for GNU STL
APP_STL := gnustl_static
# turn on exceptions and runtime type info
APP_CPPFLAGS += -fexceptions -frtti
Android.mk
LOCAL_LDLIBS := -llog -landroid $(BOOST_LIBS) -lgnustl_static
LOCAL_LDFLAGS := -L$(BOOST_PATH)/lib/arm
LOCAL_CFLAGS := -D__GLIBC__=1
LOCAL_CFLAGS += -D_GLIBCXX_USE_C99_MATH=1
LOCAL_CFLAGS += -DUNICODE=1
LOCAL_CFLAGS += -D_UNICODE=1
LOCAL_CFLAGS += -DGENERATE_BINARY=1
LOCAL_CFLAGS += -DUSE_BINARY=1
LOCAL_CFLAGS += -DPORTABLE=1
LOCAL_CFLAGS += -fpermissive
LOCAL_CFLAGS += $(CSPROMOBILE_INCLUDE)
LOCAL_STATIC_LIBRARIES := Engine zTbdO zFormO zDictO zToolsO zUtilO zCommonO
I've noticed that the GCC compiler doesn't handle virtual functions very well and I suspect this could be the problem, but I'm not sure. Here are the details for my environment.
NDK: Crystax r75
ABI Target: 4.6.3
ADT: v21.0.1-543035
Debug Device: Nexus 7
Any help will be greatly appreciated.
If you have any additional info please don't hesitate to ask.
Thanks,
Will
After we have changed kernel driver code from C to C++ IoVolumeDeviceToDosName function's call produces BSOD on Windows 7 but this code
still works fine on Windows XP.
Can anyone give me a hint how to resolve this problem?
Yes driver complied for Windows 7.
I not using static code analyzer
BUGCHECK_STR: 0x7f_8
TSS: 00000028 -- (.tss 0x28)
eax=908b92ec ebx=00000000 ecx=908b9360 edx=00000000 esi=908b9374 edi=908b9374
eip=826c5035 esp=908b8e74 ebp=908b92c8 iopl=0 nv up ei ng nz na po nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010282
nt!_woutput_l+0x1b:
826c5035 57 push edi
Resetting default scope
DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT
PROCESS_NAME: svchost.exe
CURRENT_IRQL: 1f
LAST_CONTROL_TRANSFER: from 826bedad to 826c5035
STACK_TEXT:
908b92c8 826bedad 908b92ec 86d70560 00000000 nt!_woutput_l+0x1b
908b930c 826c7667 908b9374 00000063 86d70560 nt!_vsnwprintf_l+0x7b
908b9328 86d66160 908b9374 00000063 86d70560 nt!_vsnwprintf+0x18
908b934c 86d6cf44 908b9374 000000c8 86d70560 volmgr!RtlStringCbPrintfW+0x3a
908b9440 86d668ab 851080e8 843b0248 00004000 volmgr!VmpQueryDeviceName+0x46
908b9464 826434bc 85108030 843b03b4 85104be8 volmgr!VmDeviceControl+0x2f1
908b947c 87001854 908b94c4 8700274d 85104b30 nt!IofCallDriver+0x63
908b9484 8700274d 85104b30 843b0248 85103990 fvevol!FveFilterSkip+0x1e
908b94c4 826434bc 85104b30 843b0248 85103978 fvevol!FveFilterDeviceControl+0x16f
908b94dc 873d1083 908b957c 843b0248 908b9534 nt!IofCallDriver+0x63
908b94ec 873d96ea 851038c0 843b0248 17b5c100 rdyboost!SmdDispatchPassthrough+0x6d
908b9534 826434bc 851038c0 843b0248 843b0248 rdyboost!SmdDispatchDeviceControl+0x68
908b954c 873b2fcc 00000000 85108660 85108660 nt!IofCallDriver+0x63
908b9580 826434bc 00000000 843b0248 00000200 volsnap!VolSnapDeviceControl+0x50
908b9598 827f549f 85f09030 93acd748 843dd030 nt!IofCallDriver+0x63
908b9dfc 90cef31f 85108660 908b9e14 0030002e nt!IoVolumeDeviceToDosName+0x7e
908ba668 90cef541 00000d78 85108030 908bb538 ProcObsrv!GetProcessImageName+0x21f [d:\oc\sources\drivers2005\ocdrivers\procobsrv\procobsrv.c # 381]
908bb53c 8285e238 843dd030 00000d78 908bb560 ProcObsrv!OnCreateProcessEx+0x91 [d:\oc\sources\drivers2005\ocdrivers\procobsrv\procobsrv.c # 469]
908bb5f4 8285d523 85f09030 013dd030 908bb650 nt!PspInsertThread+0x5be
908bbd00 8264a42a 00b0eacc 00b0eaa8 02000000 nt!NtCreateUserProcess+0x742
908bbd00 77b164f4 00b0eacc 00b0eaa8 02000000 nt!KiFastCallEntry+0x12a
00b0e78c 77b14bcc 761e4a0b 00b0eacc 00b0eaa8 ntdll!KiFastSystemCallRet
00b0e790 761e4a0b 00b0eacc 00b0eaa8 02000000 ntdll!NtCreateUserProcess+0xc
00b0edec 76192059 00000000 00000000 000f2188 kernel32!CreateProcessInternalW+0xe75
00b0ee24 6b3669a8 00000000 000f2188 00000000 kernel32!CreateProcessW+0x2c
00b0eeb4 6b34ee3b 00b0eeec 000f20d8 00000020 mpsvc!CommonUtil::UtilCreateProcess+0x8c
00b0eef8 6b3558b5 00948b98 00000000 c4d82385 mpsvc!MpService::MpTaskSchedulerCmdRun+0x7f
00b0ef44 6b355c60 00000001 c4d8234d 00b0efc8 mpsvc!CommonUtil::CStdBasicString<unsigned short,CommonUtil::mp_char_traits<unsigned short>,std::allocator<unsigned short> >::operator+=+0x73
00b0ef8c 6b355d94 00b0efdc 00958830 00948b40 mpsvc!MpService::CMpSignaturesUpdateManager::RpcStartUpdate+0x1d0
00b0efc4 7654fc8f 00307f90 00000011 00b0f1f8 mpsvc!ServerMpRpcSigUpdClientOpen+0x32
00b0efec 765b4c53 6b355d62 00b0f1d8 00000005 RPCRT4!Invoke+0x2a
00b0f3f4 765b430e 00000000 00000000 00308048 RPCRT4!NdrStubCall2+0x2d6
00b0f410 7654f34a 00308048 c82f34ca 00318238 RPCRT4!NdrServerCall2+0x19
00b0f44c 7654f4da 6b39096e 00308048 00b0f4fc RPCRT4!DispatchToStubInCNoAvrf+0x4a
00b0f4a4 7654f3c6 00318238 00000000 00000000 RPCRT4!RPC_INTERFACE::DispatchToStubWorker+0x16c
00b0f4cc 76543974 00000000 00000000 00b0f4fc RPCRT4!RPC_INTERFACE::DispatchToStub+0x8b
00b0f518 7654f7a4 00307f90 00b0f534 0031c188 RPCRT4!LRPC_SCALL::DispatchRequest+0x257
00b0f538 7654f763 00307f90 0033d380 0031c188 RPCRT4!LRPC_SCALL::QueueOrDispatchCall+0xbd
00b0f554 7654f5ff 00000000 0033d368 00318238 RPCRT4!LRPC_SCALL::HandleRequest+0x34f
00b0f588 7654f573 00000000 0033d368 00319e90 RPCRT4!LRPC_SASSOCIATION::HandleRequest+0x144
00b0f5c0 7654ee4f 00318150 00000000 00319e90 RPCRT4!LRPC_ADDRESS::HandleRequest+0xbd
00b0f63c 7654ece7 00000000 00b0f658 76551357 RPCRT4!LRPC_ADDRESS::ProcessIO+0x50a
00b0f648 76551357 003181ec 00000000 00b0f680 RPCRT4!LrpcServerIoHandler+0x16
00b0f658 77afd3a3 00b0f6c4 003181ec 0031f898 RPCRT4!LrpcIoComplete+0x16
00b0f680 77b00748 00b0f6c4 00000000 00000000 ntdll!TppAlpcpExecuteCallback+0x1c5
00b0f7e8 761e1174 002e1da8 00b0f834 77b2b3f5 ntdll!TppWorkerThread+0x5a4
00b0f7f4 77b2b3f5 002e1da8 7709baea 00000000 kernel32!BaseThreadInitThunk+0xe
00b0f834 77b2b3c8 77afd63e 002e1da8 00000000 ntdll!__RtlUserThreadStart+0x70
00b0f84c 00000000 77afd63e 002e1da8 00000000 ntdll!_RtlUserThreadStart+0x1b
STACK_COMMAND: .tss 0x28 ; kb
FOLLOWUP_IP:
volmgr!RtlStringCbPrintfW+3a
86d66160 83c410 add esp,10h
SYMBOL_STACK_INDEX: 3
SYMBOL_NAME: volmgr!RtlStringCbPrintfW+3a
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: volmgr
IMAGE_NAME: volmgr.sys
DEBUG_FLR_IMAGE_TIMESTAMP: 4a5bbf1d
FAILURE_BUCKET_ID: 0x7f_8_volmgr!RtlStringCbPrintfW+3a
BUCKET_ID: 0x7f_8_volmgr!RtlStringCbPrintfW+3a
Followup: MachineOwner
---------
You might be converting Device Type of FILE_DEVICE_NETWORK_FILE_SYSTEM to dos name. FILE_DEVICE_NETWORK_FILE_SYSTEM is not a volume device object. so before calling ioVolumeDeviceToDosName you should check
if(IoGetCurrentIrpStackLocation(Irp)->FileObject->DeviceObject->DeviceType == FILE_DEVICE_DISK && !KeAreAllApcsDisabled())
{
//Do you ioVolumeDeviceTioDosName Here
}