[fpc-devel] According to Valgrind, something is wrong in IndexByte
Jan Ruzicka
jan.ruzicka at comcast.net
Sun Aug 14 01:22:25 CEST 2005
On Aug 13, 2005, at 10:41, Micha Nelissen wrote:
> On Sat, 13 Aug 2005 00:03:01 -0400
> Jan Ruzicka <jan.ruzicka at comcast.net> wrote:
>
>> On Aug 12, 2005, at 05:04, Micha Nelissen wrote:
>>
>>> But if I use my own version (which I use for delphi and is i386
>>> specific), it reports no errors in this location, for
>>> Dbf_Common/Dbf_Memo.
>>>
>>> i386 IndexByte seems way more complex than my custom MemScan, but
>>> maybe that's necessary somehow.
>>
>> Have you investigated more into the Valgrind behavior?
>> The jump (JNE @@1) is reacting to "REPNE SCASB" and all values
>> seem
>> to be defined.
>> Valgrind may be expecting some numerical operation to set the flags.
>> "Flags Affected: None; however, the CMPS and SCAS instructions do set
>> the status flags in the EFLAGS register."
>
> Hmm is your point that valgrind should detect an error in my "REPNE
> SCASB" ?
No. Sorry did not read the original post carefully enough.
My understanding was that the assembler portion was causing valgrind to
complain.
Now I finally got it. You were pointing out possible problem in
System.IndexByte(Buffer, Length, Chr);
The valgrind message is really strange, because the IndexByte function
is really similar to one you advised.
The svn version has this in rtl/i386/i386.inc
297 function IndexByte(Const buf;len:SizeInt;b:byte):SizeInt;
assembler;
298 var
299 saveedi,saveebx : longint;
300 asm
301 movl %edi,saveedi
302 movl %ebx,saveebx
303 movl buf,%edi // Load String
304 movb b,%bl
305 movl len,%ecx // Load len
306 xorl %eax,%eax
307 testl %ecx,%ecx
308 jz .Lcharposnotfound
309 cld
310 movl %ecx,%edx // Copy for easy manipulation
311 movb %bl,%al
312 repne
313 scasb
314 jne .Lcharposnotfound
315 incl %ecx
316 subl %ecx,%edx
317 movl %edx,%eax
318 jmp .Lready
319 .Lcharposnotfound:
320 movl $-1,%eax
321 .Lready:
322 movl saveedi,%edi
323 movl saveebx,%ebx
324 end;
>
> I am not familiar with the internals of valgrind, so to conclude from
> 1 hour valgrind-experience that valgrind is faulty would be a little
> over the top IMHO..
Once again sorry for the misunderstanding.
Jan
More information about the fpc-devel
mailing list