debugger symbols and NPTL on RedHat 9

[Shachar Shemesh]

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

[Alexandre Julliard]

Shachar Shemesh  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.

[Shachar Shemesh]

Alexandre Julliard wrote:
> Shachar Shemesh  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

[Alexandre Julliard]

Shachar Shemesh  writes:
> Three questions, then:
> - 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.
> - 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.
> - Any way to force wine to start wine-kthread?

You don't want to do that, it won't work right.

[Mike Hearn]

On Wed, 02 Jun 2004 20:15:30 +0300, Shachar Shemesh wrote:
> - 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!

[Eric Pouech]

> 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+

[Shachar Shemesh]

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.

[Eric Pouech]

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+

[Shachar Shemesh]

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

[Eric Pouech]

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+