Am 30.08.2016 um 22:09 schrieb Bernhard Übelacker:
$ wine winedbg --gdb d3d8_test.exe.so ... 0025:0026: loads DLL C:\windows\system32\wined3d.dll @0x7ec20000 (0<0>) ... Wine-gdb> info symbol 0x7ec2EF19 init_output_registers + 1172 in section .text of /.../dlls/wined3d/wined3d.dll.so
This does not work in case wined3d got relocated. You can either use addr2line or winedbg directly on the target process. For addr2line you need to know the base address of wined3d in the crashed process and then use something like:
addr2line -e wined3d.dll.so -j .text 0xdeadbeef
where 0xdeadbeef is the address of the crash minus the base address of the ELF section as shown in the crash dump. I think using winedbg is easier. Either directly start the process using winedbg or in case the process detects debuggers, you can also SHIFT + right click on the crash dialog to start winedbg. Then you can just use bt to display the backtrace including the source code lines (although the output should be identical to the crash dialog). For arbitrary addresses, you can just disassemble some instructions, it should also display the filename and line number using x/10i 0xdeadbeef. You can also use registers this way (for example x/10i $eip).
If the application sets up its own crash handler, you can either attach to the process when it displays an error by starting winedbg as standalone program and then use "info process" and "attach 0x...". This way you won't get a correct backtrace though, so you might want to edit dlls/ntdll/signal_i386.c instead. I attached a hack to prevent 32 bit applications from catching access violations. In case they call SetUnhandledExceptionFilter, you also need to make this a noop as it replaces the handler to start the debugger.
Regards, Michael