You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
(58) |
Apr
(261) |
May
(169) |
Jun
(214) |
Jul
(201) |
Aug
(219) |
Sep
(198) |
Oct
(203) |
Nov
(241) |
Dec
(94) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(137) |
Feb
(149) |
Mar
(150) |
Apr
(193) |
May
(95) |
Jun
(173) |
Jul
(137) |
Aug
(236) |
Sep
(157) |
Oct
(150) |
Nov
(136) |
Dec
(90) |
| 2005 |
Jan
(139) |
Feb
(130) |
Mar
(274) |
Apr
(138) |
May
(184) |
Jun
(152) |
Jul
(261) |
Aug
(409) |
Sep
(239) |
Oct
(241) |
Nov
(260) |
Dec
(137) |
| 2006 |
Jan
(191) |
Feb
(142) |
Mar
(169) |
Apr
(75) |
May
(141) |
Jun
(169) |
Jul
(131) |
Aug
(141) |
Sep
(192) |
Oct
(176) |
Nov
(142) |
Dec
(95) |
| 2007 |
Jan
(98) |
Feb
(120) |
Mar
(93) |
Apr
(96) |
May
(95) |
Jun
(65) |
Jul
(62) |
Aug
(56) |
Sep
(53) |
Oct
(95) |
Nov
(106) |
Dec
(87) |
| 2008 |
Jan
(58) |
Feb
(149) |
Mar
(175) |
Apr
(110) |
May
(106) |
Jun
(72) |
Jul
(55) |
Aug
(89) |
Sep
(26) |
Oct
(96) |
Nov
(83) |
Dec
(93) |
| 2009 |
Jan
(97) |
Feb
(106) |
Mar
(74) |
Apr
(64) |
May
(115) |
Jun
(83) |
Jul
(137) |
Aug
(103) |
Sep
(56) |
Oct
(59) |
Nov
(61) |
Dec
(37) |
| 2010 |
Jan
(94) |
Feb
(71) |
Mar
(53) |
Apr
(105) |
May
(79) |
Jun
(111) |
Jul
(110) |
Aug
(81) |
Sep
(50) |
Oct
(82) |
Nov
(49) |
Dec
(21) |
| 2011 |
Jan
(87) |
Feb
(105) |
Mar
(108) |
Apr
(99) |
May
(91) |
Jun
(94) |
Jul
(114) |
Aug
(77) |
Sep
(58) |
Oct
(58) |
Nov
(131) |
Dec
(62) |
| 2012 |
Jan
(76) |
Feb
(93) |
Mar
(68) |
Apr
(95) |
May
(62) |
Jun
(109) |
Jul
(90) |
Aug
(87) |
Sep
(49) |
Oct
(54) |
Nov
(66) |
Dec
(84) |
| 2013 |
Jan
(67) |
Feb
(52) |
Mar
(93) |
Apr
(65) |
May
(33) |
Jun
(34) |
Jul
(52) |
Aug
(42) |
Sep
(52) |
Oct
(48) |
Nov
(66) |
Dec
(14) |
| 2014 |
Jan
(66) |
Feb
(51) |
Mar
(34) |
Apr
(47) |
May
(58) |
Jun
(27) |
Jul
(52) |
Aug
(41) |
Sep
(78) |
Oct
(30) |
Nov
(28) |
Dec
(26) |
| 2015 |
Jan
(41) |
Feb
(42) |
Mar
(20) |
Apr
(73) |
May
(31) |
Jun
(48) |
Jul
(23) |
Aug
(55) |
Sep
(36) |
Oct
(47) |
Nov
(48) |
Dec
(41) |
| 2016 |
Jan
(32) |
Feb
(34) |
Mar
(33) |
Apr
(22) |
May
(14) |
Jun
(31) |
Jul
(29) |
Aug
(41) |
Sep
(17) |
Oct
(27) |
Nov
(38) |
Dec
(28) |
| 2017 |
Jan
(28) |
Feb
(30) |
Mar
(16) |
Apr
(9) |
May
(27) |
Jun
(57) |
Jul
(28) |
Aug
(43) |
Sep
(31) |
Oct
(20) |
Nov
(24) |
Dec
(18) |
| 2018 |
Jan
(34) |
Feb
(50) |
Mar
(18) |
Apr
(26) |
May
(13) |
Jun
(31) |
Jul
(13) |
Aug
(11) |
Sep
(15) |
Oct
(12) |
Nov
(18) |
Dec
(13) |
| 2019 |
Jan
(12) |
Feb
(29) |
Mar
(51) |
Apr
(22) |
May
(13) |
Jun
(20) |
Jul
(13) |
Aug
(12) |
Sep
(21) |
Oct
(6) |
Nov
(9) |
Dec
(5) |
| 2020 |
Jan
(13) |
Feb
(5) |
Mar
(25) |
Apr
(4) |
May
(40) |
Jun
(27) |
Jul
(5) |
Aug
(17) |
Sep
(21) |
Oct
(1) |
Nov
(5) |
Dec
(15) |
| 2021 |
Jan
(28) |
Feb
(6) |
Mar
(11) |
Apr
(5) |
May
(7) |
Jun
(8) |
Jul
(5) |
Aug
(5) |
Sep
(11) |
Oct
(9) |
Nov
(10) |
Dec
(12) |
| 2022 |
Jan
(7) |
Feb
(13) |
Mar
(8) |
Apr
(7) |
May
(12) |
Jun
(27) |
Jul
(14) |
Aug
(27) |
Sep
(27) |
Oct
(17) |
Nov
(17) |
Dec
|
| 2023 |
Jan
(10) |
Feb
(18) |
Mar
(9) |
Apr
(26) |
May
|
Jun
(13) |
Jul
(18) |
Aug
(5) |
Sep
(6) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
|
|
|
|
1
(5) |
|
2
(2) |
3
(15) |
4
(3) |
5
|
6
(11) |
7
(4) |
8
|
|
9
(3) |
10
(6) |
11
(4) |
12
(5) |
13
(7) |
14
(37) |
15
(8) |
|
16
(1) |
17
(19) |
18
(20) |
19
(20) |
20
(15) |
21
(13) |
22
|
|
23
|
24
(20) |
25
(6) |
26
(2) |
27
(4) |
28
(6) |
29
|
|
30
(5) |
|
|
|
|
|
|
|
From: Nicholas N. <nj...@ca...> - 2003-11-19 21:31:43
|
On Wed, 19 Nov 2003, Jeremy Fitzhardinge wrote:
> Question: does gcc move %ESP up over the generated thunk when it is
> finished with it, or does it just overwrite the code?
The former, AFAICT:
test2:
pushl %ebp
movl %esp, %ebp
subl $36, %esp
leal -24(%ebp), %edx
movl $test2_inner.1+6, %eax
leal -8(%ebp), %ecx
subl %ecx, %eax
movb $-71, -24(%ebp) # code
movl %ecx, -23(%ebp) # code
movb $-23, -19(%ebp) # code
movl %eax, -18(%ebp) # code
pushl %edx
call call_func
leave
ret
N
|
|
From: Jeremy F. <je...@go...> - 2003-11-19 21:06:59
|
On Wed, 2003-11-19 at 07:48, Nicholas Nethercote wrote: > The support for self-modifying code was removed because, IIRC, it was > clunky and rarely needed, and the VALGRIND_DISCARD_TRANSLATIONS macro was > good enough for eg. JIT-compilers and other programs that generate code at > runtime. > > But if runtime code-generation occurs and the user doesn't even realise > it, that's bad. It should be easy enough to tell when this is happening and we need to be extra-careful. If vg_translate finds itself reading instructions from near the %ESP, then we should note that we have cached code for the stack, and we need to be paranoid about stack writes/%ESP movement. Question: does gcc move %ESP up over the generated thunk when it is finished with it, or does it just overwrite the code? Presumably on other architectures it generates an icache invalidate for the memory it's modifying, which would be our cue to do something sensible. Pity x86 does all that stuff implicitly... J |
|
From: Nicholas N. <nj...@ca...> - 2003-11-19 20:21:26
|
On Wed, 19 Nov 2003, Josef Weidendorfer wrote: > > But if runtime code-generation occurs and the user doesn't even realise > > it, that's bad. > > Yes. > Can we print out a warning when code on the stack/heap is about to be > instrumented? Perhaps with some warning-suppression support. > > How was support for self-modifying code working? I don't know, I never looked at it. > For basic blocks on stack/ heap, can't we instrument a call to a > helper-function at beginning which checks (via checksum?) if the > original version of the code was changed, whenever the basic-block is > called? Sounds like it would work, as long as we're confident we can identify the stack/heap code blocks accurately. However, for programs like JIT-compilers that use the VALGRIND_DISCARD_TRANSLATIONS macro currently, it would be a performance hit to have an extra C call + checksum for every basic block. Is there a better way to do it? N |
|
From: Nicholas N. <nj...@ca...> - 2003-11-19 15:48:27
|
On Wed, 19 Nov 2003, Josef Weidendorfer wrote:
> just looked at this strange piece of code.
> Now I know why Intel refuses to support nested functions in their
> compilers ;-)
>
> When GCC-compiled code needs a function pointer for a nested function, it
> seems to produce dynamically some trampoline code on the stack, and uses the
> start address of this piece of code as the function pointer (don't ask me
> why).
>
> Note that the function pointer for the nested function will point to the same
> address of dynamically produced code. Valgrind's instrumentation engine
> doesn't detect that the code on stack is changed inbetween, and uses
> the same instrumented version both times.
>
> The code works as expected if you change call_func() this way:
> =============================================
> #include <valgrind/valgrind.h>
> ...
> static void call_func(void (*sel)(void))
> {
> sel();
> VALGRIND_DISCARD_TRANSLATIONS(sel,20);
> }
> =============================================
Yes. Or, if the code is changed a bit so that the on-stack code doesn't
happen to be at the same address.
> Note that VG would be quite slow if it had to check if a write instruction
> is about to change already instrumented code (Wasn't this the
> case in the first days of VG?).
Alternatively, one could invalidate any code on the stack when it shrinks,
but that would hurt performance too.
The support for self-modifying code was removed because, IIRC, it was
clunky and rarely needed, and the VALGRIND_DISCARD_TRANSLATIONS macro was
good enough for eg. JIT-compilers and other programs that generate code at
runtime.
But if runtime code-generation occurs and the user doesn't even realise
it, that's bad.
Hmm.
N
|
|
From: Tom H. <th...@cy...> - 2003-11-19 15:43:50
|
In message <fre...@fm...>
sa...@fr... wrote:
> Could you please also replace the "KLUDGED call to: ..."
> messages to something more straightforward?
> For example I'd like to know what I am doing wrong when I
> make a "kludged call" to phtread_cond_destroy (I link
> pthread dinamically).
You're not doing anything wrong. It's just that you're using a part
of the pthread interface that valgrind currently doesn't support very
well. The kludged message is telling you that although valgrind has
done something in response to that call, it may well not have been
the right thing and that you program might therefore misbehave as a
result.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Attila <sa...@fr...> - 2003-11-19 15:31:00
|
Hi, Nicholas Nethercote <nj...@ca...> wrote: > > I just committed a change so it prints this: > > Warning: ignored attempt to set SIGKILL handler in sigaction(); > the SIGKILL signal is uncatchable > Thank you for doing so. Could you please also replace the "KLUDGED call to: ..." messages to something more straightforward? For example I'd like to know what I am doing wrong when I make a "kludged call" to phtread_cond_destroy (I link pthread dinamically). BR, Attila |
|
From: Josef W. <Jos...@gm...> - 2003-11-19 15:26:24
|
Hi,
just looked at this strange piece of code.
Now I know why Intel refuses to support nested functions in their
compilers ;-)
When GCC-compiled code needs a function pointer for a nested function, it
seems to produce dynamically some trampoline code on the stack, and uses the
start address of this piece of code as the function pointer (don't ask me
why).
Note that the function pointer for the nested function will point to the same
address of dynamically produced code. Valgrind's instrumentation engine
doesn't detect that the code on stack is changed inbetween, and uses
the same instrumented version both times.
The code works as expected if you change call_func() this way:
=============================================
#include <valgrind/valgrind.h>
...
static void call_func(void (*sel)(void))
{
sel();
VALGRIND_DISCARD_TRANSLATIONS(sel,20);
}
=============================================
Note that VG would be quite slow if it had to check if a write instruction
is about to change already instrumented code (Wasn't this the
case in the first days of VG?).
Josef
|
|
From: Maarten B. <maa...@mi...> - 2003-11-19 15:17:10
|
Hello
On Wed, 2003-11-19 at 08:08, Dimitri Papadopoulos-Orfanos wrote:
> Nicholas Nethercote wrote:
> > On Wed, 19 Nov 2003, Dimitri Papadopoulos-Orfanos wrote:
...
> >> > ==3546== Conditional jump or move depends on uninitialised value(s)
> >>
> >>Again, some programers just wonder what this error message means. I
> >>guess that it has to do with code looking like
> >> if ( variable ) {
> >> [...]
> >>where "variable" isn't initialised. Again maybe this error message could
> >>be rewritten using simple words, if at all possible.
> >
> >
> > Can you suggest alternatives that are easier to understand?
>
> Not in the first case. When I say I can't understand the message, I mean it.
>
> In the second case, I think the important part of the message is not
> that there's a "conditional jump or move" but an "uninitialised value".
> What about
> Attempt to read an uninitialised variable
> or something like that? I'm not really sure this covers the same error,
> but that's the idea.
The order of the message is a little confusing (until you get used
to it ;-/) How about reordering and bringing the "uninitialised"
to the front:
==3546== Uninitialised value(s) used in conditional jump or move.
Anyway, keep up the good work, it is a great tool!
Cheers,
Maarten.
--
Maarten Ballintijn <maa...@mi...>
Massachusetts Institute of Technology
|
|
From: Crispin F. <val...@fl...> - 2003-11-19 14:00:18
|
I made a simpler test case while having a quick look at this, see the attached file. I couldn't simplify it any more than this. Hope it helps. Crispin On Wed, 2003-11-19 at 12:45, Lee Kindness wrote: > Hi, some further info on this problem (see below), not necessarily a > reply to Dennis. > > Dennis Lubert writes: > > At 17:10 18.11.2003, you wrote: > > >The attached test case results in different output when run under > > >Valgrind (version 2.0 & 1.9.6) compared to when it is run > > >stand-alone. This source makes use of nested functions. > > > > > >The following is output when run normally: > > > > > > % ./hmmlk 1 2 > > > bob is odd > > > bob is NOT even > > > > > >and when run under Valgrind (I've also attached verbose output): > > > > > > % valgrind ./hmmlk 1 2 > > > bob is odd > > > bob is even > > > > I can confirm this for gcc 3.3.1 and valgrind HEAD as well as 1.9.6 ... > > Even the nul skin does produce this behaviour. > > > > A quick look at the generated assembly, looks as if it should work, but > > obiously valgrind is confusing something. I would rather try to fix > > valgrind, than simply not to use nested functions, since the bug might > > affect other function pointer / nested function issues. > > > > gcc produces two symbols. One is sel.1 and the other is sel.3 ... I would > > suspect that valgrind does not get the second symbol right, since it does > > not even seem to pass the right function pointer to find_name ... Another > > curious thing is, if you let the program display the pointers, they seem to > > be the same, with and without valgrind... Its all just a rough guess, since > > I don't know much about the internals, and how gcc handles function pointers... > > > The double nesting is irrelevant; moving both is_even() and is_odd() > to the outer scope doesn't change the behaviour. > > Both "hmmlk" and "hmmlk 0" (which use only is_odd()) work the same > when run normally and when run under valgrind > > The order of definition of is_odd(), is_even() is irrelevant, but the > order of calling is not: I tried changing main() to allow several > calls, in various orders of test() and testw() and it seems that the > second function called is always in error (ie differs under valgrind > and normal running), however often it is called, while the first one > is ok, however often called. > > Thanks, Lee. > > > ------------------------------------------------------- > This SF.net email is sponsored by: SF.net Giveback Program. > Does SourceForge.net help you be more productive? Does it > help you create better code? SHARE THE LOVE, and help us help > YOU! Click Here: http://sourceforge.net/donate/ > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: Paul H. <pa...@ha...> - 2003-11-19 13:54:00
|
On Wed, 19 Nov 2003, Lee Kindness wrote:
> Date: Wed, 19 Nov 2003 12:41:40 +0000
> From: Lee Kindness <lki...@cs...>
> To: pa...@ha...
> Cc: Lee Kindness <lki...@cs...>, val...@li...,
> Duncan Muirhead <du...@cs...>
> Subject: Re: [Valgrind-users] Nested functions
>
> Paul Haas writes:
> > Don't nest the functions and it just works.
Sorry about that comment. I realized the inappropriateness within seconds
of hitting the send button.
> Granted, but that's not really a solution. Valgrind should handle
> nested function calls. Your added debug has shown that when run under
> Valgrind the program flow is altered - I'd say that's a Valgrind bug
> and to work around it isn't the best long-term solution, afterall
> who's to say the same bug does not affect "more normal" programing
> practices?
>
> Thanks, L.
Here's a shorter program that demonstrates the same bug.
#include <stdlib.h>
#include <stdio.h>
#include <string.h>
static void CallViaP(void (*sel)(void)) {
sel();
}
int main(int argc, char** argv) {
static void MidFunc1(void) {
static void BottomFunc1(void) {
fprintf(stdout,"BottomFunc1\n");
}
CallViaP( BottomFunc1);
}
static void MidFunc2(void) {
static void BottomFunc2( void ) {
fprintf(stdout,"BottomFunc2\n");
}
CallViaP(BottomFunc2 );
}
MidFunc1();
MidFunc2();
return 0;
}
|
|
From: Dimitri Papadopoulos-O. <pap...@sh...> - 2003-11-19 13:06:58
|
Nicholas Nethercote wrote:
> On Wed, 19 Nov 2003, Dimitri Papadopoulos-Orfanos wrote:
>
>
>> > ==3546== Syscall param modify_ldt(ptr)(func=1 or 0x11) contains
>>uninitialised or unaddressable byte(s)
>>
>>I don't understand this error message. I'd like to suggest rewriting it
>>using plain English, so that casual users can understand what's
>>happenning. I suspect many power users on this mailing list do
>>understand this message, but other programers just don't understand what
>>this means (that's the case at my place):
>> modify_ldt(ptr)(func=1 or 0x11)
>>
>>
>> > ==3546== Conditional jump or move depends on uninitialised value(s)
>>
>>Again, some programers just wonder what this error message means. I
>>guess that it has to do with code looking like
>> if ( variable ) {
>> [...]
>>where "variable" isn't initialised. Again maybe this error message could
>>be rewritten using simple words, if at all possible.
>
>
> Can you suggest alternatives that are easier to understand?
Not in the first case. When I say I can't understand the message, I mean it.
In the second case, I think the important part of the message is not
that there's a "conditional jump or move" but an "uninitialised value".
What about
Attempt to read an uninitialised variable
or something like that? I'm not really sure this covers the same error,
but that's the idea.
--
Dimitri
|
|
From: Lee K. <lki...@cs...> - 2003-11-19 12:45:17
|
Hi, some further info on this problem (see below), not necessarily a reply to Dennis. Dennis Lubert writes: > At 17:10 18.11.2003, you wrote: > >The attached test case results in different output when run under > >Valgrind (version 2.0 & 1.9.6) compared to when it is run > >stand-alone. This source makes use of nested functions. > > > >The following is output when run normally: > > > > % ./hmmlk 1 2 > > bob is odd > > bob is NOT even > > > >and when run under Valgrind (I've also attached verbose output): > > > > % valgrind ./hmmlk 1 2 > > bob is odd > > bob is even > > I can confirm this for gcc 3.3.1 and valgrind HEAD as well as 1.9.6 ... > Even the nul skin does produce this behaviour. > > A quick look at the generated assembly, looks as if it should work, but > obiously valgrind is confusing something. I would rather try to fix > valgrind, than simply not to use nested functions, since the bug might > affect other function pointer / nested function issues. > > gcc produces two symbols. One is sel.1 and the other is sel.3 ... I would > suspect that valgrind does not get the second symbol right, since it does > not even seem to pass the right function pointer to find_name ... Another > curious thing is, if you let the program display the pointers, they seem to > be the same, with and without valgrind... Its all just a rough guess, since > I don't know much about the internals, and how gcc handles function pointers... The double nesting is irrelevant; moving both is_even() and is_odd() to the outer scope doesn't change the behaviour. Both "hmmlk" and "hmmlk 0" (which use only is_odd()) work the same when run normally and when run under valgrind The order of definition of is_odd(), is_even() is irrelevant, but the order of calling is not: I tried changing main() to allow several calls, in various orders of test() and testw() and it seems that the second function called is always in error (ie differs under valgrind and normal running), however often it is called, while the first one is ok, however often called. Thanks, Lee. |
|
From: Lee K. <lki...@cs...> - 2003-11-19 12:41:58
|
Paul Haas writes: > Don't nest the functions and it just works. Granted, but that's not really a solution. Valgrind should handle nested function calls. Your added debug has shown that when run under Valgrind the program flow is altered - I'd say that's a Valgrind bug and to work around it isn't the best long-term solution, afterall who's to say the same bug does not affect "more normal" programing practices? Thanks, L. |
|
From: Nicholas N. <nj...@ca...> - 2003-11-19 12:37:48
|
On Wed, 19 Nov 2003, Dimitri Papadopoulos-Orfanos wrote:
> > ==3546== Syscall param modify_ldt(ptr)(func=1 or 0x11) contains
> uninitialised or unaddressable byte(s)
>
> I don't understand this error message. I'd like to suggest rewriting it
> using plain English, so that casual users can understand what's
> happenning. I suspect many power users on this mailing list do
> understand this message, but other programers just don't understand what
> this means (that's the case at my place):
> modify_ldt(ptr)(func=1 or 0x11)
>
>
> > ==3546== Conditional jump or move depends on uninitialised value(s)
>
> Again, some programers just wonder what this error message means. I
> guess that it has to do with code looking like
> if ( variable ) {
> [...]
> where "variable" isn't initialised. Again maybe this error message could
> be rewritten using simple words, if at all possible.
Can you suggest alternatives that are easier to understand?
N
|
|
From: Dimitri Papadopoulos-O. <pap...@sh...> - 2003-11-19 07:48:08
|
Hi,
> I got this report from a valgrind user. He found this bug in later versions
> of valgrind (>> 20031012). Is this information enough to solve the problem
> or may I ask the user for further information?
Just a few remarks:
> $ valgrind ./kmagui
> [...]
> ==3546== at 0x49ECDBB8: (within /usr/lib/libGL.so.1.0.4496)
> [...]
This is the latest NVidia driver. It has been reported that NVidia
drivers require __GL_FORCE_GENERIC_CPU be set for lack of MMX, SSE, or
3DNOW! support in Valgrind (see FAQ). I don't know if that's still the
case with curent version of Valgrind. Try setting this variable.
Maybe it would be worth trying on a machine without NVidia drivers, just
to test whether this is related to NVidia drivers.
> ==3546== Syscall param modify_ldt(ptr)(func=1 or 0x11) contains
uninitialised or unaddressable byte(s)
I don't understand this error message. I'd like to suggest rewriting it
using plain English, so that casual users can understand what's
happenning. I suspect many power users on this mailing list do
understand this message, but other programers just don't understand what
this means (that's the case at my place):
modify_ldt(ptr)(func=1 or 0x11)
> ==3546== Conditional jump or move depends on uninitialised value(s)
Again, some programers just wonder what this error message means. I
guess that it has to do with code looking like
if ( variable ) {
[...]
where "variable" isn't initialised. Again maybe this error message could
be rewritten using simple words, if at all possible.
Finally it's a pity there's no searchable archive for this mailing list.
--
Dimitri
|
|
From: Dirk M. <dm...@gm...> - 2003-11-19 01:02:54
|
On Tuesday 18 November 2003 11:46, Josef Weidendorfer wrote: > The sycall 218 seems to be in a handler for illegal instructions ?!? its "mincore", which is apparently used somewhere in the cleanup process for abort() (??) > Proposed patch (it is working, but I really don't know what I am doing looks good to me, please commit. |
|
From: Tyler N. <tyl...@co...> - 2003-11-18 20:23:43
|
On Tue, 2003-11-18 at 01:42, Nicholas Nethercote wrote: > On Mon, 17 Nov 2003, Tyler Nielsen wrote: > > It would be quite easy to add support for prefetchw to > coregrind/vg_to_ucode.c, since you can just ignore the instruction and not > generate any UCode for it. That won't help you much if your program uses > other 3dNow! instructions. Can you remove them from your program, eg. by > compiling with different options? > Thanks for the help, I'll try to remove the 3dNow instructions. Tyler |
|
From: <ar...@de...> - 2003-11-18 18:56:06
|
Hi all. I got this report from a valgrind user. He found this bug in later versions of valgrind (>> 20031012). Is this information enough to solve the problem or may I ask the user for further information? Regards. |
|
From: Paul H. <pa...@ha...> - 2003-11-18 18:06:34
|
On Tue, 18 Nov 2003, Lee Kindness wrote: > Hi, > The attached test case results in different output when run under > Valgrind (version 2.0 & 1.9.6) compared to when it is run > stand-alone. This source makes use of nested functions. Most importantly, it makes use of 2 functions named "sel". And it is confusing them. Hmm, further experiments show that the bug persists if one of the sel()s is renamed. > The following is output when run normally: > % ./hmmlk 1 2 > bob is odd > bob is NOT even I added fprintf(stdout,"sel1\n"); to the first sel, and fprintf(stdout,"sel2\n"); to the second sel. Here is my output: sel1 bob is odd sel2 bob is NOT even > and when run under Valgrind (I've also attached verbose output): > > % valgrind ./hmmlk 1 2 > bob is odd > bob is even sel1 bob is odd sel1 bob is even > This source was compiled with GGC 3.2: > > gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5) > > without optimisation. > Has anyone else encountered this problem, or have any ideas on how to > get Valgrind to report the same results? Or is this a GCC bug? Don't nest the functions and it just works. > Thanks in advance, Lee Kindness. -- Paulh |
|
From: Lee K. <lki...@cs...> - 2003-11-18 16:10:16
|
Hi, The attached test case results in different output when run under Valgrind (version 2.0 & 1.9.6) compared to when it is run stand-alone. This source makes use of nested functions. The following is output when run normally: % ./hmmlk 1 2 bob is odd bob is NOT even and when run under Valgrind (I've also attached verbose output): % valgrind ./hmmlk 1 2 bob is odd bob is even This source was compiled with GGC 3.2: gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5) without optimisation. Has anyone else encountered this problem, or have any ideas on how to get Valgrind to report the same results? Or is this a GCC bug? Thanks in advance, Lee Kindness. |
|
From: Josef W. <Jos...@gm...> - 2003-11-18 10:46:19
|
Hi,
with code compiled with Intels Fortran compiler, I get
=============================================
disInstr: unhandled instruction bytes: 0x66 0xF 0x5A 0xC0
** Illegal Instruction **
--2913-- FATAL: unhandled syscall: 218
=============================================
The sycall 218 seems to be in a handler for illegal instructions ?!?
This is "cvtpd2ps %xmm0,%xmm0". The instruction is from
the SSE version of logf(), symbol "__libm_sse2_logf".
Proposed patch (it is working, but I really don't know what I am doing here):
=============================================================
--- vg_to_ucode.c.orig 2003-11-18 11:10:08.000000000 +0100
+++ vg_to_ucode.c 2003-11-18 11:38:06.000000000 +0100
@@ -4742,6 +4742,14 @@ static Addr disInstr ( UCodeBlock* cb, A
goto decode_success;
}
+ /* CVTPD2PS -- convert one doubles to floats. */
+ if (sz == 2 &&
+ insn[0] == 0x0F && insn[1] == 0x5A) {
+ eip = dis_SSE3_reg_or_mem ( cb, sorb, eip+2, 16, "cvtpd2ps",
+ 0x66, insn[0], insn[1] );
+ goto decode_success;
+ }
+
/* SQRTPD: square root of packed double. */
if (sz == 2
&& insn[0] == 0x0F && insn[1] == 0x51) {
==================================================
Cheers,
Josef
|
|
From: Nicholas N. <nj...@ca...> - 2003-11-18 08:42:29
|
On Mon, 17 Nov 2003, Tyler Nielsen wrote: > > prefetchw - that's an AMD 3dnow! instruction right? I think it's a bug > > in your distro if it's using 3dnow instructions on a CPU which doesn't > > claim to support them (unless, of course, we are claiming to do so > > accidentally). What's your CPU? > > > I think my CPU supports them. I have an AMD Athlon XP 2600+. I just > figured valgrind doesn't know what to do with the command. Yes. Valgrind doesn't support any 3dNow! instructions, because they're not used very much. I don't think Valgrind does any kind of checking for 3dNow! support. It would be quite easy to add support for prefetchw to coregrind/vg_to_ucode.c, since you can just ignore the instruction and not generate any UCode for it. That won't help you much if your program uses other 3dNow! instructions. Can you remove them from your program, eg. by compiling with different options? N |
|
From: Dirk M. <dm...@gm...> - 2003-11-18 03:46:05
|
On Monday 17 November 2003 14:57, Jim Meyering wrote: > P.S., I did register with KDE bugzilla and then tried to report > via that, but when I hit the `commit' button, it failed. Sigh. > I reported _that_ to the indicated address. There was a small bug, fixed now. |
|
From: Tyler N. <tyl...@co...> - 2003-11-18 02:38:31
|
On Mon, 2003-11-17 at 18:05, Jeremy Fitzhardinge wrote: > On Mon, 2003-11-17 at 16:48, Tyler Nielsen wrote: > > disInstr: unhandled instruction bytes: 0xF 0xD 0x8A 0x80 > > Illegal instruction > > > > I'm not to good at this, but I think it's the prefetchw command. Any > > idea how difficult this is to implement? > > prefetchw - that's an AMD 3dnow! instruction right? I think it's a bug > in your distro if it's using 3dnow instructions on a CPU which doesn't > claim to support them (unless, of course, we are claiming to do so > accidentally). What's your CPU? > > J > I think my CPU supports them. I have an AMD Athlon XP 2600+. I just figured valgrind doesn't know what to do with the command. cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 6 model : 8 model name : AMD Athlon(TM) XP 2600+ stepping : 1 cpu MHz : 2083.203 cache size : 256 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse syscall mmxext 3dnowext 3dnow bogomips : 4104.19 Tyler |
|
From: Jeremy F. <je...@go...> - 2003-11-18 01:42:50
|
On Mon, 2003-11-17 at 16:10, Tom Hughes wrote: > There can actually be mutiple TLS segments in the ELF file - there > are typically .tdata and .tbss from what I can see. There's both .tdata and .tbss sections, but they both get mapped to the one PT_TLS segment. > In fact only the base executable seems to use direct %gs references. For > example, when xxx is a thread local variables, this code: > > xxx++; [...] > The function being called is ___tls_get_addr and the lea is setting > up some sort of index into the TLS segment. Yep, ___tls_get_addr is a function defined by the ABI to exist so the compiler can call it. There are many different types of reloc possible, depending on how much static info the compiler/linker has (like whether the code accessing the variable is necessarily in the same shared object or not). tls.pdf goes into (vast) detail about it. > Even the cloning is hard because although we have the pointer to > the thread area for the original thread we have no idea how big > that area is because ld.so seems to set it up with a size of -1 so > the area is effectively unlimited. Well, if we already have enough interaction with ld.so anyway, we can probably work out the size of the TLS chunk. I think it is sizeof(tcbheader_t). And clone() doesn't copy anything; it just sets up a new thread area at the given address, which libpthread points to its struct pthread. > In fact I believe the address passed to the kernel as the thread > area pointer is a pointer to the thread descriptor structure, with > the TLS data for the main executable just below it so that negative > offsets from %gs will find it. Other TLS data is found from the > thread descriptor somehow by the __tls_get_addr function. Yup, the ABI says something like that. But it is also part of the thread stack, so I'm not quite sure how much stuff is there. ___tls_get_addr is designed to hide a fair amount of the detail, and the compiler isn't allowed to make too many assumptions. > Trying to emulate the whole thing would be horrible, but given > the incestuous links between ld.so, libc and libpthread it's hard > to see how else it can be done. It would also be a maintenance > nightmare of course, as you say. Yes. It might be the only really sane way of doing it is to get some officially sanctioned hooks into glibc so that we can get enough information without too much interdependence. > I don't think they do make do without it, which is why valgrind > falls over if you try and load any program or library with a TLS > section in the ELF file. Setting LD_ASSUME_KERNEL causes ld.so to > use a glibc built without using TLS segments. Does that mean that code using TLS just SEGVs on a pre-TLS kernel? J |