debugger symbols and NPTL on RedHat 9
Hi all, As mentioned in a previous thread, I'm trying to get a client to migrate their product to Linux using Wine. So far, the results have been so so, with mightily strange results (sockets in "Established" state with no controlling process, zomby processes who's parent is init that are not being cleared, etc.). After some looking around, we tried running Wine with "LD_ASSUME_KERNEL=2.4.1", and the problems magically disappeared. Maybe because of the time that passed since these problems were common, I clean forgot about this option. I noticed that wine-pthread was running instead of wine-kthread, but I did not think of it as a problem beyond a theoretical performance problem. It seems, however, that guessing wrong had pretty dire side effects. So, the question <--------------- Will running wine-kthread directly work? Or is there something crucial done by the "wine" executable? Second problem is probably independant. 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 solveable 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? Shachar -- Shachar Shemesh Lingnu Open Source Consulting http://www.lingnu.com/
Shachar Shemesh <wine-devel(a)shemesh.biz> writes:
So, the question <---------------
Will running wine-kthread directly work? Or is there something crucial done by the "wine" executable?
These days it launches the preloader too, so you probably shouldn't bypass that. But in any case it's unlikely that things are going to work right by using the wrong threading version; it may seem to solve some issues but it will definitely create others. -- Alexandre Julliard julliard(a)winehq.org
Alexandre Julliard wrote:
Shachar Shemesh <wine-devel(a)shemesh.biz> writes:
So, the question <---------------
Will running wine-kthread directly work? Or is there something crucial done by the "wine" executable?
These days it launches the preloader too, so you probably shouldn't bypass that. But in any case it's unlikely that things are going to work right by using the wrong threading version; it may seem to solve some issues but it will definitely create others.
Three questions, then: 1. Any idea why it starts the wrong executeable? 2. Is using wine-pthread when LD_ASSUME_KERNEL=2.4.1 considered "the wrong threading version"? 3. Any way to force wine to start wine-kthread? Shachar -- Shachar Shemesh Lingnu Open Source Consulting http://www.lingnu.com/
Shachar Shemesh <wine-devel(a)shemesh.biz> writes:
Three questions, then: 1. Any idea why it starts the wrong executeable?
It doesn't, you do that when you start wine-kthread directly on a platform that requires wine-pthread.
2. Is using wine-pthread when LD_ASSUME_KERNEL=2.4.1 considered "the wrong threading version"?
Yes, I'd expect it to use wine-kthread in that case.
3. Any way to force wine to start wine-kthread?
You don't want to do that, it won't work right. -- Alexandre Julliard julliard(a)winehq.org
On Wed, 02 Jun 2004 20:15:30 +0300, Shachar Shemesh wrote:
3. Any way to force wine to start wine-kthread?
I suppose you need to figure out why you're getting such wierd symptoms, starting the wrong wine-[pk]thread version will cause even wierder stuff (like libc not being thread safe). The NPTL stuff is scary, good luck!
Second problem is probably independant. it is 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. good 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. this isn't linked to the options from winedbg
Is this a solveable 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.
A+
Eric Pouech wrote:
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.
this isn't linked to the options from winedbg
While I agree in principle, in practice symbol lookups *appear* to work when winedbg is invoking the application directly.
Is this a solveable 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.
Visual studio 6.
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).
VC6 offers the following options for their debug info: Microsoft Format COFF format both Any recommendations on what to use?
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.
A+
I don't know what VC7 offers, but it appears like noone is using it anyways. -- Shachar Shemesh Lingnu Open Source Consulting http://www.lingnu.com/
Shachar Shemesh a écrit :
Eric Pouech wrote:
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.
this isn't linked to the options from winedbg
While I agree in principle, in practice symbol lookups *appear* to work when winedbg is invoking the application directly. silly me. when run with gdb, the PE symbol lookup doesn't work, gdb doesn't know anything about PE. You need to use winedbg without the gdb proxy. But you will loose the GUI debugging part (à la DDD, or kdbg...). A+
Eric Pouech wrote:
Shachar Shemesh a écrit :
While I agree in principle, in practice symbol lookups *appear* to work when winedbg is invoking the application directly.
silly me. when run with gdb, the PE symbol lookup doesn't work, gdb doesn't know anything about PE. You need to use winedbg without the gdb proxy. But you will loose the GUI debugging part (à la DDD, or kdbg...). A+
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? Shachar -- Shachar Shemesh Lingnu Open Source Consulting http://www.lingnu.com/
Shachar Shemesh a écrit :
Eric Pouech wrote:
Shachar Shemesh a écrit :
While I agree in principle, in practice symbol lookups *appear* to work when winedbg is invoking the application directly.
silly me. when run with gdb, the PE symbol lookup doesn't work, gdb doesn't know anything about PE. You need to use winedbg without the gdb proxy. But you will loose the GUI debugging part (à la DDD, or kdbg...). A+
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. AFAICT, 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) from the gdb one's. 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).
A+
participants (4)
-
Alexandre Julliard -
Eric Pouech -
Mike Hearn -
Shachar Shemesh