|
From: Tom H. <to...@co...> - 2006-02-15 17:18:42
|
In message <200...@kt...>
Eric Pouech <eri...@wa...> wrote:
> We do however have some (other) strange effect with stacks. When wine
> starts, the first thread is given a new stack (different from the one
> allocated by the OS). We need this because most windows executable
> define the size of the stack, and we must create a stack of the right
> size even for the first thread.
>
> So, the typical layout we end up with is:
>
> 0xBE?????? original stack
> 0x20?????? new stack
>
> which is horrible for valgrind, has the range for stacks is seen
> between 0x20?????? 0xBE??????, and in most of the cases we cannot get
> a decent backtrace on this stack. The problem doesn't occur on any
> other thread, because we can define at thread creation time the size
> the stack.
Well valgrind itself provides the client program (wine in this case) with
a stack that is not the original OS and it then emulates the stack growth
behaviour that the kernel normally provides.
There should be no problem with wine allocating it's own stack - you
will probably get a stack switch warning from valgrind when you jump
on to it but valgrind should cope.
Not sure why you aren't getting backtraces - one problem with
backtraces in wine is obviously where you have things on the stack
that only have PDB symbol tables/debugging which valgrind won't
understand but it should still be able to unwind so long as there
are normal x86 frames on the stack.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Julian S. <js...@ac...> - 2006-02-15 17:38:42
|
> Not sure why you aren't getting backtraces - one problem with > backtraces in wine is obviously where you have things on the stack > that only have PDB symbol tables/debugging which valgrind won't > understand but it should still be able to unwind so long as there > are normal x86 frames on the stack. The symbol-table and line-number info and to some extent the stack unwind info is stored inside V in a target-neutral format. So at least in principle, it should be possible read info from PDBs (possibly using Adam Gundy's code) and store that; then V would be able to seamlessly display backtraces from combinations of ELF and PDB objects. J |
|
From: Tom H. <to...@co...> - 2006-02-15 17:54:09
|
In message <200...@ac...>
Julian Seward <js...@ac...> wrote:
> > Not sure why you aren't getting backtraces - one problem with
> > backtraces in wine is obviously where you have things on the stack
> > that only have PDB symbol tables/debugging which valgrind won't
> > understand but it should still be able to unwind so long as there
> > are normal x86 frames on the stack.
>
> The symbol-table and line-number info and to some extent the stack
> unwind info is stored inside V in a target-neutral format. So at
> least in principle, it should be possible read info from PDBs
> (possibly using Adam Gundy's code) and store that; then V would
> be able to seamlessly display backtraces from combinations of
> ELF and PDB objects.
Absolutely. Adam's code was the wine code anyway. Adding PE executable
and PDB debugging support is certainly possible.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Eric P. <eri...@wa...> - 2006-02-15 18:21:10
|
Tom Hughes wrote:
> In message <200...@kt...>
> Eric Pouech <eri...@wa...> wrote:
>=20
>=20
>>We do however have some (other) strange effect with stacks. When wine
>>starts, the first thread is given a new stack (different from the one
>>allocated by the OS). We need this because most windows executable
>>define the size of the stack, and we must create a stack of the right
>>size even for the first thread.
>>
>>So, the typical layout we end up with is:
>>
>>0xBE?????? original stack
>>0x20?????? new stack
>>
>>which is horrible for valgrind, has the range for stacks is seen
>>between 0x20?????? 0xBE??????, and in most of the cases we cannot get
>>a decent backtrace on this stack. The problem doesn't occur on any
>>other thread, because we can define at thread creation time the size
>>the stack.
>=20
>=20
> Well valgrind itself provides the client program (wine in this case) wi=
th
> a stack that is not the original OS and it then emulates the stack grow=
th
> behaviour that the kernel normally provides.
>=20
> There should be no problem with wine allocating it's own stack - you
> will probably get a stack switch warning from valgrind when you jump
> on to it but valgrind should cope.
>=20
> Not sure why you aren't getting backtraces
it's because of the test:
if (fp_min + VG_(clo_max_stackframe) <=3D fp_max) {
in get_StackTrace2
what I currently get is fp_min (on the new stack) is around 0x20??????
while fp_max, as being computes as the highest sp ever met in somewhere=20
in 0xBE?????? (as the first stack has been used).
which means that the test always fail, and we never get a backtrace
again, this only happens for the first thread of a program. the next=20
threads are created directly with the right stack, and this doesn't happe=
n
I tried commenting out the test, and get the correct backtraces
however, this is highly error prone and triggers in some other tests=20
sigsegv in get_StackTrace2 (because of the large span of fp_min/fp_max)
> - one problem with
> backtraces in wine is obviously where you have things on the stack
> that only have PDB symbol tables/debugging which valgrind won't
> understand but it should still be able to unwind so long as there
> are normal x86 frames on the stack.
this is a different problem
A=B0
--=20
Eric Pouech
|