valgrind-users — General discussion list for Valgrind users

Re: [Valgrind-users] helgrind and c++ atomic_flag

[Tom H. <to...@co...>]

On 25/09/2018 05:44, John Perry wrote:

> When run in helgrind, the C++ example programs at
> 
>      en.cppreference.com/w/cpp/atomic/atomic_flag
> 
> and
> 
>      www.cplusplus.com/reference/atomic/atomic_flag/
> 
> report a bunch of possible data races. For instance,
> 
>      ==24483== Possible data race during read of size 1 at 0x6051F1 by
>      thread #3
>      ==24483== Locks held: none
>      ==24483==    at 0x400E8F: test_and_set (atomic_base.h:176)
>      ==24483==    by 0x400E8F: f(int) (helgrind_spinlock2.cpp:11)
>      ...
>      ==24483== This conflicts with a previous write of size 1 by thread
>      #2
>      ==24483== Locks held: none
>      ==24483==    at 0x400EE6: clear (atomic_base.h:193)
>      ==24483==    by 0x400EE6: f(int) (helgrind_spinlock2.cpp:14)
> 
> Is it correct to conclude that these are false positives? I found a
> lot of discussion in the mailing list on atomic operations but nothing
> "recent" seemed to address the C++ standard library.

I don't believe helgrind makes any attempt to observe atomic
operations so it is entirely unaware of them and of any effect
they might have on the thread correctness of a program.

It would be hard to do because where the compiler is able to
generate direction instructions for the atomic there will be no
function call to intercept, and as there won't necessarily be a
one-one mapping from atomic operations to CPU instructions it
is hard to determine what the original operation was by
observing the instruction stream.

Tom

-- 
Tom Hughes (to...@co...)
http://compton.nu/

[Valgrind-users] helgrind and c++ atomic_flag

[John P. <Joh...@us...>]

Hello!

When run in helgrind, the C++ example programs at

    en.cppreference.com/w/cpp/atomic/atomic_flag

and

    www.cplusplus.com/reference/atomic/atomic_flag/

report a bunch of possible data races. For instance,

    ==24483== Possible data race during read of size 1 at 0x6051F1 by
    thread #3
    ==24483== Locks held: none
    ==24483==    at 0x400E8F: test_and_set (atomic_base.h:176)
    ==24483==    by 0x400E8F: f(int) (helgrind_spinlock2.cpp:11)
    ...
    ==24483== This conflicts with a previous write of size 1 by thread
    #2
    ==24483== Locks held: none
    ==24483==    at 0x400EE6: clear (atomic_base.h:193)
    ==24483==    by 0x400EE6: f(int) (helgrind_spinlock2.cpp:14)

Is it correct to conclude that these are false positives? I found a
lot of discussion in the mailing list on atomic operations but nothing
"recent" seemed to address the C++ standard library.

regards
john perry

-- 
John Perry, PhD + Associate Professor of Mathematics
Undergraduate Program Lead, Mathematics BS
University of Southern Mississippi
School of Physical and Metaphysical Sciences
(i.e., School of Mathematics and Natural Sciences)


Contrariwise, if it was so, it might be, and if it were so, it would
be, but as it isn't, it ain't. That's logic. -- Tweedledee, Through the
Looking Glass

Re: [Valgrind-users] Callgrind complains about debug symbols missing

[Alexander B. <ale...@lu...>]

On 9/17/18 11:31 PM, Philippe Waroquiers wrote:
> If you have a small reproducer, you might look at the last comment
> of the bug https://bugs.kde.org/show_bug.cgi?id=398028
> and attach the traces with the suggested debug switches.

The smallest reproducer I could come up with is a cpp file with only a
main function linked to openblas. I tried to stuff all relevant
information in the comments to the bug report, does it reproduce?

Alexander

Re: [Valgrind-users] Callgrind complains about debug symbols missing

[Philippe W. <phi...@sk...>]

On Mon, 2018-09-17 at 22:14 +0200, Alexander Brock wrote:
> On 9/17/18 7:26 PM, Julian Seward wrote:
> > > valgrind: m_debuginfo/debuginfo.c:738 (check_CFSI_related_invariants):
> > > Assertion 'cfsi_fits' failed.
> > 
> > Is that really still failing?  I thought that got comprehensively fixed
> > in the past few weeks.  Can you re-try?
We had a problem with all Qt applications, failing with
  Bug 393146 - failing assert "is_DebugInfo_active(di)" 
which is (I believe) fully fixed.

However, this cfsi_fits failing looks to be something different,
i.e. the (not yet fixed) bug  :
  Bug 398028 - Assertion `csfi_fits` failing in simple C program with embedded Julia code. 

(I guess it might be related to using a newer gcc, or a newer glibc,
or something else new, seeing the versions reported).

If you have a small reproducer, you might look at the last comment
of the bug https://bugs.kde.org/show_bug.cgi?id=398028
and attach the traces with the suggested debug switches.

That might help to see (guess) what is wrong.

Thanks

Philippe

> 
> I ran "git pull" (no new commits, latest commit is
> 97365bada64c27a40004c55793ff8988e59adf35) and re-tried with a couple of
> executables in my project, each fail:
> 
> http://paste.debian.net/1043013/
> 
> It doesn't matter if I use callgrind or memcheck, here is the output for
> memcheck:
> 
> http://paste.debian.net/1043014/
> 
> Alexander
> 
> 
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Callgrind complains about debug symbols missing

[Alexander B. <ale...@lu...>]

On 9/17/18 7:26 PM, Julian Seward wrote:
>> valgrind: m_debuginfo/debuginfo.c:738 (check_CFSI_related_invariants):
>> Assertion 'cfsi_fits' failed.
> 
> Is that really still failing?  I thought that got comprehensively fixed
> in the past few weeks.  Can you re-try?

I ran "git pull" (no new commits, latest commit is
97365bada64c27a40004c55793ff8988e59adf35) and re-tried with a couple of
executables in my project, each fail:

http://paste.debian.net/1043013/

It doesn't matter if I use callgrind or memcheck, here is the output for
memcheck:

http://paste.debian.net/1043014/

Alexander

Re: [Valgrind-users] Callgrind complains about debug symbols missing

[Julian S. <js...@ac...>]

On 17/09/18 18:15, Alexander Brock wrote:

> valgrind: m_debuginfo/debuginfo.c:738 (check_CFSI_related_invariants):
> Assertion 'cfsi_fits' failed.

Is that really still failing?  I thought that got comprehensively fixed
in the past few weeks.  Can you re-try?

J

[Valgrind-users] Callgrind complains about debug symbols missing

[Alexander B. <ale...@lu...>]

Hi,

I have a large, complex, non-public project where I used to identify
performance issues using callgrind (via QtCreator) but that stopped
working. Now I don't get any function names, instead I get
"0x00000123456789" or similar.

I created a very simple project and it still doesn't work as expected.
You can find the project here:

https://github.com/abrock/callgrind-test

I build it like this:
g++ -g main.cpp

and run it like this:
valgrind --tool=callgrind ./a.out

which gives me this output:
==8960== Callgrind, a call-graph generating cache profiler
==8960== Copyright (C) 2002-2017, and GNU GPL'd, by Josef Weidendorfer
et al.
==8960== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==8960== Command: ./a.out
==8960==
==8960== For interactive control, run 'callgrind_control -h'.
Hello World!
The sum is: 499999500000
The sum is: 49995000
==8960==
==8960== Events    : Ir
==8960== Collected : 14374235
==8960==
==8960== I   refs:      14,374,235

Then I run kcachegrind:
kcachegrind callgrind.out.8960

which gives me this result:
https://imgur.com/a/anljbAL

It shows the two trees for the two functions with different runtimes as
expected, but no function names and complains about missing debug
symbols and doesn't seem to know the name of the executable.

This is my g++ version:
g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/8/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 8.2.0-6'
--with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++
--prefix=/usr --with-gcc-major-version-only --program-suffix=-8
--program-prefix=x86_64-linux-gnu- --enable-shared
--enable-linker-build-id --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --libdir=/usr/lib
--enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin
--enable-default-pie --with-system-zlib --with-target-system-zlib
--enable-objc-gc=auto --enable-multiarch --disable-werror
--with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 8.2.0 (Debian 8.2.0-6)

I'm out of ideas, did I do something wrong? Feels like I missed
something totally obvious.

I tried the git version of valgrind which works as expected for the
simple test program but crashes for my large project:

valgrind: m_debuginfo/debuginfo.c:738 (check_CFSI_related_invariants):
Assertion 'cfsi_fits' failed.

host stacktrace:
==24946==    at 0x58022AB4: show_sched_status_wrk (m_libcassert.c:369)
==24946==    by 0x58022BC7: report_and_quit (m_libcassert.c:440)
==24946==    by 0x58022D59: vgPlain_assert_fail (m_libcassert.c:506)
==24946==    by 0x58049F7F: vgPlain_di_notify_mmap (debuginfo.c:738)
==24946==    by 0x5807A96B: vgModuleLocal_generic_PRE_sys_mmap
(syswrap-generic.c:2402)
==24946==    by 0x5808640F: vgSysWrap_amd64_linux_sys_mmap_before
(syswrap-amd64-linux.c:404)
==24946==    by 0x58076081: vgPlain_client_syscall (syswrap-main.c:1863)
==24946==    by 0x58072C1A: handle_syscall (scheduler.c:1176)
==24946==    by 0x580744D6: vgPlain_scheduler (scheduler.c:1498)
==24946==    by 0x580D5330: run_a_thread_NORETURN (syswrap-linux.c:103)

sched status:
  running_tid=1

Thread 1: status = VgTs_Runnable syscall 9 (lwpid 24946)
==24946==    at 0x401A693: mmap (mmap64.c:52)
==24946==    by 0x40060AD: _dl_map_object_from_fd (dl-map-segments.h:94)
==24946==    by 0x400890E: _dl_map_object (dl-load.c:2461)
==24946==    by 0x400D061: openaux (dl-deps.c:63)
==24946==    by 0x401950A: _dl_catch_exception (dl-error-skeleton.c:196)
==24946==    by 0x400D2F2: _dl_map_object_deps (dl-deps.c:249)
==24946==    by 0x4003D95: dl_main (rtld.c:1726)
==24946==    by 0x401862F: _dl_sysdep_start (dl-sysdep.c:253)
==24946==    by 0x40020D7: _dl_start (rtld.c:414)
==24946==    by 0x4001217: ??? (in /lib/x86_64-linux-gnu/ld-2.27.so)
client stack range: [0x1FFEFFE000 0x1FFF000FFF] client SP: 0x1FFEFFE258
valgrind stack range: [0x1002A8E000 0x1002B8DFFF] top usage: 16248 of
1048576

Best Regards,
Alexander

Re: [Valgrind-users] Valgrind seems to give false "Invalid read" positive with vsnprintf

[Mohamed B. <moh...@wa...>]

Hi Tom,

Indeed, I overlooked this.

Thanks for the help!

On Mon, 17 Sep 2018 at 12:24, Tom Hughes <to...@co...> wrote:

> On 17/09/2018 10:16, Mohamed BELAOUAD wrote:
>
> > I seem to have encountered a false positive with valgrind-3.13.0 with
> > the program below.
> > https://pastebin.com/XPHsM2sF
> >
> > Valgrind gives "invalid read" errors show the following pastebin:
> > https://pastebin.com/a4vzNMvW.
> >
> > The error is reported during the second call to w_strdup_printf on
> > address of string a (which is created during the first call).
> > If I uncomment the printf calls, the errors disappear. If I move free(a)
> > next to free(b), the errors also disappear.
> >
> > I am not sure if I am missing something in my program or if those are
> > real false positives.
>
> You have used ap twice, the second time after va_end.
>
> I think you meant to pass ap_copy to the vsnprintf calls (and to
> the va_end calls).
>
> Tom
>
> --
> Tom Hughes (to...@co...)
> http://compton.nu/
>

Re: [Valgrind-users] Valgrind seems to give false "Invalid read" positive with vsnprintf

[Tom H. <to...@co...>]

On 17/09/2018 10:16, Mohamed BELAOUAD wrote:

> I seem to have encountered a false positive with valgrind-3.13.0 with 
> the program below.
> https://pastebin.com/XPHsM2sF
> 
> Valgrind gives "invalid read" errors show the following pastebin: 
> https://pastebin.com/a4vzNMvW.
> 
> The error is reported during the second call to w_strdup_printf on 
> address of string a (which is created during the first call).
> If I uncomment the printf calls, the errors disappear. If I move free(a) 
> next to free(b), the errors also disappear.
> 
> I am not sure if I am missing something in my program or if those are 
> real false positives.

You have used ap twice, the second time after va_end.

I think you meant to pass ap_copy to the vsnprintf calls (and to
the va_end calls).

Tom

-- 
Tom Hughes (to...@co...)
http://compton.nu/

[Valgrind-users] Valgrind seems to give false "Invalid read" positive with vsnprintf

[Mohamed B. <moh...@wa...>]

Hi all,

I seem to have encountered a false positive with valgrind-3.13.0 with the
program below.
https://pastebin.com/XPHsM2sF

Valgrind gives "invalid read" errors show the following pastebin:
https://pastebin.com/a4vzNMvW.

The error is reported during the second call to w_strdup_printf on address
of string a (which is created during the first call).
If I uncomment the printf calls, the errors disappear. If I move free(a)
next to free(b), the errors also disappear.

I am not sure if I am missing something in my program or if those are real
false positives.
I would appreciate any help!

Thanks & Best Regards,
Mohamed

Re: [Valgrind-users] Warning: client switching stacks due to inline asm

[Julian S. <js...@ac...>]

On 10/09/18 06:34, Jeffrey Walton wrote:

> I believe the warnings are due to one of two things. The first use is
> inline asm adjusting the stack pointer for SSE operations.

I doubt it.

> The second use case is using sp as a general purpose register.

Sounds plausible.  But is it safe?  What happens if a signal arrives
whilst esp has some value that isn't a valid stack?

J

[Valgrind-users] Warning: client switching stacks due to inline asm

[Jeffrey W. <nol...@gm...>]

Hi Everyone,

(Sorry about the previous incomplete post). We are catching some
Valgrind warnings when testing 32-bit x86 code. The warnings are:

==4782== Warning: client switching stacks?  SP change: 0xbedc728c --> 0x4456a00
==4782==          to suppress, use: --max-stackframe=1164506996 or greater
==4782== Warning: client switching stacks?  SP change: 0x4456a00 --> 0xbedc728c
==4782==          to suppress, use: --max-stackframe=1164506996 or greater

Notice the former sp is restored.

I believe the warnings are due to one of two things. The first use is
inline asm adjusting the stack pointer for SSE operations. The second
use case is using sp as a general purpose register. For the warnings
above this triggers them (AS2 is a macro in the inline asm that allows
the code to work with GCC and MSVC):

    AS2( mov [ecx+16*12+16*4], esp)    // save esp to L_SP
    AS2( lea esp, [ecx-768])

I think I would like to annotate the code and tell Valgrind we are
adjusting the stack pointer so we get improved analysis rather than
disabling warnings or using some other cannon. I'm trying to avoid
--max-stackframe because it may mask a valid finding later.

Is it possible to inform Valgrind we are (1) moving the stack pointer
for this function/inline asm block; and (2) the stack pointer will be
restored when finished with the block?

Thanks in advance,

Jeff

[Valgrind-users] (no subject)

[Jeffrey W. <nol...@gm...>]

Hi Everyone,

We are catching some Valgrind warnings when testing 32-bit x86 code.
The warnings are:

Re: [Valgrind-users] Off-topic: what happended to bzip.org?

[Jeffrey W. <nol...@gm...>]

On Wed, Aug 29, 2018 at 3:48 PM, Mark Wielaard <ma...@kl...> wrote:
> Hi Jeffrey,
>
> Unfortunately the bzip.org domain is no longer available to the
> bzip2 project. The plan is to move back to sourceware:
> https://sourceware.org/bzip2/
> https://sourceware.org/pub/bzip2/
> And also setup a git repo, bugzilla, mailinglist, etc. for the project
> there. But not everything has moved yet. The homepage currently only has
> (very) old information available.

I'm kind of surprised, but the Wayback machine has this archived:
http://www.bzip.org/1.0.6/bzip2-1.0.6.tar.gz. I was able to download
it.

Jeff

Re: [Valgrind-users] Off-topic: what happended to bzip.org?

[Mark W. <ma...@kl...>]

Hi Jeffrey,

Unfortunately the bzip.org domain is no longer available to the
bzip2 project. The plan is to move back to sourceware:
https://sourceware.org/bzip2/
https://sourceware.org/pub/bzip2/
And also setup a git repo, bugzilla, mailinglist, etc. for the project
there. But not everything has moved yet. The homepage currently only has
(very) old information available.

Cheers,

Mark

Re: [Valgrind-users] Off-topic: what happended to bzip.org?

[Jeffrey W. <nol...@gm...>]

On Wed, Aug 29, 2018 at 3:48 PM, Mark Wielaard <ma...@kl...> wrote:
> Hi Jeffrey,
>
> Unfortunately the bzip.org domain is no longer available to the
> bzip2 project. The plan is to move back to sourceware:
> https://sourceware.org/bzip2/
> https://sourceware.org/pub/bzip2/
> And also setup a git repo, bugzilla, mailinglist, etc. for the project
> there. But not everything has moved yet. The homepage currently only has
> (very) old information available.

Thanks Mark.

A small suggestion...

Bzip should setup GitHub, GitLab, <favorite sc> accounts. Then the
project should add a README that points people to the new location.

The action serves two purposes. First, it disseminates information on
the new location. I went to GitHub looking when the original site was
not operational.

Second, it stops folks from squatting the Bzip name and distributing
who knows what.

Jeff

[Valgrind-users] Off-topic: what happended to bzip.org?

[Jeffrey W. <nol...@gm...>]

Hi Every,

Please forgive me for the off-topic question. I'm hoping Julian can
shed some light...

I have a script that fetches the latest bzip from
http://www.bzip.org/1.0.6/bzip2-1.0.6.tar.gz . The library is built
from sources because some GNU packages need it. The fetch has been
failing lately. Visiting bzip.org it looks like the site is no longer
operational.

Where can we find authentic sources for Bzip?

Jeff

[Valgrind-users] 转发: hi, there is a quesion about fp16 running in arm server

[Wuweijia <wuw...@hu...>]

Is there any guy help me to re-send to Mr. Andreas Pinkert ? I do not know his email address.

发件人: Zwinkau Andreas (CC-AD/ESW1) [mailto:And...@de...]
发送时间: 2018年8月28日 22:41
收件人: Wuweijia <wuw...@hu...>
主题: Automatische Antwort: hi, there is a quesion about fp16 running in arm server

Thank you for your message.

I am not in the office till September 9. Emails are not read and not forwarded until then. In case of need please contact Mr. Andreas Pinkert (CC-AD/ESW1).

Vielen Dank für Ihre Nachricht.

Ich bin bis 9. September nicht im Haus. Emails werden bis dann nicht gelesen und nicht weitergeleitet. In dringenden Fällen wenden Sie sich bitte an Herrn Andreas Pinkert (CC-AD/ESW1).


发件人: Wuweijia [mailto:wuw...@hu...]
发送时间: 2018年8月28日 22:40
收件人: val...@li...
抄送: Fanbohao <fan...@hu...>
主题: [Valgrind-users] hi, there is a quesion about fp16 running in arm server

Hi:
                I wrote the program running in the arm64 server. There is something difference with other program. I use fp16 to compute the result;
                The fp16 program can run successfully without valgrind.  But with valgrind,  it ran failed.

                There is call stack, and last word:


t135 = GET:F16(722)
vex: the `impossible' happened:
   iselStmt
vex storage: T total 4464272856 bytes allocated
vex storage: P total 0 bytes allocated

valgrind: the 'impossible' happened:
   LibVEX called failure_exit().

host stacktrace:
==2201==    at 0x380453C4: show_sched_status_wrk (m_libcassert.c:355)
==2201==    by 0x3804572B: report_and_quit (m_libcassert.c:426)
==2201==    by 0x380457CB: panic (m_libcassert.c:502)
==2201==    by 0x3804576F: vgPlain_core_panic_at (m_libcassert.c:507)
==2201==    by 0x380457DB: vgPlain_core_panic (m_libcassert.c:512)
==2201==    by 0x38060C6B: failure_exit (m_translate.c:740)
==2201==    by 0x38109AAB: vpanic (main_util.c:231)
==2201==    by 0x3816C30F: iselStmt (host_arm64_isel.c:4003)
==2201==    by 0x3816A7DB: iselSB_ARM64 (host_arm64_isel.c:4201)
==2201==    by 0x38107D93: libvex_BackEnd (main_main.c:1047)
==2201==    by 0x38107D93: LibVEX_Translate (main_main.c:1174)
==2201==    by 0x38060A23: vgPlain_translate (m_translate.c:1794)
==2201==    by 0x38093F47: handle_chain_me (scheduler.c:1084)
==2201==    by 0x3809227F: vgPlain_scheduler (scheduler.c:0)
==2201==    by 0x380A0607: thread_wrapper (syswrap-linux.c:103)
==2201==    by 0x380A0607: run_a_thread_NORETURN (syswrap-linux.c:156)
==2201==    by 0x380A051F: vgModuleLocal_start_thread_NORETURN (syswrap-linux.c:320)
==2201==    by 0x380C2E37: ??? (in /system/lib64/valgrind/memcheck-arm64-linux)


        I check the code that valgrind analyze the instruction.

        In the Ist_WrTmp case, there is no statement to handle fp16 case.

        I want to know how to fixed the bug,  and support  fp16 type.


Host_arm64_isel.c   iselStmt function code as below:

   /* --------- TMP --------- */
   /* assign value to temporary */
   case Ist_WrTmp: {
      IRTemp tmp = stmt->Ist.WrTmp.tmp;
      IRType ty  = typeOfIRTemp(env->type_env, tmp);

      if (ty == Ity_I64 || ty == Ity_I32 || ty == Ity_I16 || ty == Ity_I8) {
         /* We could do a lot better here.  But for the time being: */
         HReg dst = lookupIRTemp(env, tmp);
         HReg rD  = iselIntExpr_R(env, stmt->Ist.WrTmp.data);
         addInstr(env, ARM64Instr_MovI(dst, rD));
         return;
      }
      if (ty == Ity_I1) {
         /* Here, we are generating a I1 value into a 64 bit register.
            Make sure the value in the register is only zero or one,
            but no other.  This allows optimisation of the
            1Uto64(tmp:I1) case, by making it simply a copy of the
            register holding 'tmp'.  The point being that the value in
            the register holding 'tmp' can only have been created
            here.  LATER: that seems dangerous; safer to do 'tmp & 1'
            in that case.  Also, could do this just with a single CINC
            insn. */
         /* CLONE-01 */
         HReg zero = newVRegI(env);
         HReg one  = newVRegI(env);
         HReg dst  = lookupIRTemp(env, tmp);
         addInstr(env, ARM64Instr_Imm64(zero, 0));
         addInstr(env, ARM64Instr_Imm64(one,  1));
         ARM64CondCode cc = iselCondCode(env, stmt->Ist.WrTmp.data);
         addInstr(env, ARM64Instr_CSel(dst, one, zero, cc));
         return;
      }
      if (ty == Ity_F64) {
         HReg src = iselDblExpr(env, stmt->Ist.WrTmp.data);
         HReg dst = lookupIRTemp(env, tmp);
         addInstr(env, ARM64Instr_VMov(8, dst, src));
         return;
      }
      if (ty == Ity_F32) {
         HReg src = iselFltExpr(env, stmt->Ist.WrTmp.data);
         HReg dst = lookupIRTemp(env, tmp);
         addInstr(env, ARM64Instr_VMov(8/*yes, really*/, dst, src));
         return;
      }
      if (ty == Ity_V128) {
         HReg src = iselV128Expr(env, stmt->Ist.WrTmp.data);
         HReg dst = lookupIRTemp(env, tmp);
         addInstr(env, ARM64Instr_VMov(16, dst, src));
         return;
      }
      if (ty == Ity_V256) {
         HReg srcHi, srcLo, dstHi, dstLo;
         iselV256Expr(&srcHi,&srcLo, env, stmt->Ist.WrTmp.data);
         lookupIRTempPair( &dstHi, &dstLo, env, tmp);
         addInstr(env, ARM64Instr_VMov(16, dstHi, srcHi));
         addInstr(env, ARM64Instr_VMov(16, dstLo, srcLo));
         return;
      }
      break;
   }

   /* --------- Call to DIRTY helper --------- */
   /* call complex ("dirty") helper function */
   case Ist_Dirty: {

valgrind vesoin 3.13.

BR
Owen

[Valgrind-users] hi, there is a quesion about fp16 running in arm server

[Wuweijia <wuw...@hu...>]

Hi:
                I wrote the program running in the arm64 server. There is something difference with other program. I use fp16 to compute the result;
                The fp16 program can run successfully without valgrind.  But with valgrind,  it ran failed.

                There is call stack, and last word:


t135 = GET:F16(722)
vex: the `impossible' happened:
   iselStmt
vex storage: T total 4464272856 bytes allocated
vex storage: P total 0 bytes allocated

valgrind: the 'impossible' happened:
   LibVEX called failure_exit().

host stacktrace:
==2201==    at 0x380453C4: show_sched_status_wrk (m_libcassert.c:355)
==2201==    by 0x3804572B: report_and_quit (m_libcassert.c:426)
==2201==    by 0x380457CB: panic (m_libcassert.c:502)
==2201==    by 0x3804576F: vgPlain_core_panic_at (m_libcassert.c:507)
==2201==    by 0x380457DB: vgPlain_core_panic (m_libcassert.c:512)
==2201==    by 0x38060C6B: failure_exit (m_translate.c:740)
==2201==    by 0x38109AAB: vpanic (main_util.c:231)
==2201==    by 0x3816C30F: iselStmt (host_arm64_isel.c:4003)
==2201==    by 0x3816A7DB: iselSB_ARM64 (host_arm64_isel.c:4201)
==2201==    by 0x38107D93: libvex_BackEnd (main_main.c:1047)
==2201==    by 0x38107D93: LibVEX_Translate (main_main.c:1174)
==2201==    by 0x38060A23: vgPlain_translate (m_translate.c:1794)
==2201==    by 0x38093F47: handle_chain_me (scheduler.c:1084)
==2201==    by 0x3809227F: vgPlain_scheduler (scheduler.c:0)
==2201==    by 0x380A0607: thread_wrapper (syswrap-linux.c:103)
==2201==    by 0x380A0607: run_a_thread_NORETURN (syswrap-linux.c:156)
==2201==    by 0x380A051F: vgModuleLocal_start_thread_NORETURN (syswrap-linux.c:320)
==2201==    by 0x380C2E37: ??? (in /system/lib64/valgrind/memcheck-arm64-linux)


        I check the code that valgrind analyze the instruction.

        In the Ist_WrTmp case, there is no statement to handle fp16 case.

        I want to know how to fixed the bug,  and support  fp16 type.


Host_arm64_isel.c   iselStmt function code as below:

   /* --------- TMP --------- */
   /* assign value to temporary */
   case Ist_WrTmp: {
      IRTemp tmp = stmt->Ist.WrTmp.tmp;
      IRType ty  = typeOfIRTemp(env->type_env, tmp);

      if (ty == Ity_I64 || ty == Ity_I32 || ty == Ity_I16 || ty == Ity_I8) {
         /* We could do a lot better here.  But for the time being: */
         HReg dst = lookupIRTemp(env, tmp);
         HReg rD  = iselIntExpr_R(env, stmt->Ist.WrTmp.data);
         addInstr(env, ARM64Instr_MovI(dst, rD));
         return;
      }
      if (ty == Ity_I1) {
         /* Here, we are generating a I1 value into a 64 bit register.
            Make sure the value in the register is only zero or one,
            but no other.  This allows optimisation of the
            1Uto64(tmp:I1) case, by making it simply a copy of the
            register holding 'tmp'.  The point being that the value in
            the register holding 'tmp' can only have been created
            here.  LATER: that seems dangerous; safer to do 'tmp & 1'
            in that case.  Also, could do this just with a single CINC
            insn. */
         /* CLONE-01 */
         HReg zero = newVRegI(env);
         HReg one  = newVRegI(env);
         HReg dst  = lookupIRTemp(env, tmp);
         addInstr(env, ARM64Instr_Imm64(zero, 0));
         addInstr(env, ARM64Instr_Imm64(one,  1));
         ARM64CondCode cc = iselCondCode(env, stmt->Ist.WrTmp.data);
         addInstr(env, ARM64Instr_CSel(dst, one, zero, cc));
         return;
      }
      if (ty == Ity_F64) {
         HReg src = iselDblExpr(env, stmt->Ist.WrTmp.data);
         HReg dst = lookupIRTemp(env, tmp);
         addInstr(env, ARM64Instr_VMov(8, dst, src));
         return;
      }
      if (ty == Ity_F32) {
         HReg src = iselFltExpr(env, stmt->Ist.WrTmp.data);
         HReg dst = lookupIRTemp(env, tmp);
         addInstr(env, ARM64Instr_VMov(8/*yes, really*/, dst, src));
         return;
      }
      if (ty == Ity_V128) {
         HReg src = iselV128Expr(env, stmt->Ist.WrTmp.data);
         HReg dst = lookupIRTemp(env, tmp);
         addInstr(env, ARM64Instr_VMov(16, dst, src));
         return;
      }
      if (ty == Ity_V256) {
         HReg srcHi, srcLo, dstHi, dstLo;
         iselV256Expr(&srcHi,&srcLo, env, stmt->Ist.WrTmp.data);
         lookupIRTempPair( &dstHi, &dstLo, env, tmp);
         addInstr(env, ARM64Instr_VMov(16, dstHi, srcHi));
         addInstr(env, ARM64Instr_VMov(16, dstLo, srcLo));
         return;
      }
      break;
   }

   /* --------- Call to DIRTY helper --------- */
   /* call complex ("dirty") helper function */
   case Ist_Dirty: {


valgrind vesoin 3.13.

BR
Owen

Re: [Valgrind-users] About how to get the guest code memory

[Philippe W. <phi...@sk...>]

On Mon, 2018-08-20 at 17:44 +0800, shuai xi wrote:
> Hi@all, 
> 
> I add some hooks in the vgpreload*.so and get some information from it. The vgpreload*.so is a dynamically library  loaded in the guest code.
> 
> I want to get this information to do some analysis. But i don't know how to get this information from guest code memory to valgrind memory space. 
> 
> I attempt to use a global variable to store this information, but valgrind show me a error that it can not find this global variable's symbol. Because this global variable is in guest code memory space.
> 
> I attempt to write this information in file, because i hook the function malloc. 
> 
> Is there some solution like 'share memory' to deal this problem？
You have to switch from guest to host.
I suggest you read in depth how a (non toy) tool works
(for example, how helgrind wraps pthread functions and
"calls" some host code from the guest code).

Philippe

[Valgrind-users] About how to get the guest code memory

[shuai xi <aha...@gm...>]

Hi@all,

I add some hooks in the vgpreload*.so and get some information from it. The
vgpreload*.so is a dynamically library  loaded in the guest code.

I want to get this information to do some analysis. But i don't know how to
get this information from guest code memory to valgrind memory space.

I attempt to use a global variable to store this information, but valgrind
show me a error that it can not find this global variable's symbol. Because
this global variable is in guest code memory space.

I attempt to write this information in file, because i hook the function
malloc.

Is there some solution like 'share memory' to deal this problem？

Very Thanks
Xi shuai

Re: [Valgrind-users] how to change the a register value of guest code in dirty call

[Tom H. <to...@co...>]

On 17/08/18 10:11, shuai xi wrote:

> Follow the memcheck's code, i insert a dirty call in IRSB. Now i want to 
> get and change a register(like rax) value in this dirty call.
> 
> In vex , Register often shows as 't19 = GET:I64(16)'  or 'PUT(16) = t22'.
> 
> Can i get the register's real address and change its value by the num 16?
> 
> i read the code of vex's translate. I seems that there has no global 
> values to store this information. Is there some ways to get this value?

Look at the amd64g_dirtyhelper_CPUID_* helpers as an example
of something that does this.

They are given a guest state pointer as the first argument
and that state contains the register values. The IR is built
so as to pass that pointer as the argument to the helper.

Alternatively I think the helper can just return a value
and then you can construct IR that will save the returned
value to a register.

Tom

-- 
Tom Hughes (to...@co...)
http://compton.nu/

[Valgrind-users] how to change the a register value of guest code in dirty call

[shuai xi <aha...@gm...>]

Hello @all,

Follow the memcheck's code, i insert a dirty call in IRSB. Now i want to
get and change a register(like rax) value in this dirty call.

In vex , Register often shows as 't19 = GET:I64(16)'  or 'PUT(16) = t22'.

Can i get the register's real address and change its value by the num 16?

i read the code of vex's translate. I seems that there has no global values
to store this information. Is there some ways to get this value?

Very Thanks!!
Shuai xi

[Valgrind-users] how to change tmp value in dirty call

[shuai xi <aha...@gm...>]

Hi@all,

I am trying to develop a valgrind tool base on memcheck.

Now i can get a shadow tmp id in memcheck's dirty call but i don't know how
to change this tmp's value. Can i change or get this tmp's value by this
id? Is there any Valgrind's API can do this?

Thanks
Shuai xi

Re: [Valgrind-users] About wrapper

[Philippe W. <phi...@sk...>]

The below wrapping functions must be in code which is part
of the guest code. That can be either directly in the guest
program/libraries, or alternatively in a valgrind preloaded
lib.
The assert below indicates that the address of the provided
wrapping function is not a valid guest address (because
it will be a piece of code part of valgrind itself).

The best is to follow the framework/structure like
what is done by existing tools.

Philippe

On Mon, 2018-07-30 at 12:13 +0800, shuai xi wrote:
> Hello developers:
> I want to write a tool for valgrind base on memcheck. I use the  '_WRAP_ macros' to wrap malloc in libc, but there show me an error:
> 
> valgrind: m_redir.c:638 (vgPlain_redir_notify_new_DebugInfo): Assertion 'is_plausible_guest_addr(sym_avmas.main)' failed.
> Segmentation fault (core dumped)
> 
> The code i add to 'mc_main.c' is:
> long I_WRAP_SONAME_FNNAME_ZU(libcZdsoZd6,malloc) ( long n )
> {
>    char *  r;
>    OrigFn fn;
>    VALGRIND_GET_ORIG_FN(fn);
>    CALL_FN_W_W(r, fn, n);
>    //cloak_malloc_addr = r;
>    return r;
> }
> 
> (I has already disable the malloc replacement by deleting vgpreload_memcheck-amd64-linux.so.)
> 
> Thanks
> 
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users