valgrind-users — General discussion list for Valgrind users

Re: [Valgrind-users] PowerPC undefined symbol _restgpr_30_x

[Alan C. <ala...@gm...>]

Those happen, don't take it personally.  They used to be real common
in ARM.  Sounds like you hit a code that's not covered.   Not that I'm
one that can add it.

See the "==466== Your program just tried to execute an instruction that Valgrind
==466== did not recognise." section of the error message.  OTOH
somewhere it looks like it jumped to a null.

On 3/22/20, MP <mx...@gm...> wrote:
> I'm trying to use Valgrind on an embedded PowerPC system but I'm
> getting the following errors:
>
> ./testprog: symbol lookup error:
> /usr/local/lib/valgrind/vgpreload_memcheck-ppc32-linux.so: undefined
> symbol: _restgpr_30_x
> disInstr(ppc): unhandled instruction: 0x0
>                  primary 0(0x0), secondary 0(0x0)
> ==466== valgrind: Unrecognised instruction at address 0xffefa74.
> ==466==    at 0xFFEFA74: ??? (in
> /usr/local/lib/valgrind/vgpreload_core-ppc32-linux.so)
>
> The target setup is:
> CPU: MPC8280 (PowerPC 603e core)
> Linux Kernel 4.9.59
> gcc 6.3.0
> glibc 2.25
> valgrind 3.15.0
> The toolchain was generated using crosstool-NG 1.23 with a target of
> "powerpc-generic-linux-gnu".
>
> Test program is:
> int main (int argc, char **argv) { return argc; }
>
> It was compiled with:
> powerpc-generic-linux-gnu-gcc -o testprog testprog.c
>
> Valgrind was compiled like this:
> ./configure --host=powerpc-generic-linux-gnu
> make
>
> The full program output is as follows:
>
> # valgrind -v ./testprog
> ==466== Memcheck, a memory error detector
> ==466== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
> ==466== Using Valgrind-3.15.0-608cb11914-20190413 and LibVEX; rerun
> with -h for copyright info
> ==466== Command: ./testprog
> ==466==
> --466-- Valgrind options:
> --466--    -v
> --466-- Contents of /proc/version:
> --466--   Linux version 4.9.59 (build@engdev) (gcc version 6.3.0
> (crosstool-NG crosstool-ng-1.23.0) ) #0 PREEMPT Mon Mar 9 10:36:51 EDT
> 2020
> --466--
> --466-- Arch and hwcaps: PPC32, BigEndian, ppc32-int-flt-GX
> --466-- Page sizes: currently 4096, max supported 65536
> --466-- Valgrind library directory: /usr/local/lib/valgrind
> --466-- Reading syms from /lib/ld-2.25.so
> --466-- Reading syms from /tmp/testprog
> --466-- Reading syms from /usr/local/lib/valgrind/memcheck-ppc32-linux
> --466--    object doesn't have a dynamic symbol table
> --466-- Scheduler: using generic scheduler lock implementation.
> --466-- Reading suppressions file: /usr/local/lib/valgrind/default.supp
> ==466== embedded gdbserver: reading from
> /tmp/vgdb-pipe-from-vgdb-to-466-by-root-on-???
> ==466== embedded gdbserver: writing to
> /tmp/vgdb-pipe-to-vgdb-from-466-by-root-on-???
> ==466== embedded gdbserver: shared mem
> /tmp/vgdb-pipe-shared-mem-vgdb-466-by-root-on-???
> ==466==
> ==466== TO CONTROL THIS PROCESS USING vgdb (which you probably
> ==466== don't want to do, unless you know exactly what you're doing,
> ==466== or are doing some strange experiment):
> ==466==   /usr/local/lib/valgrind/../../bin/vgdb --pid=466 ...command...
> ==466==
> ==466== TO DEBUG THIS PROCESS USING GDB: start GDB like this
> ==466==   /path/to/gdb ./testprog
> ==466== and then give GDB the following command
> ==466==   target remote | /usr/local/lib/valgrind/../../bin/vgdb --pid=466
> ==466== --pid is optional if only one valgrind process is running
> ==466==
> --466-- REDIR: 0x401b250 (ld.so.1:strcmp) redirected to 0x58116d7c
> (vgPlain_ppc32_linux_REDIR_FOR_strcmp)
> --466-- REDIR: 0x401b3b4 (ld.so.1:strlen) redirected to 0x58116d54
> (vgPlain_ppc32_linux_REDIR_FOR_strlen)
> --466-- REDIR: 0x401b174 (ld.so.1:index) redirected to 0x58116df0
> (vgPlain_ppc32_linux_REDIR_FOR_strchr)
> --466-- Reading syms from
> /usr/local/lib/valgrind/vgpreload_core-ppc32-linux.so
> --466-- Reading syms from
> /usr/local/lib/valgrind/vgpreload_memcheck-ppc32-linux.so
> --466-- REDIR: 0x401bec8 (ld.so.1:memcpy) redirected to 0xffba7e8 (memcpy)
> --466-- REDIR: 0x401b820 (ld.so.1:bcmp) redirected to 0xffbb8c4 (bcmp)
> --466-- Reading syms from /lib/libc-2.25.so
> ./testprog: symbol lookup error:
> /usr/local/lib/valgrind/vgpreload_memcheck-ppc32-linux.so: undefined
> symbol: _restgpr_30_x
> disInstr(ppc): unhandled instruction: 0x0
>                  primary 0(0x0), secondary 0(0x0)
> ==466== valgrind: Unrecognised instruction at address 0xffefa74.
> ==466==    at 0xFFEFA74: ??? (in
> /usr/local/lib/valgrind/vgpreload_core-ppc32-linux.so)
> ==466==    by 0x404082F: ??? (in /lib/ld-2.25.so)
> ==466==    by 0x4018D27: _dl_signal_error (dl-error-skeleton.c:134)
> ==466==    by 0x4018E67: _dl_signal_cerror (dl-error-skeleton.c:166)
> ==466==    by 0x400AECF: _dl_lookup_symbol_x (dl-lookup.c:874)
> ==466==    by 0x400C977: elf_machine_rela (dl-machine.h:315)
> ==466==    by 0x400C977: elf_dynamic_do_Rela (do-rel.h:170)
> ==466==    by 0x400C977: _dl_relocate_object (dl-reloc.c:259)
> ==466==    by 0x4004923: dl_main (rtld.c:2051)
> ==466==    by 0x4017B73: _dl_sysdep_start (dl-sysdep.c:253)
> ==466==    by 0x4005A3F: _dl_start_final (rtld.c:305)
> ==466==    by 0x4005DD3: _dl_start (rtld.c:413)
> ==466==    by 0x401997B: _start (dl-start.S:38)
> ==466== Your program just tried to execute an instruction that Valgrind
> ==466== did not recognise.  There are two possible reasons for this.
> ==466== 1. Your program has a bug and erroneously jumped to a non-code
> ==466==    location.  If you are running Memcheck and you just saw a
> ==466==    warning about a bad jump, it's probably your program's fault.
> ==466== 2. The instruction is legitimate but Valgrind doesn't handle it,
> ==466==    i.e. it's Valgrind's fault.  If you think this is the case or
> ==466==    you are not sure, please let us know and we'll try to fix it.
> ==466== Either way, Valgrind will now raise a SIGILL signal which will
> ==466== probably kill your program.
> ==466==
> ==466== Process terminating with default action of signal 4 (SIGILL):
> dumping core
> ==466==  Illegal opcode at address 0xFFEFA74
> ==466==    at 0xFFEFA74: ??? (in
> /usr/local/lib/valgrind/vgpreload_core-ppc32-linux.so)
> ==466==    by 0x404082F: ??? (in /lib/ld-2.25.so)
> ==466==    by 0x4018D27: _dl_signal_error (dl-error-skeleton.c:134)
> ==466==    by 0x4018E67: _dl_signal_cerror (dl-error-skeleton.c:166)
> ==466==    by 0x400AECF: _dl_lookup_symbol_x (dl-lookup.c:874)
> ==466==    by 0x400C977: elf_machine_rela (dl-machine.h:315)
> ==466==    by 0x400C977: elf_dynamic_do_Rela (do-rel.h:170)
> ==466==    by 0x400C977: _dl_relocate_object (dl-reloc.c:259)
> ==466==    by 0x4004923: dl_main (rtld.c:2051)
> ==466==    by 0x4017B73: _dl_sysdep_start (dl-sysdep.c:253)
> ==466==    by 0x4005A3F: _dl_start_final (rtld.c:305)
> ==466==    by 0x4005DD3: _dl_start (rtld.c:413)
> ==466==    by 0x401997B: _start (dl-start.S:38)
> ==466==
> ==466== HEAP SUMMARY:
> ==466==     in use at exit: 0 bytes in 0 blocks
> ==466==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
> ==466==
> ==466== All heap blocks were freed -- no leaks are possible
> ==466==
> ==466== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
>
>
> What am I doing wrong? Could there be a problem with my toolchain?
>
>
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>


-- 
-------------
No, I won't  call it "climate change", do you have a "reality problem"? - AB1JX
Cities are cages built to contain excess people and keep them from
cluttering up nature.
Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach

[Valgrind-users] PowerPC undefined symbol _restgpr_30_x

[MP <mx...@gm...>]

I'm trying to use Valgrind on an embedded PowerPC system but I'm
getting the following errors:

./testprog: symbol lookup error:
/usr/local/lib/valgrind/vgpreload_memcheck-ppc32-linux.so: undefined
symbol: _restgpr_30_x
disInstr(ppc): unhandled instruction: 0x0
                 primary 0(0x0), secondary 0(0x0)
==466== valgrind: Unrecognised instruction at address 0xffefa74.
==466==    at 0xFFEFA74: ??? (in
/usr/local/lib/valgrind/vgpreload_core-ppc32-linux.so)

The target setup is:
CPU: MPC8280 (PowerPC 603e core)
Linux Kernel 4.9.59
gcc 6.3.0
glibc 2.25
valgrind 3.15.0
The toolchain was generated using crosstool-NG 1.23 with a target of
"powerpc-generic-linux-gnu".

Test program is:
int main (int argc, char **argv) { return argc; }

It was compiled with:
powerpc-generic-linux-gnu-gcc -o testprog testprog.c

Valgrind was compiled like this:
./configure --host=powerpc-generic-linux-gnu
make

The full program output is as follows:

# valgrind -v ./testprog
==466== Memcheck, a memory error detector
==466== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==466== Using Valgrind-3.15.0-608cb11914-20190413 and LibVEX; rerun
with -h for copyright info
==466== Command: ./testprog
==466==
--466-- Valgrind options:
--466--    -v
--466-- Contents of /proc/version:
--466--   Linux version 4.9.59 (build@engdev) (gcc version 6.3.0
(crosstool-NG crosstool-ng-1.23.0) ) #0 PREEMPT Mon Mar 9 10:36:51 EDT
2020
--466--
--466-- Arch and hwcaps: PPC32, BigEndian, ppc32-int-flt-GX
--466-- Page sizes: currently 4096, max supported 65536
--466-- Valgrind library directory: /usr/local/lib/valgrind
--466-- Reading syms from /lib/ld-2.25.so
--466-- Reading syms from /tmp/testprog
--466-- Reading syms from /usr/local/lib/valgrind/memcheck-ppc32-linux
--466--    object doesn't have a dynamic symbol table
--466-- Scheduler: using generic scheduler lock implementation.
--466-- Reading suppressions file: /usr/local/lib/valgrind/default.supp
==466== embedded gdbserver: reading from
/tmp/vgdb-pipe-from-vgdb-to-466-by-root-on-???
==466== embedded gdbserver: writing to
/tmp/vgdb-pipe-to-vgdb-from-466-by-root-on-???
==466== embedded gdbserver: shared mem
/tmp/vgdb-pipe-shared-mem-vgdb-466-by-root-on-???
==466==
==466== TO CONTROL THIS PROCESS USING vgdb (which you probably
==466== don't want to do, unless you know exactly what you're doing,
==466== or are doing some strange experiment):
==466==   /usr/local/lib/valgrind/../../bin/vgdb --pid=466 ...command...
==466==
==466== TO DEBUG THIS PROCESS USING GDB: start GDB like this
==466==   /path/to/gdb ./testprog
==466== and then give GDB the following command
==466==   target remote | /usr/local/lib/valgrind/../../bin/vgdb --pid=466
==466== --pid is optional if only one valgrind process is running
==466==
--466-- REDIR: 0x401b250 (ld.so.1:strcmp) redirected to 0x58116d7c
(vgPlain_ppc32_linux_REDIR_FOR_strcmp)
--466-- REDIR: 0x401b3b4 (ld.so.1:strlen) redirected to 0x58116d54
(vgPlain_ppc32_linux_REDIR_FOR_strlen)
--466-- REDIR: 0x401b174 (ld.so.1:index) redirected to 0x58116df0
(vgPlain_ppc32_linux_REDIR_FOR_strchr)
--466-- Reading syms from /usr/local/lib/valgrind/vgpreload_core-ppc32-linux.so
--466-- Reading syms from
/usr/local/lib/valgrind/vgpreload_memcheck-ppc32-linux.so
--466-- REDIR: 0x401bec8 (ld.so.1:memcpy) redirected to 0xffba7e8 (memcpy)
--466-- REDIR: 0x401b820 (ld.so.1:bcmp) redirected to 0xffbb8c4 (bcmp)
--466-- Reading syms from /lib/libc-2.25.so
./testprog: symbol lookup error:
/usr/local/lib/valgrind/vgpreload_memcheck-ppc32-linux.so: undefined
symbol: _restgpr_30_x
disInstr(ppc): unhandled instruction: 0x0
                 primary 0(0x0), secondary 0(0x0)
==466== valgrind: Unrecognised instruction at address 0xffefa74.
==466==    at 0xFFEFA74: ??? (in
/usr/local/lib/valgrind/vgpreload_core-ppc32-linux.so)
==466==    by 0x404082F: ??? (in /lib/ld-2.25.so)
==466==    by 0x4018D27: _dl_signal_error (dl-error-skeleton.c:134)
==466==    by 0x4018E67: _dl_signal_cerror (dl-error-skeleton.c:166)
==466==    by 0x400AECF: _dl_lookup_symbol_x (dl-lookup.c:874)
==466==    by 0x400C977: elf_machine_rela (dl-machine.h:315)
==466==    by 0x400C977: elf_dynamic_do_Rela (do-rel.h:170)
==466==    by 0x400C977: _dl_relocate_object (dl-reloc.c:259)
==466==    by 0x4004923: dl_main (rtld.c:2051)
==466==    by 0x4017B73: _dl_sysdep_start (dl-sysdep.c:253)
==466==    by 0x4005A3F: _dl_start_final (rtld.c:305)
==466==    by 0x4005DD3: _dl_start (rtld.c:413)
==466==    by 0x401997B: _start (dl-start.S:38)
==466== Your program just tried to execute an instruction that Valgrind
==466== did not recognise.  There are two possible reasons for this.
==466== 1. Your program has a bug and erroneously jumped to a non-code
==466==    location.  If you are running Memcheck and you just saw a
==466==    warning about a bad jump, it's probably your program's fault.
==466== 2. The instruction is legitimate but Valgrind doesn't handle it,
==466==    i.e. it's Valgrind's fault.  If you think this is the case or
==466==    you are not sure, please let us know and we'll try to fix it.
==466== Either way, Valgrind will now raise a SIGILL signal which will
==466== probably kill your program.
==466==
==466== Process terminating with default action of signal 4 (SIGILL):
dumping core
==466==  Illegal opcode at address 0xFFEFA74
==466==    at 0xFFEFA74: ??? (in
/usr/local/lib/valgrind/vgpreload_core-ppc32-linux.so)
==466==    by 0x404082F: ??? (in /lib/ld-2.25.so)
==466==    by 0x4018D27: _dl_signal_error (dl-error-skeleton.c:134)
==466==    by 0x4018E67: _dl_signal_cerror (dl-error-skeleton.c:166)
==466==    by 0x400AECF: _dl_lookup_symbol_x (dl-lookup.c:874)
==466==    by 0x400C977: elf_machine_rela (dl-machine.h:315)
==466==    by 0x400C977: elf_dynamic_do_Rela (do-rel.h:170)
==466==    by 0x400C977: _dl_relocate_object (dl-reloc.c:259)
==466==    by 0x4004923: dl_main (rtld.c:2051)
==466==    by 0x4017B73: _dl_sysdep_start (dl-sysdep.c:253)
==466==    by 0x4005A3F: _dl_start_final (rtld.c:305)
==466==    by 0x4005DD3: _dl_start (rtld.c:413)
==466==    by 0x401997B: _start (dl-start.S:38)
==466==
==466== HEAP SUMMARY:
==466==     in use at exit: 0 bytes in 0 blocks
==466==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==466==
==466== All heap blocks were freed -- no leaks are possible
==466==
==466== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)


What am I doing wrong? Could there be a problem with my toolchain?

[Valgrind-users] VG_(exit) not properly releasing BigLock after VG_(fork)

[Derrick M. <der...@gm...>]

Hi,

I am writing a tool that is trying to execute an arbitrary function in
the client and report the program state immediately after finishing.
I have been able to get the client to jump to the function I want and
execute.  However to get that to work, I have registered a function
via VG_(track_pre_thread_ll_create) that calls VG_(fork), after which
only the child process continues to execute the client code.  The
parent waits on the child to exit via VG_(waitpid), and reads the
program state reported by the child on a pipe.  The parent then waits
for an external process to issue the command to execute the same
function again.  If the forks and the child runs the same function,
the child process hangs while trying to acquire the BigLock.  I was
able to solve the issue by having my child manually call
VG_(release_BigLock_LL)(NULL) before VG_(exit)().

This seems like a bug, as I would assume the VG_(exit) would release
any held locks, however I am not sure if there is a reason for not
doing this.  If it is a bug, I would be happy to make a bug report for
this, along with a minimal example.


-- 
Derrick McKee
Phone: (703) 957-9362
Email: der...@gm...

Re: [Valgrind-users] Unable to start process with valgrind, failing with setns

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

Hi Bhargav,

On Mon, Mar 16, 2020 at 10:44:42AM +0530, bhargav p wrote:
> I am trying to start a process with valgrind. In my code, I am using setns
> call.
> 
> When I start process with valgrind, seeing below error and process is
> getting exited.
> 
>  "Failed to switch to namespace ns1: Function not implemented"
> 
> 
> If I start process without valgrind, I am not seeing this error message.
> 
> 
> Can someone please help me how to resolve this?

There is a bug report about this already:
https://bugs.kde.org/show_bug.cgi?id=343099
It does have a patch attached. Maybe you can test it?

Cheers,

Mark

[Valgrind-users] Unable to start process with valgrind, failing with setns

[bhargav p <bha...@gm...>]

Hi Team,

I am trying to start a process with valgrind. In my code, I am using setns
call.

When I start process with valgrind, seeing below error and process is
getting exited.

 "Failed to switch to namespace ns1: Function not implemented"


If I start process without valgrind, I am not seeing this error message.


Can someone please help me how to resolve this?


-Bhargav

[Valgrind-users] valgrind-3.15.0 on cpu e500v2 : unhandled instruction: 0x10E40301

[ashish y. <ash...@gm...>]

Hi,

I  am using valgrind-3.15.0 on the cpu e500v2.
Linux kernel version is  2.6.27.47 .

#  LD_SHOW_AUXV=1 /bin/true | grep AT_HWCAP
AT_HWCAP:        booke efpdouble efpsingle spe mmu ppc32

While using  valgrind, its throwing Illegal instruction error:
disInstr(ppc): unhandled instruction: 0x10E40301
                 primary 4(0x4), secondary 769(0x301)
==13854== valgrind: Unrecognised instruction at address 0xffd9510.
==13854==    at 0xFFD9510: memcpy (in /lib/ld-2.8.so)
==13854==    by 0xFFC21BF: _dl_start_final (rtld.c:287)
==13854==    by 0xFFD62C7: _start (in /lib/ld-2.8.so)

Could you please provide me steps to resolve this issue.

Please let me know if you need more information from my side.

Thanks & Regards
   Ashish Yadav

Re: [Valgrind-users] Calling arbitrary guest functions

[Derrick M. <der...@gm...>]

Thanks for the tip.  I saw that code while grepping for VG_(set_IP),
and I thought I was doing what that function was doing.  However,
looking closer, I see that the IP is being set to the result of
VG_(client_freeres) which contains the address of the client function
that is called.  I am pretty sure that I am not getting the correct
address of the client function I want to call.  I've searched around
for some function that can provide me the client address given a
function name, and there doesn't appear to be one.  Any other way I
can get a client function address?

As an aside, I am interested in why the client program executes
normally, despite me calling VG_(set_IP) with an invalid address from
SE_(start_client_code) above.  I read that function executes in the
client context, but nothing seemingly changes when I call VG_(set_IP)
in a function tracking thread creation, which runs in the tool's
context.  I would expect the tool or the client to crash when I set an
invalid IP, but the client executes as if the IP is correct.

On Thu, Mar 5, 2020 at 3:58 PM Philippe Waroquiers
<phi...@sk...> wrote:
>
> You might find some inspiration by reading the function final_tidyup
> in coregrind/m_main.c.
>
> final_tidyup is calling some client code part of malloc library.
>
> Philippe
>
>
> On Thu, 2020-03-05 at 11:27 -0500, Derrick McKee wrote:
> > My intent is to write a tool that waits for another process to write
> > client addresses to a pipe, and then execute the specified function
> > with a fixed number of arguments.  I'm unconcerned about whether the
> > specified function actually has the assumed arity or not, though.  I
> > tried the following, but it seems that the function is not called.
> > However, this is what I am wanting to do.
> > ---------------------------------------------
> > static void SE_(start_client_code)(ThreadId tid, ULong blocks_dispatched) {
> >   if (!client_running && tid == client_thread_id) {
> >     VG_(umsg)
> >     ("Thread %u is starting executing at instruction 0x%lx with "
> >      "blocks_dispatched=%llu\n",
> >      tid, VG_(get_IP)(tid), blocks_dispatched);
> >     client_running = True;
> >     VG_(umsg)("Thread %u is about to call target function\n", tid);
> >     OrigFn fn;
> >     fn.nraddr = (Addr)0x401145; // Function address in client
> >     CALL_FN_v_v(fn);  // Assume no arguments are passed in
> >     VG_(umsg)("Thread %u returned\n", tid);
> >     client_running = False;
> >   }
> > }
> >
> > static void SE_(pre_clo_init)(void) {
> >     ....
> >     VG_(track_start_client_code)(SE_(start_client_code));
> > }
> >
> > VG_DETERMINE_INTERFACE_VERSION(SE_(pre_clo_init))
> > --------------------------------------
> > Reading the documentation, it seems that CALL_FN_v_v should be called
> > from the client code, but I want to use my tool with any binary.  I
> > also tried using the VG_(set_IP) function (admittedly against the
> > valgrind tool contract), but that seemingly didn't work either.  Any
> > other thoughts, or is this just something I cannot do with valgrind?
> >
> > On Tue, Mar 3, 2020 at 11:01 AM Derrick McKee <der...@gm...> wrote:
> > > I am also interested in instrumenting the guest binary, as well as
> > > change which guest function I execute at run time.  So LD_PRELOAD
> > > won't help me here.
> > >
> > > On Tue, Mar 3, 2020 at 10:41 AM John Reiser <jr...@bi...> wrote:
> > > > > I am trying to make a tool that intercepts the call to main, and then
> > > > > call an arbitrary function within the guest with arbitrary function
> > > > > arguments.
> > > >
> > > > This can be done without valgrind by using LD_PRELOAD environment variable
> > > > and RTLD_NEXT (see "man dlsym"):
> > > >
> > > >      LD_PRELOAD=main_interceptor.so  ./my_app args...
> > > >
> > > > where main_interceptor.so is a shared library that has a function main()
> > > > and that can call the original main() by using dlsym(RTLD_NEXT, "main").
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > Valgrind-users mailing list
> > > > Val...@li...
> > > > https://lists.sourceforge.net/lists/listinfo/valgrind-users
> > >
> > >
> > > --
> > > Derrick McKee
> > > Phone: (703) 957-9362
> > > Email: der...@gm...
> >
> >
>


-- 
Derrick McKee
Phone: (703) 957-9362
Email: der...@gm...

Re: [Valgrind-users] Calling arbitrary guest functions

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

You might find some inspiration by reading the function final_tidyup
in coregrind/m_main.c.

final_tidyup is calling some client code part of malloc library.

Philippe


On Thu, 2020-03-05 at 11:27 -0500, Derrick McKee wrote:
> My intent is to write a tool that waits for another process to write
> client addresses to a pipe, and then execute the specified function
> with a fixed number of arguments.  I'm unconcerned about whether the
> specified function actually has the assumed arity or not, though.  I
> tried the following, but it seems that the function is not called.
> However, this is what I am wanting to do.
> ---------------------------------------------
> static void SE_(start_client_code)(ThreadId tid, ULong blocks_dispatched) {
>   if (!client_running && tid == client_thread_id) {
>     VG_(umsg)
>     ("Thread %u is starting executing at instruction 0x%lx with "
>      "blocks_dispatched=%llu\n",
>      tid, VG_(get_IP)(tid), blocks_dispatched);
>     client_running = True;
>     VG_(umsg)("Thread %u is about to call target function\n", tid);
>     OrigFn fn;
>     fn.nraddr = (Addr)0x401145; // Function address in client
>     CALL_FN_v_v(fn);  // Assume no arguments are passed in
>     VG_(umsg)("Thread %u returned\n", tid);
>     client_running = False;
>   }
> }
> 
> static void SE_(pre_clo_init)(void) {
>     ....
>     VG_(track_start_client_code)(SE_(start_client_code));
> }
> 
> VG_DETERMINE_INTERFACE_VERSION(SE_(pre_clo_init))
> --------------------------------------
> Reading the documentation, it seems that CALL_FN_v_v should be called
> from the client code, but I want to use my tool with any binary.  I
> also tried using the VG_(set_IP) function (admittedly against the
> valgrind tool contract), but that seemingly didn't work either.  Any
> other thoughts, or is this just something I cannot do with valgrind?
> 
> On Tue, Mar 3, 2020 at 11:01 AM Derrick McKee <der...@gm...> wrote:
> > I am also interested in instrumenting the guest binary, as well as
> > change which guest function I execute at run time.  So LD_PRELOAD
> > won't help me here.
> > 
> > On Tue, Mar 3, 2020 at 10:41 AM John Reiser <jr...@bi...> wrote:
> > > > I am trying to make a tool that intercepts the call to main, and then
> > > > call an arbitrary function within the guest with arbitrary function
> > > > arguments.
> > > 
> > > This can be done without valgrind by using LD_PRELOAD environment variable
> > > and RTLD_NEXT (see "man dlsym"):
> > > 
> > >      LD_PRELOAD=main_interceptor.so  ./my_app args...
> > > 
> > > where main_interceptor.so is a shared library that has a function main()
> > > and that can call the original main() by using dlsym(RTLD_NEXT, "main").
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > _______________________________________________
> > > Valgrind-users mailing list
> > > Val...@li...
> > > https://lists.sourceforge.net/lists/listinfo/valgrind-users
> > 
> > 
> > --
> > Derrick McKee
> > Phone: (703) 957-9362
> > Email: der...@gm...
> 
> 

[Valgrind-users] Calling var_args functions from with Wrapper

[Austin G. <aga...@aa...>]

Hello!

I am trying to call the function vsnprintf from within a wrapper for vnsprintf using the I_WRAP and CALL_FN macros provided by Valgrind.

However, all of the CALL_FN macros only take longs as parameters. vsnprintf takes a va_list struct as one of its parameters.

Is there a way to use call functions that take va_lists (or any sort of struct) as parameters from inside a wrapper?

Best Regards,
Austin Gadient

Re: [Valgrind-users] Calling arbitrary guest functions

[Derrick M. <der...@gm...>]

My intent is to write a tool that waits for another process to write
client addresses to a pipe, and then execute the specified function
with a fixed number of arguments.  I'm unconcerned about whether the
specified function actually has the assumed arity or not, though.  I
tried the following, but it seems that the function is not called.
However, this is what I am wanting to do.
---------------------------------------------
static void SE_(start_client_code)(ThreadId tid, ULong blocks_dispatched) {
  if (!client_running && tid == client_thread_id) {
    VG_(umsg)
    ("Thread %u is starting executing at instruction 0x%lx with "
     "blocks_dispatched=%llu\n",
     tid, VG_(get_IP)(tid), blocks_dispatched);
    client_running = True;
    VG_(umsg)("Thread %u is about to call target function\n", tid);
    OrigFn fn;
    fn.nraddr = (Addr)0x401145; // Function address in client
    CALL_FN_v_v(fn);  // Assume no arguments are passed in
    VG_(umsg)("Thread %u returned\n", tid);
    client_running = False;
  }
}

static void SE_(pre_clo_init)(void) {
    ....
    VG_(track_start_client_code)(SE_(start_client_code));
}

VG_DETERMINE_INTERFACE_VERSION(SE_(pre_clo_init))
--------------------------------------
Reading the documentation, it seems that CALL_FN_v_v should be called
from the client code, but I want to use my tool with any binary.  I
also tried using the VG_(set_IP) function (admittedly against the
valgrind tool contract), but that seemingly didn't work either.  Any
other thoughts, or is this just something I cannot do with valgrind?

On Tue, Mar 3, 2020 at 11:01 AM Derrick McKee <der...@gm...> wrote:
>
> I am also interested in instrumenting the guest binary, as well as
> change which guest function I execute at run time.  So LD_PRELOAD
> won't help me here.
>
> On Tue, Mar 3, 2020 at 10:41 AM John Reiser <jr...@bi...> wrote:
> >
> > > I am trying to make a tool that intercepts the call to main, and then
> > > call an arbitrary function within the guest with arbitrary function
> > > arguments.
> >
> > This can be done without valgrind by using LD_PRELOAD environment variable
> > and RTLD_NEXT (see "man dlsym"):
> >
> >      LD_PRELOAD=main_interceptor.so  ./my_app args...
> >
> > where main_interceptor.so is a shared library that has a function main()
> > and that can call the original main() by using dlsym(RTLD_NEXT, "main").
> >
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > Valgrind-users mailing list
> > Val...@li...
> > https://lists.sourceforge.net/lists/listinfo/valgrind-users
>
>
>
> --
> Derrick McKee
> Phone: (703) 957-9362
> Email: der...@gm...



-- 
Derrick McKee
Phone: (703) 957-9362
Email: der...@gm...

Re: [Valgrind-users] Write new tool in C++?

[Derrick M. <der...@gm...>]

Thanks for the response.  That's what I am seeing in my initial test,
as I am getting undefined reference errors to std::cout during
linking.

On Wed, Mar 4, 2020 at 10:16 AM Tom Hughes <to...@co...> wrote:
>
> On 04/03/2020 14:46, Derrick McKee wrote:
>
> > Is it possible to write a tool using C++ instead of just C?
>
> In theory, maybe, but the problem you're going to have is that
> you have no run time library support - no libstdc+++ and not even
> any libc. So there are probably various things that need run time
> support that just aren't going to work and you're not going to have
> any of the normal library data structures and things.
>
> Tom
>
> --
> Tom Hughes (to...@co...)
> http://compton.nu/



-- 
Derrick McKee
Phone: (703) 957-9362
Email: der...@gm...

Re: [Valgrind-users] Write new tool in C++?

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

On 04/03/2020 14:46, Derrick McKee wrote:

> Is it possible to write a tool using C++ instead of just C?

In theory, maybe, but the problem you're going to have is that
you have no run time library support - no libstdc+++ and not even
any libc. So there are probably various things that need run time
support that just aren't going to work and you're not going to have
any of the normal library data structures and things.

Tom

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

[Valgrind-users] Write new tool in C++?

[Derrick M. <der...@gm...>]

Hi,

Is it possible to write a tool using C++ instead of just C?

-- 
Derrick McKee
Phone: (703) 957-9362
Email: der...@gm...

[Valgrind-users] obj:*/fun:* matching in suppression

[Deene D. <dd...@ma...>]

Hi,

I'm running some Valgrind test programs (using 3.15.0) that trigger all of the Memcheck errors and have noticed that a suppression file (I was accidently loading) was suppressing a bunch of the issues, but on the surface the match was 'obj:*' for 'fun:*' which is not what I expected.
e.g. without adding the suppression file I get the nice simple Definite Leak

==241898== 8 bytes in 1 blocks are definitely lost in loss record 1 of 2
==241898==    at 0x4C2BF0D: malloc (/valgrind/valgrind-3.15.0/src/valgrind-3.15.0/coregrind/m_replacemalloc/vg_replace_malloc.c:309)
==241898==    by 0x400884: LDL_2() (/src/test_valgrind/test_ldl.cpp:72)
==241898==    by 0x4008AE: main (/src/test_valgrind/test_ldl.cpp:80)
==241898==
{
   <insert_a_suppression_name_here>
   Memcheck:Leak
   match-leak-kinds: definite
   fun:malloc
   fun:_Z5LDL_2v
   fun:main
}

Adding in the suppression file the issue is suppressed:

--243931-- used_suppression:      1 <insert_a_suppression_name_here> /devel/valgrind_glnxa64.supp:17391 suppressed: 8 bytes in 1 blocks

e.g.
<insert_a_suppression_name_here>
    Memcheck:Leak
    match-leak-kinds:definite
    fun:malloc
    obj:*
    obj:*
    obj:*
}

After reading  '2.5. Suppressing errors' from the user manual I would assume using an 'obj:' or a 'fun:' implied there had to be a match of that type, and that any wildcard kicked in after the type (i.e. shared lib or function) was matched.
Is that not the case?

i.e. is the above suppression really the same as
{
<insert_a_suppression_name_here>
    Memcheck:Leak
    match-leak-kinds:definite
    fun:malloc
}

Thanks

Re: [Valgrind-users] detecting uninitialized values in debug builds

[Ben W. <ben...@co...>]

Thanks.  Obviously, I should have tried that before posting my question, although I would not have known how to obtain the answer without seeing your answer below.

Not being familiar with the x86 asm language, I modified the foo.cpp program (explicitly assign y=0) and then g++ again, so I could compare the two asm lang outputs.  After that, it was fairly clear that the compiler is not initializing y.

Ben

-----Original Message-----
From: John Reiser <jr...@bi...> 
Sent: Monday, March 2, 2020 7:20 PM
To: val...@li...
Subject: Re: [Valgrind-users] detecting uninitialized values in debug builds

On 3/2/20 22:02 UTC, Ben White wrote:
> I've also been told that the g++ compiler will initialize all stack 
> objects to zero when compiling for debug (the -g option).

Obviously you didn't try it.  g++ 9.2.1 does not do that.

$ cat foo.cpp
int g(int x, int y);

int f(int x)
{
	int y;
         return	g(x, y);  // uninit use of y
}

$ g++ -g -S foo.cpp
$ cat foo.s
	.file	"foo.cpp"
	.text
.Ltext0:
	.globl	_Z1fi
	.type	_Z1fi, @function
_Z1fi:
.LFB0:
	.file 1 "foo.cpp"
	.loc 1 4 1
	.cfi_startproc
	pushq	%rbp
	.cfi_def_cfa_offset 16
	.cfi_offset 6, -16
	movq	%rsp, %rbp
	.cfi_def_cfa_register 6
	subq	$32, %rsp
	movl	%edi, -20(%rbp)
	.loc 1 6 17
	movl	-4(%rbp), %edx   // -4(%rbp) is never initialized
	movl	-20(%rbp), %eax
	movl	%edx, %esi   // 2nd parameter to g
	movl	%eax, %edi
	call	_Z1gii
	.loc 1 7 1
	leave
	.cfi_def_cfa 7, 8
	ret
	.cfi_endproc
.LFE0:
	.size	_Z1fi, .-_Z1fi
   [[snip]]
	.section	.debug_str,"MS",@progbits,1
.LASF1:
	.string	"foo.cpp"
.LASF0:
	.string	"GNU C++14 9.2.1 20190827 (Red Hat 9.2.1-1) -mtune=generic -march=x86-64 -g"
.LASF3:
	.string	"_Z1fi"
.LASF2:
	.string	"/home/user"
	.ident	"GCC: (GNU) 9.2.1 20190827 (Red Hat 9.2.1-1)"
	.section	.note.GNU-stack,"",@progbits
$


_______________________________________________
Valgrind-users mailing list
Val...@li...
https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Fvalgrind-users&amp;data=02%7C01%7Cben.white%40cohu.com%7C4af3d19203134610feef08d7bf220529%7Ceacc2a35149847488d1f03fb953672f8%7C0%7C0%7C637188025165390441&amp;sdata=CkROtsN2ADGpGORSPKlYSEqmibqd3VLSA0LfO8U2giU%3D&amp;reserved=0

Re: [Valgrind-users] Calling arbitrary guest functions

[Derrick M. <der...@gm...>]

I am also interested in instrumenting the guest binary, as well as
change which guest function I execute at run time.  So LD_PRELOAD
won't help me here.

On Tue, Mar 3, 2020 at 10:41 AM John Reiser <jr...@bi...> wrote:
>
> > I am trying to make a tool that intercepts the call to main, and then
> > call an arbitrary function within the guest with arbitrary function
> > arguments.
>
> This can be done without valgrind by using LD_PRELOAD environment variable
> and RTLD_NEXT (see "man dlsym"):
>
>      LD_PRELOAD=main_interceptor.so  ./my_app args...
>
> where main_interceptor.so is a shared library that has a function main()
> and that can call the original main() by using dlsym(RTLD_NEXT, "main").
>
>
>
>
>
>
>
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users



-- 
Derrick McKee
Phone: (703) 957-9362
Email: der...@gm...

Re: [Valgrind-users] Calling arbitrary guest functions

[John R. <jr...@bi...>]

> I am trying to make a tool that intercepts the call to main, and then
> call an arbitrary function within the guest with arbitrary function
> arguments.

This can be done without valgrind by using LD_PRELOAD environment variable
and RTLD_NEXT (see "man dlsym"):

     LD_PRELOAD=main_interceptor.so  ./my_app args...

where main_interceptor.so is a shared library that has a function main()
and that can call the original main() by using dlsym(RTLD_NEXT, "main").

[Valgrind-users] Calling arbitrary guest functions

[Derrick M. <der...@gm...>]

Hi,

I am trying to make a tool that intercepts the call to main, and then
call an arbitrary function within the guest with arbitrary function
arguments.  Is this possible?  Thanks.

-- 
Derrick McKee
Phone: (703) 957-9362
Email: der...@gm...

Re: [Valgrind-users] detecting uninitialized values in debug builds

[Dallman, J. <joh...@si...>]

> However, I've also been told that the g++ compiler will initialize all stack objects to zero when compiling for debug (the -g option).  Yet, valgrind still detects the un-init condition.

I think whoever told you that was confusing it with Microsoft Visual Studio. The default debug-build configuration for that IDE does initialise all variables.

--
John Dallman

-----------------
Siemens Industry Software Limited is a limited company registered in England and Wales.
Registered number: 3476850.
Registered office: Faraday House, Sir William Siemens Square, Frimley, Surrey, GU16 8QD.

Re: [Valgrind-users] detecting uninitialized values in debug builds

[John R. <jr...@bi...>]

On 3/2/20 22:02 UTC, Ben White wrote:
> I’ve also been told that the g++ compiler will initialize all stack 
> objects to zero when compiling for debug (the -g option).

Obviously you didn't try it.  g++ 9.2.1 does not do that.

$ cat foo.cpp
int g(int x, int y);

int f(int x)
{
	int y;
         return	g(x, y);  // uninit use of y
}

$ g++ -g -S foo.cpp
$ cat foo.s
	.file	"foo.cpp"
	.text
.Ltext0:
	.globl	_Z1fi
	.type	_Z1fi, @function
_Z1fi:
.LFB0:
	.file 1 "foo.cpp"
	.loc 1 4 1
	.cfi_startproc
	pushq	%rbp
	.cfi_def_cfa_offset 16
	.cfi_offset 6, -16
	movq	%rsp, %rbp
	.cfi_def_cfa_register 6
	subq	$32, %rsp
	movl	%edi, -20(%rbp)
	.loc 1 6 17
	movl	-4(%rbp), %edx   // -4(%rbp) is never initialized
	movl	-20(%rbp), %eax
	movl	%edx, %esi   // 2nd parameter to g
	movl	%eax, %edi
	call	_Z1gii
	.loc 1 7 1
	leave
	.cfi_def_cfa 7, 8
	ret
	.cfi_endproc
.LFE0:
	.size	_Z1fi, .-_Z1fi
   [[snip]]
	.section	.debug_str,"MS",@progbits,1
.LASF1:
	.string	"foo.cpp"
.LASF0:
	.string	"GNU C++14 9.2.1 20190827 (Red Hat 9.2.1-1) -mtune=generic -march=x86-64 -g"
.LASF3:
	.string	"_Z1fi"
.LASF2:
	.string	"/home/user"
	.ident	"GCC: (GNU) 9.2.1 20190827 (Red Hat 9.2.1-1)"
	.section	.note.GNU-stack,"",@progbits
$

[Valgrind-users] detecting uninitialized values in debug builds

[Ben W. <ben...@co...>]

Hello,

I have seen cases where valgrind (memcheck) will report conditional jump or move based on uninitialized value, and when examining the relevant source code, I can see that the value or variable is indeed uninitialized.  However, I've also been told that the g++ compiler will initialize all stack objects to zero when compiling for debug (the -g option).  Yet, valgrind still detects the un-init condition.

Does anybody know how this works behind the scenes?  This is mainly a curiosity question, no need to research it.

Ben White
Diagnostics, Calibration, and Verification (DCV)
Cohu Inc.

Re: [Valgrind-users] Valgrind master fails to compile

[Jeff H. <jef...@gm...>]

The attached patches address these issues, which are caused by the correct
implementation of deprecated function deletion in Open-MPI 4.
https://www.open-mpi.org/faq/?category=mpi-removed has details.

This is my first attempted contribution to Valgrind so please let me know
if the patches need modifications to be accepted.  Do I need to state that
I license them as "GPLv2, or (at your option) any later version," in the
patches?

I would not object at all if someone wants the MPI_UB/MPI_LB workaround to
be different, since there are a bunch of valid ways to implement it.  I
suppose "#ifdef MPI_UB" etc. is simpler, but I can't remember off the top
of my head if the MPI standard requires that identifier to be a
preprocessor symbol or if that is merely common practice, so I did not want
to use a direct preprocessor test on it.

Best,

Jeff

On Sun, Mar 1, 2020 at 1:35 PM Derrick McKee <der...@gm...>
wrote:

> I am having a problem compiling Valgrind using OpenMPI 4.0.2.  The
> error is listed below.  It seems it is the same bug logged in [1].
> Has there been any patch made that resolves the issue?  Thanks.
>
> - Derrick
>
> [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=946329
>
> Error
> -----------------------------------------------------------------------
> mkdir -p ../.in_place; \
> for f in ; do \
>   rm -f ../.in_place/$f.dSYM; \
>   ln -f -s ../mpi/$f.dSYM ../.in_place; \
> done
> In file included from ../../mpi/libmpiwrap.c:116:
> ../../mpi/libmpiwrap.c: In function ‘showTy’:
> ../../mpi/libmpiwrap.c:281:19: error: expected expression before
> ‘_Static_assert’
>   281 |    else if (ty == MPI_UB)             fprintf(f,"UB");
>       |                   ^~~~~~
> ../../mpi/libmpiwrap.c:282:19: error: expected expression before
> ‘_Static_assert’
>   282 |    else if (ty == MPI_LB)             fprintf(f,"LB");
>       |                   ^~~~~~
> ../../mpi/libmpiwrap.c: In function ‘showCombiner’:
> ../../mpi/libmpiwrap.c:354:12: error: expected expression before
> ‘_Static_assert’
>   354 |       case MPI_COMBINER_HVECTOR_INTEGER: fprintf(f,
> "HVECTOR_INTEGER"); break;
>       |            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
> ../../mpi/libmpiwrap.c:354:12: error: expected expression before
> ‘_Static_assert’
> ../../mpi/libmpiwrap.c:354:40: error: expected expression before ‘:’ token
>   354 |       case MPI_COMBINER_HVECTOR_INTEGER: fprintf(f,
> "HVECTOR_INTEGER"); break;
>       |                                        ^
> In file included from ../../mpi/libmpiwrap.c:116:
> ../../mpi/libmpiwrap.c:359:12: error: expected expression before
> ‘_Static_assert’
>   359 |       case MPI_COMBINER_HINDEXED_INTEGER: fprintf(f,
> "HINDEXED_INTEGER"); break;
>       |            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> ../../mpi/libmpiwrap.c:359:12: error: expected expression before
> ‘_Static_assert’
> ../../mpi/libmpiwrap.c:359:41: error: expected expression before ‘:’ token
>   359 |       case MPI_COMBINER_HINDEXED_INTEGER: fprintf(f,
> "HINDEXED_INTEGER"); break;
>       |                                         ^
> In file included from ../../mpi/libmpiwrap.c:116:
> ../../mpi/libmpiwrap.c:366:12: error: expected expression before
> ‘_Static_assert’
>   366 |       case MPI_COMBINER_STRUCT_INTEGER: fprintf(f,
> "STRUCT_INTEGER"); break;
>       |            ^~~~~~~~~~~~~~~~~~~~~~~~~~~
> ../../mpi/libmpiwrap.c:366:12: error: expected expression before
> ‘_Static_assert’
> ../../mpi/libmpiwrap.c:366:39: error: expected expression before ‘:’ token
>   366 |       case MPI_COMBINER_STRUCT_INTEGER: fprintf(f,
> "STRUCT_INTEGER"); break;
>       |                                       ^
> ../../mpi/libmpiwrap.c: In function ‘extentOfTy’:
> ../../mpi/libmpiwrap.c:462:8: warning: implicit declaration of
> function ‘PMPI_Type_extent’; did you mean ‘MPI_Type_extent’?
> [-Wimplicit-function-declaration]
>   462 |    r = PMPI_Type_extent(ty, &n);
>       |        ^~~~~~~~~~~~~~~~
>       |        MPI_Type_extent
> In file included from ../../mpi/libmpiwrap.c:116:
> ../../mpi/libmpiwrap.c: In function ‘walk_type’:
> ../../mpi/libmpiwrap.c:736:17: error: expected expression before
> ‘_Static_assert’
>   736 |       if (ty == MPI_LB || ty == MPI_UB)
>
> --
> Derrick McKee
> Phone: (703) 957-9362
> Email: der...@gm...
>
>
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>


-- 
Jeff Hammond
jef...@gm...
http://jeffhammond.github.io/

Re: [Valgrind-users] Valgrind master fails to compile

[Jeff H. <jef...@gm...>]

_Static_assert is C11. Are you using a compiler that supports C11 and are
you using the correct flags to activate that support?

Jeff

On Sun, Mar 1, 2020 at 1:35 PM Derrick McKee <der...@gm...>
wrote:

> I am having a problem compiling Valgrind using OpenMPI 4.0.2.  The
> error is listed below.  It seems it is the same bug logged in [1].
> Has there been any patch made that resolves the issue?  Thanks.
>
> - Derrick
>
> [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=946329
>
> Error
> -----------------------------------------------------------------------
> mkdir -p ../.in_place; \
> for f in ; do \
>   rm -f ../.in_place/$f.dSYM; \
>   ln -f -s ../mpi/$f.dSYM ../.in_place; \
> done
> In file included from ../../mpi/libmpiwrap.c:116:
> ../../mpi/libmpiwrap.c: In function ‘showTy’:
> ../../mpi/libmpiwrap.c:281:19: error: expected expression before
> ‘_Static_assert’
>   281 |    else if (ty == MPI_UB)             fprintf(f,"UB");
>       |                   ^~~~~~
> ../../mpi/libmpiwrap.c:282:19: error: expected expression before
> ‘_Static_assert’
>   282 |    else if (ty == MPI_LB)             fprintf(f,"LB");
>       |                   ^~~~~~
> ../../mpi/libmpiwrap.c: In function ‘showCombiner’:
> ../../mpi/libmpiwrap.c:354:12: error: expected expression before
> ‘_Static_assert’
>   354 |       case MPI_COMBINER_HVECTOR_INTEGER: fprintf(f,
> "HVECTOR_INTEGER"); break;
>       |            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
> ../../mpi/libmpiwrap.c:354:12: error: expected expression before
> ‘_Static_assert’
> ../../mpi/libmpiwrap.c:354:40: error: expected expression before ‘:’ token
>   354 |       case MPI_COMBINER_HVECTOR_INTEGER: fprintf(f,
> "HVECTOR_INTEGER"); break;
>       |                                        ^
> In file included from ../../mpi/libmpiwrap.c:116:
> ../../mpi/libmpiwrap.c:359:12: error: expected expression before
> ‘_Static_assert’
>   359 |       case MPI_COMBINER_HINDEXED_INTEGER: fprintf(f,
> "HINDEXED_INTEGER"); break;
>       |            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> ../../mpi/libmpiwrap.c:359:12: error: expected expression before
> ‘_Static_assert’
> ../../mpi/libmpiwrap.c:359:41: error: expected expression before ‘:’ token
>   359 |       case MPI_COMBINER_HINDEXED_INTEGER: fprintf(f,
> "HINDEXED_INTEGER"); break;
>       |                                         ^
> In file included from ../../mpi/libmpiwrap.c:116:
> ../../mpi/libmpiwrap.c:366:12: error: expected expression before
> ‘_Static_assert’
>   366 |       case MPI_COMBINER_STRUCT_INTEGER: fprintf(f,
> "STRUCT_INTEGER"); break;
>       |            ^~~~~~~~~~~~~~~~~~~~~~~~~~~
> ../../mpi/libmpiwrap.c:366:12: error: expected expression before
> ‘_Static_assert’
> ../../mpi/libmpiwrap.c:366:39: error: expected expression before ‘:’ token
>   366 |       case MPI_COMBINER_STRUCT_INTEGER: fprintf(f,
> "STRUCT_INTEGER"); break;
>       |                                       ^
> ../../mpi/libmpiwrap.c: In function ‘extentOfTy’:
> ../../mpi/libmpiwrap.c:462:8: warning: implicit declaration of
> function ‘PMPI_Type_extent’; did you mean ‘MPI_Type_extent’?
> [-Wimplicit-function-declaration]
>   462 |    r = PMPI_Type_extent(ty, &n);
>       |        ^~~~~~~~~~~~~~~~
>       |        MPI_Type_extent
> In file included from ../../mpi/libmpiwrap.c:116:
> ../../mpi/libmpiwrap.c: In function ‘walk_type’:
> ../../mpi/libmpiwrap.c:736:17: error: expected expression before
> ‘_Static_assert’
>   736 |       if (ty == MPI_LB || ty == MPI_UB)
>
> --
> Derrick McKee
> Phone: (703) 957-9362
> Email: der...@gm...
>
>
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>
-- 
Jeff Hammond
jef...@gm...
http://jeffhammond.github.io/

[Valgrind-users] Valgrind master fails to compile

[Derrick M. <der...@gm...>]

I am having a problem compiling Valgrind using OpenMPI 4.0.2.  The
error is listed below.  It seems it is the same bug logged in [1].
Has there been any patch made that resolves the issue?  Thanks.

- Derrick

[1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=946329

Error
-----------------------------------------------------------------------
mkdir -p ../.in_place; \
for f in ; do \
  rm -f ../.in_place/$f.dSYM; \
  ln -f -s ../mpi/$f.dSYM ../.in_place; \
done
In file included from ../../mpi/libmpiwrap.c:116:
../../mpi/libmpiwrap.c: In function ‘showTy’:
../../mpi/libmpiwrap.c:281:19: error: expected expression before
‘_Static_assert’
  281 |    else if (ty == MPI_UB)             fprintf(f,"UB");
      |                   ^~~~~~
../../mpi/libmpiwrap.c:282:19: error: expected expression before
‘_Static_assert’
  282 |    else if (ty == MPI_LB)             fprintf(f,"LB");
      |                   ^~~~~~
../../mpi/libmpiwrap.c: In function ‘showCombiner’:
../../mpi/libmpiwrap.c:354:12: error: expected expression before
‘_Static_assert’
  354 |       case MPI_COMBINER_HVECTOR_INTEGER: fprintf(f,
"HVECTOR_INTEGER"); break;
      |            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
../../mpi/libmpiwrap.c:354:12: error: expected expression before
‘_Static_assert’
../../mpi/libmpiwrap.c:354:40: error: expected expression before ‘:’ token
  354 |       case MPI_COMBINER_HVECTOR_INTEGER: fprintf(f,
"HVECTOR_INTEGER"); break;
      |                                        ^
In file included from ../../mpi/libmpiwrap.c:116:
../../mpi/libmpiwrap.c:359:12: error: expected expression before
‘_Static_assert’
  359 |       case MPI_COMBINER_HINDEXED_INTEGER: fprintf(f,
"HINDEXED_INTEGER"); break;
      |            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../../mpi/libmpiwrap.c:359:12: error: expected expression before
‘_Static_assert’
../../mpi/libmpiwrap.c:359:41: error: expected expression before ‘:’ token
  359 |       case MPI_COMBINER_HINDEXED_INTEGER: fprintf(f,
"HINDEXED_INTEGER"); break;
      |                                         ^
In file included from ../../mpi/libmpiwrap.c:116:
../../mpi/libmpiwrap.c:366:12: error: expected expression before
‘_Static_assert’
  366 |       case MPI_COMBINER_STRUCT_INTEGER: fprintf(f,
"STRUCT_INTEGER"); break;
      |            ^~~~~~~~~~~~~~~~~~~~~~~~~~~
../../mpi/libmpiwrap.c:366:12: error: expected expression before
‘_Static_assert’
../../mpi/libmpiwrap.c:366:39: error: expected expression before ‘:’ token
  366 |       case MPI_COMBINER_STRUCT_INTEGER: fprintf(f,
"STRUCT_INTEGER"); break;
      |                                       ^
../../mpi/libmpiwrap.c: In function ‘extentOfTy’:
../../mpi/libmpiwrap.c:462:8: warning: implicit declaration of
function ‘PMPI_Type_extent’; did you mean ‘MPI_Type_extent’?
[-Wimplicit-function-declaration]
  462 |    r = PMPI_Type_extent(ty, &n);
      |        ^~~~~~~~~~~~~~~~
      |        MPI_Type_extent
In file included from ../../mpi/libmpiwrap.c:116:
../../mpi/libmpiwrap.c: In function ‘walk_type’:
../../mpi/libmpiwrap.c:736:17: error: expected expression before
‘_Static_assert’
  736 |       if (ty == MPI_LB || ty == MPI_UB)

-- 
Derrick McKee
Phone: (703) 957-9362
Email: der...@gm...

[Valgrind-users] Invalid read optimized build false positive

[Volker W. <vol...@gm...>]

Hello,

Valgrind reports "invalid read" in my program, but only if I compile it
with -O3 and not if I compile it with -O2, -O1 or -O0. The -g option
doesn't change this. Is it possible that valgrind reports false
positives if the -O3 option is used? If yes, how can I confirm this
message is indeed a false positive?

I couldn't find anything in the documentation except for this quote from
https://valgrind.org/docs/manual/quick-start.html:

Compile your program with |-g| to include debugging information so that
Memcheck's error messages include exact line numbers. Using |-O0| is
also a good idea, if you can tolerate the slowdown. With |-O1| line
numbers in error messages can be inaccurate, although generally speaking
running Memcheck on code compiled at |-O1| works fairly well, and the
speed improvement compared to running |-O0| is quite significant. Use of
|-O2| and above is not recommended as Memcheck occasionally reports
uninitialised-value errors which don't really exist.

But here, they only talk about uninitialised-value's and not about
invalid-reed's.


Greetings

Volker Weißmann