World Wine News

I'm trying to get a Visual C compiled program to run on Wine. I have the sources and full debug info for the PE part of the program. Obviously, however, it was not compiled on the same machine on which it is running.

To make things even more interesting, I would rather use some GUI frontend for the debugger.

As far as I can tell, I have two options to go about this:

1. Use Visual Studio's remote debugging
2. Use winedbg as a gdb backend for ddd

Option 1 fails miserably. I suspect the project is just too complex for Visual Studio to handle over the wire. When I try to do that, the Visual Studio front end (the one running on a Windows machine) crashes. This leaves me with just option 2.

When I try to run it like that (winedbg --gdb --no-start ), winedbg starts ok. When I hook ddd to it, however, winedbg complains about a missing source file (one that is not in the Windows source, btw). In the meanwhile, ddd claims to time out on the connection, and closes down.

err:wineconsole:WINECON_Fatal Couldn't find a decent font, aborting

it's time to make winedbg use dbghelp for its internal working This is the full patch (quite big), that's why it's been gzip:ed.

Among the biggest changes:

• all symbol information storage is now module relative, so we can unload a module (and its debugging information), and a process without pain
• portabiblity to another CPU should be easier now (CPU dependent backend)
• speed up memory allocation
• stabs related fixes:
  • now correctly handling symbol's size
  • blocks {} in functions are now correctly recognized and stored (also applies to local variables scoping)
  • better basic types management (less wild guesses in the code)
  • full support of inline functions (source stepping now shows the code in .h files for example)
• removal of external debugger (attaching with gdb is just fine to debug winedbg)
• fixed a couple of issues for symbol address handling (address lookup, incorrect type binding)
• winedbg now has a man page

The biggest changes since from the end user point of view:

• the $regs variable has disappeared
• all the 'walk' commands have now been merged into the 'info' ones. 'walk' is no longer a valid command
• module identification in symbol name now has the form of <module>!<symbol> which is the dbghelp/windbg way (instead of <module>:<symbol> or <module>.<symbol>)

I figured that going through the process of getting the program compiled as winelib was unnecessary, so I am still compiling it on Windows using Visual Studio. This, naturally, means that it's a PE. After resolving the font problems, I can finally get the program running through winedbg. While I'm doing ok at working like that, the client really prefers working with a GUI. When I try to run the program using the --gdb switch (with or without --no-start ), debug symbols for the PE part are not shown. I get all the symbols for the ELF dlls (wine's DLLs), but not for the PE program.

Is this a solvable problem? The program is using PDBs for debug symbols, they are not compiled into the PEs. I can change that, I guess, but I would really rather not. Will changing that solve anything?

I assumed you compiled your program with a recent version of msvc. winedbg doesn't support the latest version of msvc symbolic information. There are IIRC some options to turn on the eldest options (which may end up in putting the info inside the EXE, but that's not mandatory. but since I don't recall all the msvc switches YMMV).

BTW, I still looking for a decent documentation on latest MSVC symbolic info to enhance your debugging support. If someone has some info, I'm interested.

Damn, I was afraid of that answer.

I really wanted to think that the symbol interpretation was done by the backend (winedbg) rather than the frontend.

How possible is it to run "winedbg" as the backend to ddd/kdevelop instead of gdb? Are they even remotely close enough in command line?

I never tested that. As far as I can tell, both ddd and kdbg are using the regular gdb command line (not the MI* extensions from gdb). While rewriting winedbg I tried to make the commands as close as possible (from a syntax point of view) to the gdb ones. However, I didn't check yet format of answers and output. The idea anyway was to make winedbg look (command input, but we could do output too) as close as possible to gdb to ease up the migration of users from gdb to winedbg).

But it's likely we'll have some discrepencies in the output (and also the I/O control from the graphical front-end on winedbg which may play some tricks on us). Anyway, it won't be a five minute fix (and Alexandre needs to commit first the "small" pending winedbg part for me to go further).

This patch:

http://www.winehq.org/hypermail/wine-cvs/2004/04/0357.html

broke the MinGW build of msvcrt. The changelog says it's a compatibility fix. Dimi: what compatibility were you aiming at with this patch?

Compatibility with other headers. _WCTYPE_T_DEFINED is in a way part of the public interface, and when we use the headers in Winelib apps, we need to define it so we don't end up with duplicate declarations for wint_t/wctype_t. When we build msvcrt it's a different story of course, and we seem to need the exact opposite. Which is why I find the entire MSVCRT() thing not only ugly, but a bit problematic also.

Alexandre, why don't we just remove all those MSVCRT() macros, use the headers in Winelib apps, and duplicate what we need with a MSVCRT_ prefix in an internal header that we use just for building? These things are quite stable, so the risk of diverging is small, and for thinks like structures we can write tests to make sure we have the same sizes/layouts.

When compiling with STLPort I saw a method that can eliminate the need for the MSVCRT macro and yet produce MSVCRT_xxx for those who need it and an xxx for those how don't. Basically you have your Regular cleanroom headers-set for wine-lib and external dlls. And you have another set of headers for msvcrt compilation. In The second set:

• each header does some magic like #define stat_t MSVCRT_stat_t
• then #include <original/header.h>

Now compilation units that need the MSVCRT_xxx use an extra -I "$wine_include/internal_msvcrt" switch in the make files.

should I random pick an header and demonstrate the Technique?

From what I understand, the need for these differences are so the msvcrt.dll.so could define it's own set of functions and in place use gcc-glibc for implementation. This way steering away from both duplicates in Linking and conflicts with gcc-glibc headers. [Q] Why don't we avoid glibc all together. Take what ever code we are missing and have a complete self contained implementation? Just like MinGW's -nocygwin

(Now if we where using C++ the problems would be solved in 2 seconds flat: "namespace". Was not "namespace" back ported to C )

Right, it will not solve problems like this (for Boaz: _WCTYPE_T_DEFINED is a sentry for not defining a type twice, check out pretty much any header under include/msvcrt/ to see how it's used).

However, I did grep the source, and it seems that we're using the MSVCRT_ prefix only in dlls/msvcrt/*.c. And so it's not clear to me that duplicating part of the headers is going to be that bad. I mean, we will need duplication only for the stuff that we use internally across files. That doesn't include math functions for example, and a bunch of other stuff.

If you're positive this is not a good idea, I'll drop it, but if there is a chance it would be acceptable, I might give it a try...

Hello, i have retried to compile wine CVS on amd64 (gcc 3.4 with -m32, etc + kernel 2.6.4-rc2), where i was thinking the 0xc0000000 problem was solved. but i get:

wine: failed to initialize: /opt/wine/lib/wine/ntdll.dll.so: failed to map segment from shared object: Cannot allocate memory

attached to this mail the output of "strace32 wine"

one of the last lines is (i have 512Mb of ram)

old_mmap(NULL, 482376, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = -1 ENOMEM (Cannot allocate memory)

It looks like my kernel absolutely wants to allocate memory > 0xc0000000 :-) Any idea?