valgrind-users — General discussion list for Valgrind users

Re: [Valgrind-users] New user and first problem

[Patrick B. <Pat...@le...>]

Le 18/05/2020 à 19:48, Julian Seward a écrit :
>
>> Program received signal SIGILL: Illegal instruction.
>>
>> Backtrace for this error:
>> vex amd64->IR: unhandled instruction bytes: 0x62 0xF1 0xFD 0x8 0x6F 0x5
>> 0x25 0xA8 0x18 0x0
>> vex amd64->IR:   REX=0 REX.W=0 REX.R=0 REX.X=0 REX.B=0
>> vex amd64->IR:   VEX=0 VEX.L=0 VEX.nVVVV=0x0 ESC=NONE
>> vex amd64->IR:   PFX.66=0 PFX.F2=0 PFX.F3=0
>> ==377969== valgrind: Unrecognised instruction at address 0xabf9581.
>> ==377969==    at 0xABF9581: opal_pointer_array_construct (in
>> /opt/openmpi-GCC73/v3.1.x-20181010/lib/libopen-pal.so.40.10.3)
>
> It sounds like there's an instruction in libopen-pal.so.40.10.3 that
> Valgrind doesn't like.  What CPU does the machine have?
>
> J

Hi Julian,*This machine is a fat node with 4  Intel Xeon Gold 6148 (20
cores each):

vendor_id     : GenuineIntel
cpu family    : 6
model         : 85
model name    : Intel(R) Xeon(R) Gold 6148 CPU @ 2.40GHz
stepping      : 4
microcode     : 0x2000064
cpu MHz       : 2400.000
cache size    : 28160 KB
physical id   : 3
siblings      : 40
core id       : 26
cpu cores     : 20
apicid        : 245
initial apicid : 245
fpu           : yes
fpu_exception : yes
cpuid level   : 22
wp            : yes
flags         : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall
nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good
nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64
monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid dca
sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c
rdrand lahf_lm abm 3dnowprefetch epb cat_l3 cdp_l3 invpcid_single
intel_ppin intel_pt ssbd mba ibrs ibpb stibp tpr_shadow vnmi
flexpriority ept vpid fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms
invpcid rtm cqm mpx rdt_a avx512f avx512dq rdseed adx smap clflushopt
clwb avx512cd avx512bw avx512vl xsaveopt xsavec xgetbv1 cqm_llc
cqm_occup_llc cqm_mbm_total cqm_mbm_local dtherm ida arat pln pts pku
ospke md_clear spec_ctrl intel_stibp flush_l1d
bogomips      : 4806.68
clflush size  : 64
cache_alignment : 64
address sizes : 46 bits physical, 48 bits virtual

Re: [Valgrind-users] New user and first problem

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

On 18/05/2020 18:48, Julian Seward wrote:
> 
>> Program received signal SIGILL: Illegal instruction.
>>
>> Backtrace for this error:
>> vex amd64->IR: unhandled instruction bytes: 0x62 0xF1 0xFD 0x8 0x6F 0x5
>> 0x25 0xA8 0x18 0x0
>> vex amd64->IR:   REX=0 REX.W=0 REX.R=0 REX.X=0 REX.B=0
>> vex amd64->IR:   VEX=0 VEX.L=0 VEX.nVVVV=0x0 ESC=NONE
>> vex amd64->IR:   PFX.66=0 PFX.F2=0 PFX.F3=0
>> ==377969== valgrind: Unrecognised instruction at address 0xabf9581.
>> ==377969==    at 0xABF9581: opal_pointer_array_construct (in
>> /opt/openmpi-GCC73/v3.1.x-20181010/lib/libopen-pal.so.40.10.3)
> 
> It sounds like there's an instruction in libopen-pal.so.40.10.3 that
> Valgrind doesn't like.  What CPU does the machine have?

0x62 is an EVEX prefix from the AVX512 extensions, so isn't
supported yet.

Tom

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

Re: [Valgrind-users] New user and first problem

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

> Program received signal SIGILL: Illegal instruction.
> 
> Backtrace for this error:
> vex amd64->IR: unhandled instruction bytes: 0x62 0xF1 0xFD 0x8 0x6F 0x5
> 0x25 0xA8 0x18 0x0
> vex amd64->IR:   REX=0 REX.W=0 REX.R=0 REX.X=0 REX.B=0
> vex amd64->IR:   VEX=0 VEX.L=0 VEX.nVVVV=0x0 ESC=NONE
> vex amd64->IR:   PFX.66=0 PFX.F2=0 PFX.F3=0
> ==377969== valgrind: Unrecognised instruction at address 0xabf9581.
> ==377969==    at 0xABF9581: opal_pointer_array_construct (in
> /opt/openmpi-GCC73/v3.1.x-20181010/lib/libopen-pal.so.40.10.3)

It sounds like there's an instruction in libopen-pal.so.40.10.3 that
Valgrind doesn't like.  What CPU does the machine have?

J

[Valgrind-users] New user and first problem

[Patrick B. <Pat...@le...>]

Hi,


I'm new to valgrind. My goal is to investigate a possible memory problem
in a large parallel MPI+OpenMP code.

I've cloned Valgrind from git and built it with GCC7.3 and fortran 3.1
for mpicc (my application is built with the same environment). I'm using
these 2 options:

--enable-only64bit --with-mpicc=$(which mpicc)

"mpirun -np 8 my_application" is working on my fat node (just to have
few processes for the test, I use nearly 60GB of RAM over more than
1TB). It fails after some tenth of iterations.

"mpirun -np 8 valgrind /bin/hostname" works too. So Valgrind seams
working with MPI 3.1 compiled with GCC7.3.

But "mpirun -np 8 valgrind ./my_application" immediately fails with:

Program received signal SIGILL: Illegal instruction.

Backtrace for this error:
vex amd64->IR: unhandled instruction bytes: 0x62 0xF1 0xFD 0x8 0x6F 0x5
0x25 0xA8 0x18 0x0
vex amd64->IR:   REX=0 REX.W=0 REX.R=0 REX.X=0 REX.B=0
vex amd64->IR:   VEX=0 VEX.L=0 VEX.nVVVV=0x0 ESC=NONE
vex amd64->IR:   PFX.66=0 PFX.F2=0 PFX.F3=0
==377969== valgrind: Unrecognised instruction at address 0xabf9581.
==377969==    at 0xABF9581: opal_pointer_array_construct (in
/opt/openmpi-GCC73/v3.1.x-20181010/lib/libopen-pal.so.40.10.3)
==377969==    by 0xAC1BA78: mca_base_var_init (in
/opt/openmpi-GCC73/v3.1.x-20181010/lib/libopen-pal.so.40.10.3)
==377969==    by 0xABFDE39: opal_init_util (in
/opt/openmpi-GCC73/v3.1.x-20181010/lib/libopen-pal.so.40.10.3)
==377969==    by 0x911AD60: ompi_mpi_init (in
/opt/openmpi-GCC73/v3.1.x-20181010/lib/libmpi.so.40.10.3)
==377969==    by 0x914BB34: PMPI_Init_thread (in
/opt/openmpi-GCC73/v3.1.x-20181010/lib/libmpi.so.40.10.3)
==377969==    by 0x8E97C1F: MPI_INIT_THREAD (in
/opt/openmpi-GCC73/v3.1.x-20181010/lib/libmpi_mpifh.so.40.11.2)
==377969==    by 0x543066: __mpi_m_MOD_init_mpi (mpi_m.f90:140)
==377969==    by 0x411447: __yales2_m_MOD_init_yales2_env (yales2_m.f90:511)
==377969==    by 0x411595: __yales2_m_MOD_run_yales2 (yales2_m.f90:378)
==377969==    by 0x40B9E0: MAIN__ (3D_cylinder.f90:20)
==377969==    by 0x40B9E0: main (3D_cylinder.f90:8)
==377969== Your program just tried to execute an instruction that Valgrind
==377969== did not recognise.  There are two possible reasons for this.
==377969== 1. Your program has a bug and erroneously jumped to a non-code
==377969==    location.  If you are running Memcheck and you just saw a
==377969==    warning about a bad jump, it's probably your program's fault.
==377969== 2. The instruction is legitimate but Valgrind doesn't handle it,
==377969==    i.e. it's Valgrind's fault.  If you think this is the case or
==377969==    you are not sure, please let us know and we'll try to fix it.
==377969== Either way, Valgrind will now raise a SIGILL signal which will
==377969== probably kill your program.

May be I've missed something ?

I'm using master branch. The branch VALGRIND_3_16_BRANCH that I have
tested do not build:

make: ***  Aucune règle pour fabriquer la cible « exp-sgcheck.supp »,
nécessaire pour « default.supp ». Arrêt.

Thanks for your help

Patrick

Re: [Valgrind-users] HELP/Hint: valgrind error message

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

> Below is the error coming when running valgrind , Do not know how to tackle it

> valgrind --tool=memcheck  ./lte_tr069
> ==6660==
> ==6660== Warning: Can't execute setuid/setgid/setcap executable: ./lte_tr069
> ==6660== Possible workaround: remove --trace-children=yes, if in effect
> ==6660==
> valgrind: ./lte_tr069: Permission denied

READ THE Warning MESSAGE.  It says *EXACTLY* what the problem is.
./lte_tr069 has one of the attributes setuid, or setgid, or setcap.
If you're clever enough to set such an attribute then you should
be clever enough to deal with the complaint from valgrind/memcheck.

Re: [Valgrind-users] HELP/Hint: valgrind error message

[Kunal C. <atk...@gm...>]

Hi  Team,

1. I have created a simple  program ./a.out and make a check
if(RUNNING_ON_VALGRIND) but still same error is coming.

2. I am trying to run ./a.out on arm board as it is compile for it also
valgrind is running there only

Thanks
Kunal


On Fri, May 15, 2020 at 2:51 PM Paul FLOYD <pj...@wa...> wrote:

>
>
> > Message du 15/05/20 10:22
> > De : "Kunal Chauhan"
>
>
> > ==6660== Warning: Can't execute setuid/setgid/setcap executable:
> ./lte_tr069
> > ==6660== Possible workaround: remove --trace-children=yes, if in effect
> > ==6660==
> > valgrind: ./lte_tr069: Permission denied
>
>
> Hi
>
> The problem is that your application (or something that your application
> is executing) is trying to switch user, group or capabilities. This is
> likely to interfere with the workings of Valgrind. As an
> example of this, Valgrind often needs to open new log files. This may fail
> if Valgrind has switched user/group/caps.
>
> This is more likely to happen if you are running Valgrind on a wrapper
> script and using the --trace-children=yes. For instance you might be on a
> system where utilities like 'basename' and
> 'dirname' are security hardened. If they are used in your wrapper this
> could result in the problem you are seeing.
>
> Alternatively, if you are not using a wrapper, then the best workaround is
> to have some special Valgrind handling in your executable. See
> http://valgrind.org/docs/manual/manual-core-
> adv.html#manual-core-adv.clientreq
> <http://valgrind.org/docs/manual/manual-core-adv.html#manual-core-adv.clientreq>
>
> So you could write some code like
>
> if (!RUNNING_ON_VALGRIND)
> {
> // your setcap calls
> }
>
> A+
> Paul
>
>
>
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>


-- 
*Thanks with Regards!*

*Kunal Chauhan*
*Mob:09813614826*
*Mob:08860397903*

*E-mail:atk...@gm... <E-mail%3Aa...@gm...>*

Re: [Valgrind-users] HELP/Hint: valgrind error message

[Paul F. <pj...@wa...>]

 
> Message du 15/05/20 10:22
> De : "Kunal Chauhan" 


> ==6660== Warning: Can't execute setuid/setgid/setcap executable: ./lte_tr069
> ==6660== Possible workaround: remove --trace-children=yes, if in effect
> ==6660==
> valgrind: ./lte_tr069: Permission denied


Hi

The problem is that your application (or something that your application is executing) is trying to switch user, group or capabilities. This is likely to interfere with the workings of Valgrind. As an 
example of this, Valgrind often needs to open new log files. This may fail if Valgrind has switched user/group/caps. 

This is more likely to happen if you are running Valgrind on a wrapper script and using the --trace-children=yes. For instance you might be on a system where utilities like 'basename' and 
'dirname' are security hardened. If they are used in your wrapper this could result in the problem you are seeing.

Alternatively, if you are not using a wrapper, then the best workaround is to have some special Valgrind handling in your executable. See http://valgrind.org/docs/manual/manual-core-
adv.html#manual-core-adv.clientreq

So you could write some code like

if (!RUNNING_ON_VALGRIND)
{
// your setcap calls
}

A+
Paul

[Valgrind-users] HELP/Hint: valgrind error message

[Kunal C. <atk...@gm...>]

Hi Team,

Below is the error coming when running valgrind , Do not know how to tackle
it
.............................

valgrind --tool=memcheck  ./lte_tr069

==6660==

==6660== Warning: Can't execute setuid/setgid/setcap executable: ./lte_tr069

==6660== Possible workaround: remove --trace-children=yes, if in effect

==6660==

valgrind: ./lte_tr069: Permission denied

-- 
*Thanks with Regards!*

*Kunal Chauhan*
*Mob:09813614826*
*Mob:08860397903*

*E-mail:atk...@gm... <E-mail%3Aa...@gm...>*

Re: [Valgrind-users] Spurious errors during an abrupt program termination

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

On 5/14/20, Dalon Work wrote:

> I have an application with two threads on linux which I was testing
> under valgrind. We have a strange memory behavior that is leading to
> an internal assert terminating the application, hence the
> investigation. After running the application, I have many, many
> errors, (invalid reads and writes), which all follow a similar
> pattern:
> 
> Invalid read/write of size 4:
>      at thread1_func()
>      at thread1_func1()
>      ...

The rule for dealing with output from memcheck is:
    Fix the first complaint.  Do not ignore it; FIX IT.
Many times the command-line option --track-origins=yes provides helpful clues.

> Address 0x##### is ##### bytes inside a block of size #### free'd
>      free()
>      myAllocator::~myAllocator()
>      __run_exit_handlers
>      exit
>      terminate_handler_sp
>      thread2_func()
>      thread2_func1()
>      ...
> 
> The call stack from the free() stack is obviously from the second
> thread (NOT the one that started the error, oddly enough), while the
> invalid read is from the first thread.

Based on this evidence, the most likely scenario is thread2 decided to
(or was forced to) terminate, and started running exit handlers
for the whole process.  Meanwhile, thread1 continues running (thread1
has received no news that it should stop) and references blocks that
have been free()d by the termination handlers invoked by thread2.
So the termination handler should first rendezvous with all threads
before beginning to shutdown the process.

[Valgrind-users] Spurious errors during an abrupt program termination

[Dalon W. <dw...@gm...>]

I have a quick question that hopefully those more knowledgeable in
linux can help me with.

I have an application with two threads on linux which I was testing
under valgrind. We have a strange memory behavior that is leading to
an internal assert terminating the application, hence the
investigation. After running the application, I have many, many
errors, (invalid reads and writes), which all follow a similar
pattern:

Invalid read/write of size 4:
    at thread1_func()
    at thread1_func1()
    ...
Address 0x##### is ##### bytes inside a block of size #### free'd
    free()
    myAllocator::~myAllocator()
    __run_exit_handlers
    exit
    terminate_handler_sp
    thread2_func()
    thread2_func1()
    ...

The call stack from the free() stack is obviously from the second
thread (NOT the one that started the error, oddly enough), while the
invalid read is from the first thread.

Anyway, the way I'm interpreting this is that the first thread starts
the abort process. The second thread catches the signal and starts
destroying the static objects, which frees memory, and somehow the
first thread keeps going and causes all sorts of spurious memory
errors?

I guess another possibility is that at some point the second thread
really did tear everything down at some point and the first thread
really did just charge ahead not knowing about it. My linux-fu is not
at expert-level yet (Just a yellow-belt, really), so I'd appreciate
any thoughts on what could be going on and how to continue with the
debugging process.

Dalon

Re: [Valgrind-users] Load a shared library into client address space

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

> Is there some way that I can load a shared library into the client
> address space?  I am trying to do some dynamic analysis on shared
> libraries, and I would like to have the dynamic loader load a
> specified shared library into the client to run my analysis.

Have main() of the valgrind app (memcheck, drd, etc.) set the environment
variable LD_PRELOAD before invoking the PT_INTERP of the app-under-test.
This is the same as invoking the app-under-test with the bash-shell command line:
     LD_PRELOAD=/path/to/the/shared/library  app-under-test  args...
except that valgrind will supervise the execution.

In many cases setting LD_PRELOAD "commutes with" (can be set before) invoking valgrind:
     LD_PRELOAD=/path/to/the/shared/library  valgrind  app-under-test  args...
as long as the shared library does not interfere with valgrind or
any shared library that already is used by valgrind (typically, libc).

There may be complications if the app-under-test invokes child process(es).
The LD_PRELOAD will propagate to the child(ren).

[Valgrind-users] Load a shared library into client address space

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

Hi,

Is there some way that I can load a shared library into the client
address space?  I am trying to do some dynamic analysis on shared
libraries, and I would like to have the dynamic loader load a
specified shared library into the client to run my analysis.
Alternatively, I could write a small program that just calls dlopen(),
but then I would need a way to track the dlopen() call.  Any ideas?
Thanks.

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

Re: [Valgrind-users] opcode question

[Mark R. <ma...@cs...>]

Also Iop_CmpNEZ128x1

-----Original Message-----
From: Mark Roberts [mailto:ma...@cs...]
Sent: Monday, April 13, 2020 5:33 PM
To: val...@li...
Subject: opcode question

In memcheck/mc_translate.c I notice that:
Iop_RndF128
Iop_I64UtoF32
are case statement labels in both expr2vbits_Unop and expr2vbits_Binop.

Is that intentional? And if so, why?

Thank you,
Mark Roberts

[Valgrind-users] opcode question

[Mark R. <ma...@cs...>]

In memcheck/mc_translate.c I notice that:
Iop_RndF128
Iop_I64UtoF32
are case statement labels in both expr2vbits_Unop and expr2vbits_Binop.

Is that intentional? And if so, why?

Thank you,
Mark Roberts

[Valgrind-users] Cachegrind not writing on exit

[Han-Wen N. <ha...@gm...>]

Hi there,

I'm trying to use cachegrind on LilyPond. For some reason, cachegrind
starts, but never finalizes its output: there is no summary, and there
is output file.

Where can I start diagnosing this?  I have no trouble running valgrind
on LilyPond.

thanks!


$ valgrind --tool=cachegrind lilypond --help
=1163922== Cachegrind, a cache and branch-prediction profiler
==1163922== Copyright (C) 2002-2017, and GNU GPL'd, by Nicholas
Nethercote et al.
==1163922== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info
==1163922== Command: /home/hanwen/bin//lilypond --help
==1163922==
--1163922-- warning: L3 cache found, using its data for the LL simulation.
Usage: lilypond [OPTION]... FILE...
..

You found a bug? Please read https://lilypond.org/bug-reports.html

$


-- 
Han-Wen Nienhuys - ha...@gm... - http://www.xs4all.nl/~hanwen

[Valgrind-users] Translated instruction doesn't get executed

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

Hi,

I am writing a new tool that involves calling a tool function at every
instruction.  However, there appears to be one instruction that never
gets executed, and I cannot figure out why.  The (partial)
instrumented IRSB is as follows:

------ IMark(0x112E42, 5, 0) ------
   DIRTY 1:I1 RdFX-gst(0,928) ::: record_current_state{0x58001ce0}(0x112E42:I64)
   t68 = Sub64(t2,0x8:I64)
   PUT(48) = t68
   STle(t68) = 0x112E47:I64
   t70 = Sub64(t68,0x80:I64)
   ====== AbiHint(t70, 128, 0x124A10:I64) ======
   ------ IMark(0x124A10, 1, 0) ------
   DIRTY 1:I1 RdFX-gst(0,928) ::: record_current_state{0x58001ce0}(0x124A10:I64)
   t79 = Sub64(t68,0x8:I64)
   PUT(48) = t79
   STle(t79) = t22
   PUT(184) = 0x124A11:I64
   ------ IMark(0x124A11, 3, 0) ------
   DIRTY 1:I1 RdFX-gst(0,928) ::: record_current_state{0x58001ce0}(0x124A11:I64)
   PUT(56) = t79
   PUT(184) = 0x124A14:I64
   ------ IMark(0x124A14, 4, 0) ------
   DIRTY 1:I1 RdFX-gst(0,928) ::: record_current_state{0x58001ce0}(0x124A14:I64)
   t82 = Add64(t79,0xFFFFFFFFFFFFFFF8:I64)
   STle(t82) = t64
   PUT(184) = 0x124A18:I64

The instruction that doesn't get executed is 0x124A10.  There are two
reasons I say the instruction is not executed.  First, I am printing
out the guest IP in record_current_state() and 0x124A10 is never
printed.  Second, I get a segfault at instruction 0x124A14, which
dereferences a stack location.  I have checked read/write permissions
of the location referenced in the STle IRStmt, and sure enough the
location is not valid for the guest.  This leads me to believe that
the t79=Sub64(t68, 0x8) isn't happening, because that should update
the memory permissions.

Interestingly, instruction 0x112E42 seemingly gets executed twice,
according to my instrumentation output:

==273360== Recording state for 0x112e42 (quote_name_buf)
==273360== Recording state for 0x112e42 (quote_name_buf)
==273360== Recording state for 0x124a11 (get_quoting_style)

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

Re: [Valgrind-users] PowerPC undefined symbol _restgpr_30_x

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

I found that the restgpr symbols were being included because I was
configuring crosstool-NG with CT_CC_GCC_ENABLE_TARGET_OPTSPACE, which
compiles gcc libs with "-Os". I rebuilt the toolchain without this
option and Valgrind no longer complains about missing symbols or
unrecognized instructions. The size of the complete board image barely
changed, so I think I can just leave the toolchain like this and
successfully use Valgrind.



On Sun, Mar 22, 2020 at 11:35 PM Alan Corey <ala...@gm...> wrote:
>
> 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.

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...
> 
>