|
From: Tom H. <th...@cy...> - 2003-09-11 14:23:00
Attachments:
valgrind-badinstr-patch
|
The attached patch modifies valgrind to make it report the location of
any unhandled instructions so that people can more easily tell which
part of their code is causing the problem. With this patch the typical
output changes from:
disInstr: unhandled instruction bytes: 0xF 0x5E 0xC8 0xF
to
disInstr: unhandled instruction bytes: 0xF 0x5E 0xC8 0xF
at 0x416C40E9: (within /usr/X11R6/lib/modules/dri/mga_dri.so)
Obviously if debugging information is available the results are more
detailed.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Nicholas N. <nj...@ca...> - 2003-09-12 08:37:23
|
On Thu, 11 Sep 2003, Tom Hughes wrote: > The attached patch modifies valgrind to make it report the location of > any unhandled instructions so that people can more easily tell which > part of their code is causing the problem. With this patch the typical > output changes from: > > disInstr: unhandled instruction bytes: 0xF 0x5E 0xC8 0xF > > to > > disInstr: unhandled instruction bytes: 0xF 0x5E 0xC8 0xF > at 0x416C40E9: (within /usr/X11R6/lib/modules/dri/mga_dri.so) > > Obviously if debugging information is available the results are more > detailed. It's a good idea, I'll look at adding it early next week (now is busy). N |
|
From: Nicholas N. <nj...@ca...> - 2003-09-16 07:43:35
|
On Thu, 11 Sep 2003, Tom Hughes wrote: > The attached patch modifies valgrind to make it report the location of > any unhandled instructions so that people can more easily tell which > part of their code is causing the problem. With this patch the typical > output changes from: > > disInstr: unhandled instruction bytes: 0xF 0x5E 0xC8 0xF > > to > > disInstr: unhandled instruction bytes: 0xF 0x5E 0xC8 0xF > at 0x416C40E9: (within /usr/X11R6/lib/modules/dri/mga_dri.so) > > Obviously if debugging information is available the results are more > detailed. I just committed a change to HEAD that does this. I didn't use your patch, but instead some similar changes that I'd already made for Massif. Thanks for the idea. N |
|
From: Tom H. <th...@cy...> - 2003-09-18 07:58:41
|
In message <Pin...@re...>
Nicholas Nethercote <nj...@ca...> wrote:
> I just committed a change to HEAD that does this. I didn't use your
> patch, but instead some similar changes that I'd already made for Massif.
Your commit finally showed up in the public side of the CVS tree
and I just noticed a slight bug - something that was actually in my
patch in fact.
That is that the address reported for the bad instruction is the
value of the eip variable, but that may have been moved - eip_start
is actually the saved value of eip at the start of the instruction.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Nicholas N. <nj...@ca...> - 2003-09-18 08:38:02
|
On Thu, 18 Sep 2003, Tom Hughes wrote: > Your commit finally showed up in the public side of the CVS tree > and I just noticed a slight bug - something that was actually in my > patch in fact. Because I copied that part of your patch :) > That is that the address reported for the bad instruction is the > value of the eip variable, but that may have been moved - eip_start > is actually the saved value of eip at the start of the instruction. Fixed, committed. Thanks. N |