Hi,
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 mean while, ddd claims to time out on the connection, and closes down.
Am I missing something?
Shachar
- Use Visual Studio's remote debugging
never tried it, cannot help you here
- 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 mean while, ddd claims to time out on the connection, and closes down.
(the latest wine misses the debug information for the .spec.c files, and that's were main is... could you print the name of the file and the exact error message)
did you try the same without ddd ? 1/ run on one xterm winedbg --gdb --no-start <your pgm> 2/ in a second xterm, start gdb, and at the gdb prompt enter the 'target remote...' line output from winedbg at step 1
if it fails too, then ddd will also fail. (btw did a bare winedbg --gdb <your pgm> work ?)
A+
Eric Pouech wrote:
- Use Visual Studio's remote debugging
never tried it, cannot help you here
Oh, it's great when it works. Obviously, no ELF or Winelib symbols, but you are essentially using the standard visual studio debugger on a program running in Wine.
I used that to try and understand why a certain program won't run on Wine. I loaded two visual studios one next to the other. One ran the program locally, and the other remotely on Wine. Since they were on the same screen, I could compare all the info I needed.
(the latest wine misses the debug information for the .spec.c files, and that's were main is... could you print the name of the file and the exact error message)
See below. Don't have them at the moment. Is there any workaround? What do I do if there is no debug symbols for that part at all. What do I do if there are no debug symbols at all?
did you try the same without ddd ? 1/ run on one xterm winedbg --gdb --no-start <your pgm> 2/ in a second xterm, start gdb, and at the gdb prompt enter the 'target remote...' line output from winedbg at step 1
if it fails too, then ddd will also fail. (btw did a bare winedbg --gdb <your pgm> work ?)
Havn't tried.
A+
All of the above happened at a client's site. I don't have the info on me. I'll be able to retest on Sunday.
In any case, this is the latest wine RPMs running on RedHat 7.3 we are talking about.
Shachar
(the latest wine misses the debug information for the .spec.c files, and that's were main is... could you print the name of the file and the exact error message)
See below. Don't have them at the moment. Is there any workaround? What do I do if there is no debug symbols for that part at all. What do I do if there are no debug symbols at all?
that shouldn't stop gdb (not winedbg in this case) from debugging. Normally, setting a bp on WinMain & running should do the trick. That's why I wanted to get the exact message to know where it really comes from.
All of the above happened at a client's site. I don't have the info on me. I'll be able to retest on Sunday.
In any case, this is the latest wine RPMs running on RedHat 7.3 we are talking about.
ok. Again the simpliest test is to run without ddd, in a one step mode (without the --no-start flag).
A+
Eric Pouech wrote:
(the latest wine misses the debug information for the .spec.c files, and that's were main is... could you print the name of the file and the exact error message)
See below. Don't have them at the moment. Is there any workaround? What do I do if there is no debug symbols for that part at all. What do I do if there are no debug symbols at all?
that shouldn't stop gdb (not winedbg in this case) from debugging. Normally, setting a bp on WinMain & running should do the trick. That's why I wanted to get the exact message to know where it really comes from.
All of the above happened at a client's site. I don't have the info on me. I'll be able to retest on Sunday.
In any case, this is the latest wine RPMs running on RedHat 7.3 we are talking about.
ok. Again the simpliest test is to run without ddd, in a one step mode (without the --no-start flag).
A+
Apparently, there is a problem even without gdb at all. Attached is the output for running "winedbg program", with no arguments at all.
The system is a RedHat 9 with kernel 2.4.20-31.9, and the latest glibc available from redhat for it. Wine is CVS tip for today.
Shachar
Apparently, there is a problem even without gdb at all. Attached is the output for running "winedbg program", with no arguments at all.
The system is a RedHat 9 with kernel 2.4.20-31.9, and the latest glibc available from redhat for it. Wine is CVS tip for today.
Shacharerr:wineconsole:WINECON_Fatal Couldn't find a decent font, aborting
<g> it's been a long time we didn't get that one. You don't have fixed font installed that matches wineconsole's needs. Usually, it means you don't have a fixed font installed.
A+
Eric Pouech wrote:
Apparently, there is a problem even without gdb at all. Attached is the output for running "winedbg program", with no arguments at all.
The system is a RedHat 9 with kernel 2.4.20-31.9, and the latest glibc available from redhat for it. Wine is CVS tip for today.
Shacharerr:wineconsole:WINECON_Fatal Couldn't find a decent font, aborting
<g> it's been a long time we didn't get that one. You don't have fixed font installed that matches wineconsole's needs. Usually, it means you don't have a fixed font installed.
A+
Hmm..... Is that the reason it can't set the breakpoints????
In any case, I'll install fixed fonts on the machine and see where it leaves me. Do I need to run winedbg through wineconsole?
Shachar
Shachar Shemesh a écrit :
Eric Pouech wrote:
Apparently, there is a problem even without gdb at all. Attached is the output for running "winedbg program", with no arguments at all.
The system is a RedHat 9 with kernel 2.4.20-31.9, and the latest glibc available from redhat for it. Wine is CVS tip for today.
Shacharerr:wineconsole:WINECON_Fatal Couldn't find a decent font, aborting
<g> it's been a long time we didn't get that one. You don't have fixed font installed that matches wineconsole's needs. Usually, it means you don't have a fixed font installed.
A+
Hmm..... Is that the reason it can't set the breakpoints????
In any case, I'll install fixed fonts on the machine and see where it leaves me. Do I need to run winedbg through wineconsole?
to be precise, the console is created when winedbg launches the child process so that winedbg and the debuggee have too seperate consoles for their output. If setting up wineconsole is an issue, you can: 1/ either remove the CREATE_NEW_CONSOLE flag in winedbg/winedbg.c 2/ fire your executable from the command line, and attaching to it later on. This wouldn't work easily with ddd (still doable, but with pain)
you cannot set a bp because since the creation of the console fails, the creation of the debuggee from winedbg fails too.
A+
-
Eric Pouech -
Shachar Shemesh