valgrind-users — General discussion list for Valgrind users

[Valgrind-users] RFC: changing Cachegrind default to `--cache-sim=no`

[Nicholas N. <n.n...@gm...>]

Hi,

Cachegrind has an option `--cache-sim`.

If you run with `--cache-sim=yes` (the default) it tells it Cachegrind to
do a full cache simulation with lots of events: Ir, I1mr, ILmr, Dr, D1mr,
DLmr, Dw, D1mw, DLmw.

If you run with `--cache-sim=no` then the cache simulation is disabled and
you just get one event: Ir. (This is "instruction cache reads", which is
equivalent to "instructions executed".)

I have been using `--cache-sim=no` almost exclusively for a long time. The
cache simulation done by Valgrind is an approximation of the memory
hierarchy of a 2002 AMD Athlon processor. Its accuracy for a modern memory
hierarchy with three levels of cache, prefetching, non-LRU replacement, and
who-knows-what-else is likely to be low. If you want to accurately know
about cache behaviour you'd be much better off using hardware counters via
`perf` or some other profiler.

But `--cache-sim=no` is still very useful because instruction execution
counts are still very useful.

Therefore, I propose changing the default to `--cache-sim=no`. Does anyone
have any objections to this?

Thanks.

Nick

Re: [Valgrind-users] about a stack fill option (as for malloc-fill and free-fill)

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

On 29-03-23 04:41, John Reiser wrote:
>>>      Could it be possible to add an option like --heap-up-fill 
>>> --heap-down-fill (like for stack with malloc), that fills heap memory 
>>> with a specified values (when entering a function and leave a function)?
> 
>> tl;dr 2
>>
>> See
>> https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2723r0.html
> 
> The value zero is the worst possible value to use for such initialization,
> from the viewpoint of quickly producing better software by discovering
> and identifying bugs sooner.  Using the value zero tends to hide many bugs.
> 
> A much better value is 0x8181...81.  This value is non-zero, odd, negative
> as a signed integer, a very unlikely floating-point value, very often
> not a valid pointer value, and instantly recognizable in any dump of 
> memory.
> It was used to great success as the "core constant" (the value of 
> uninitialized
> RAM) by the Michigan Terminal System for IBM 360/67 and successors,
> from the early 1970s (50 years ago!) until the demise of MTS around 2000.

Hi John

The value 0 isn't all bad.

I quite often write code that uses enums that start with KIND_INVALID so 
then I can write asserts like assert(kind != KIND_INVALID);

0 is also the NULL pointer so if your code defends against NULL it will 
at least not crash. I agree with you about early detection of errors - 
in a previous job we had loads of "pass the parcel" code that just 
ignored errors and returned from functions without reporting an error. 
It was a nightmare to debug,

The value used with 'pattern' is 0xAA which isn't too bad either - 
fairly well known as being a test pattern.

A+
Paul

Re: [Valgrind-users] about a stack fill option (as for malloc-fill and free-fill)

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

>>      Could it be possible to add an option like --heap-up-fill --heap-down-fill (like for stack with malloc), that fills heap memory with a specified values (when entering a function and leave a function)?

> tl;dr 2
> 
> See
> https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2723r0.html

The value zero is the worst possible value to use for such initialization,
from the viewpoint of quickly producing better software by discovering
and identifying bugs sooner.  Using the value zero tends to hide many bugs.

A much better value is 0x8181...81.  This value is non-zero, odd, negative
as a signed integer, a very unlikely floating-point value, very often
not a valid pointer value, and instantly recognizable in any dump of memory.
It was used to great success as the "core constant" (the value of uninitialized
RAM) by the Michigan Terminal System for IBM 360/67 and successors,
from the early 1970s (50 years ago!) until the demise of MTS around 2000.

[Valgrind-users] RFC: proposal to remove user annotation from `cg_annotate`

[Nicholas N. <n.n...@gm...>]

Hi,

I recently rewrote `cg_annotate`, `cg_diff`, and `cg_merge` in Python. The
old versions were written in Perl, Perl, and C, respectively. The new
versions are much nicer and easier to modify, and I have various ideas for
improving `cg_annotate`. This email is about one of those ideas.

A typical way to invoke `cg_annotate` is like this:

> cg_annotate cachegrind.out.12345

This implies `--auto=yes`, which requests line-by-line "auto-annotation" of
source files. I.e. `cg_annotate` will automatically annotate all files in
the profile that meet the significance threshold.

It's also possible to do something like this:

> cg_annotate --auto=no cachegrind.out.12345 a.c b.c

Which instead requests "user annotation" of the files `a.c` and `b.c`.

My thesis is that auto-annotation suffices in practice for all reasonable
use cases, and that user annotation is unnecessary and can be removed.

When I first wrote `cg_annotate` in 2002, only user annotation was
implemented. Shortly after, I added the `--auto={yes,no}` option. Since
then I've never used user annotation, and I suspect nobody else has either.
User annotation is ok when dealing with tiny programs, but as soon as you
are profiling a program with more than a handful of source files it becomes
impractical.

The only possible use cases I can think of for user annotation are as
follows.

   - If you want to see a particular file(s) annotated but you don't want
   to see any others, then you can use user annotation in combination with
   `--auto=no`. But it's trivial to search through the output for the
   particular file, so this doesn't seem important.
   - If the path to a file is somehow really messed up in the debug info,
   it might be possible that auto-annotation would fail to find it, but user
   annotation could find it, possibly in combination with `-I`. But this seems
   unlikely. Some basic testing shows that gcc, clang and rustc all default to
   using full paths in debug info. gcc supports `-fdebug-prefix-map` but that
   seems to mostly be used for changing full paths to relative paths, which
   will still work fine.

Removing user annotation would (a) simplify the code and docs, and (b)
enable the possibility of moving the merge functionality from `cg_merge`
into `cg_annotate`, by allowing the user to specify multiple cachegrind.out
files as input.

So: is anybody using user annotation? Does anybody see any problems with
this proposal?

Thanks.

Nick

Re: [Valgrind-users] about a stack fill option (as for malloc-fill and free-fill)

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

On 28-03-23 11:40, Julien Allali wrote:
> Hi,
> 
>      Sometimes, valgrind detects error like "Conditional jump or move 
> depends" or "Use of uninitialized value" related to a variable in heap. 
> When using with gdb (--vgdb-error=1), a newbie (i.e. my students) can 
> have difficulties to understand as the value stored is 0 (because there 
> was zeros in heap, not because we set 0 to the variable).
> 
>      Could it be possible to add an option like --heap-up-fill 
> --heap-down-fill (like for stack with malloc), that fills heap memory 
> with a specified values (when entering a function and leave a function)?
> 
> Would it be complicated to implement?


Hi

tl;dr

I recommend using the vgdb monitor commands, they show what memcheck 
considers initialized or not. You just have to type something like

"memcheck monitor xb &var sizeof(var)"


tl;dr 2

See
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2723r0.html





Having a "stack  fill" in Valgrind would be very difficult. The problem 
is identifying exactly what is a stack allocation. Identifying a call to 
malloc is easy - we have the address of the function. Stack allocation 
is, roughly, just modifying the stack pointer.


The simplest case is where the callee does the stack allocation, on 
amd64 something like


   201910:       55                      push   %rbp
   201911:       48 89 e5                mov    %rsp,%rbp
   201914:       48 83 ec 10             sub    $0x10,%rsp


where the constant in the last line depends on the amount being 
allocated.  The initial push and move won't be there for optimized 
builds or if -fomit-frame-pointer is specified.

If the compiler is doing RVO then the stack memory will be allocated by 
the caller. See here

https://godbolt.org/z/qasjWGhsK

Line 25 in the asm output is where main allocates the space on the stack.

Then there is tail-call optimization where there is no call, just a jump 
to the callee. And then all of the other things that manipulate the 
stack pointer (alloca, C++ exceptions, signals, setjmp/longjmp). There 
are a few compiler options that affect stack use. On top of all that 
each compiler tends to do things differently.

I don't know what would be possible with DWARF, but that would only work 
with debug builds.

Going back to my second tl;dr

If I compile the godbolt example with

clang++-devel -ftrivial-auto-var-init=pattern jfb.cpp -o jfb

(that's LLVM 16)

then I get

   2019a2:       be aa 00 00 00          mov    $0xaa,%esi
   2019a7:       ba 00 10 00 00          mov    $0x1000,%edx
   2019ac:       e8 bf 00 00 00          call   201a70 <memset@plt>
   2019b1:       48 8d bd 00 f0 ff ff    lea    -0x1000(%rbp),%rdi
   2019b8:       e8 73 ff ff ff          call   201930 <_Z1fv>

which is the caller filling the 4k with 0xaa.



A+
Paul

[Valgrind-users] about a stack fill option (as for malloc-fill and free-fill)

[Julien A. <jul...@en...>]

Hi,

	Sometimes, valgrind detects error like "Conditional jump or move 
depends" or "Use of uninitialized value" related to a variable in heap. 
When using with gdb (--vgdb-error=1), a newbie (i.e. my students) can 
have difficulties to understand as the value stored is 0 (because there 
was zeros in heap, not because we set 0 to the variable).
	
	Could it be possible to add an option like --heap-up-fill 
--heap-down-fill (like for stack with malloc), that fills heap memory 
with a specified values (when entering a function and leave a function)?

Would it be complicated to implement?

thanks :)
Julien.

Re: [Valgrind-users] valgrind exits with an error when using mmap (mmap mdev device)

[Floyd, P. <pj...@wa...>]

On 15/03/2023 02:22, 骤变成玄武 via Valgrind-users wrote:
> 2  Problem description:
> -- source code:   mmap a mdev device
>
What i usually do is run pmap -x on the guest exe running standalong 
(adding a "sleep" if ncessary) and then running valgrind -d.

That should give you memory maps that you can compare.


A+

Paul

[Valgrind-users] valgrind exits with an error when using mmap (mmap mdev device)

[<101...@qq...>]

1  version:
    valgrind-3.20.0
    4.19.25-200.el7.bclinux.x86_64
    gcc version 4.8.5 20150623 (Red Hat 4.8.5-36) 
2  Problem description:
-- source code:   mmap a mdev device

static int test_mmap_bar(void)
{
    const char *path="/sys/class/mdev_bus/0000:06:00.0/resource4";
    ...
    flags = O_RDWR;
    prot = PROT_READ | PROT_WRITE;
    unsigned long len = 4096;
    unsigned long offset = 0x320000;
    fd = open(path, flags | O_SYNC);
&nbsp; &nbsp; if (fd < 0) {
&nbsp; &nbsp; &nbsp; &nbsp; printf("[ERROR] open device err\n");
&nbsp; &nbsp; &nbsp; &nbsp; return -1;
&nbsp; &nbsp; }
&nbsp; &nbsp; addr = mmap(0, len, prot, MAP_SHARED, fd, offset);
&nbsp; &nbsp; if (addr == P_FAILED) {
&nbsp; &nbsp; &nbsp; &nbsp; printf("[ERROR] mmap faild\n");
&nbsp; &nbsp; }
...
}


--run with valgrind : 
&nbsp; &nbsp; &nbsp;valgrind --leak-check=full --show-leak-kinds=all -v --log-file=valgrind.log ./build/valgrind-test --base-virtaddr=0x4000000000
-- The valgrind log reported the following error with mmap：
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;valgrind: m_debuginfo/image.c:587 (set_CEnt): Assertion '! sr_isError(sr)' failed.
--strace valgrind:
&nbsp; &nbsp; 
&nbsp; &nbsp; open("/sys/class/mdev_bus/0000:06:00.0/resource4", O_RDWR|O_SYNC) = 94&nbsp; &nbsp; rt_sigprocmask(SIG_SETMASK, ~[ILL TRAP BUS FPE KILL SEGV STOP SYS], NULL, 8) = 0
&nbsp; &nbsp; gettid()&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; = 13758
&nbsp; &nbsp; read(1028, "Y", 1)&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; = 1
&nbsp; &nbsp; mmap(0x4033000, 4096, PROT_READ|PROT_WRITE, MAP_SHARED|MAP_FIXED, 94, 0x320000) = 0x4033000
&nbsp; &nbsp; syscall_332(0x5e, 0x58246543, 0x1000, 0xfff, 0x1003633aa0, 0) = 0
&nbsp; &nbsp; readlink("/proc/self/fd/94", "/sys/devices/pci0000:00/0000:00:"..., 4096) = 59
&nbsp; &nbsp; syscall_332(0xffffffffffffff9c, 0x597789da, 0, 0xfff, 0x10036346d0, 0) = 0
&nbsp; &nbsp; syscall_332(0x5e, 0x58246543, 0x1000, 0xfff, 0x1003634560, 0) = 0
&nbsp; &nbsp; pread64(94, 0x100299acd0, 8192, 0)&nbsp; &nbsp; &nbsp; = -1 EIO (Input/output error)
&nbsp; 
valgrind will do pread64&nbsp; after mmap ??




4&nbsp; run directly:
-- There is no problem with mmap
-- use pread64(..)&nbsp; will cause io error


5&nbsp; Quesions:
&nbsp; &nbsp; &nbsp; &nbsp;How can I use valgrind in this case

[Valgrind-users] Dependency issue with apt install Valgrind in Ubuntu Mate distro

[Jake H. <jak...@gm...>]

Hello experts,
I would like to start using Valgrind in my Ubunt Mate Linux distro.
Therefore I just ran the following terminal command:
sudo apt install valgrind

it didn't work as expected, here is the output:
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 libc6-i386 : Depends: libc6 (= 2.35-0ubuntu3) but 2.35-0ubuntu3.1 is to be
installed
E: Unable to correct problems, you have held broken packages.

Anyone did already faced the same issue? Can it be solved with a workaround?
Thank you in advance for your help!

Re: [Valgrind-users] Compilation fails on ARM

[Leon P. <leo...@gm...>]

Yes, you are right, John.
The error message comes from glibc, but I didn't look in this direction.

For those coming after me with this task, below is the way to do this. To
cross-compile Valgrind 3.20.0 I used the following script:

export CC=arm-linux-gnueabihf-gcc
export CXX=arm-linux-gnueabihf-g++
export CCFLAGS="-mcpu=cortex-a8 -mfpu=neon"
export LDFLAGS="
-Wl,--rpath=/lib/glibc.2.23,--dynamic-linker=/lib/glibc.2.23/ld-linux-armhf.so.3"
./configure --host=armv7-linux-gnueabihyf
--target=armv7-linux-gnueabihf --prefix=/opt/FS_HDVR/opt
make
make install

When this finished successfully, I need to run the following command to
execute MyApp under Valgrind:
export VALGRIND_LIB=/opt/libexec/valgrind; /opt/bin/valgrind MyApp
Note that most probably (I am not sure) the glibc should correspond to the
cross-compiler in use.
Anyway, now I can run Valgrind with my application(s).


THANKS FOR THE HELP!

On Wed, 1 Mar 2023 at 00:02, John Reiser <jr...@bi...> wrote:

> On 2/28/2023, Leon Pollak wrote:
> > I recall my previous mail about cross-compilation.
> > When i did exactly what is recommended, I managed to cross-compile.
> > The unexpected issue appeared when I run wvalgrind myappw:
> > FATAL: kernel too old
> > My kernel is 2.6.37 and seemed to be ok.
> > Is it final or can I do something further? Old Valgrind version, for
> example?
>
> The string "kernel too old" does not appear in the sources for valgrind
> 3.20.0,
> nor in the current 3.21.0, nor in previous 3.19.0.  The substring "too old"
> likewise does not appear in the sources, except for configuration tests
> such as:
>   ./configure:  { $as_echo "$as_me:${as_lineno-$LINENO}: WARNING:
> 'missing' script is too old or missing" >&5
>
> So, which software wrote "FATAL: kernel too old"?  The utility 'strace'
> may help.
> Something like
>    strace -f -o strace.out -e trace=execve,write,writev,pwrite,pwritev
> wvalgrind myappw
> where 'execve' tells the command line for a given PID, and the
> 'write,writev,...'
> trace various system calls which write to file descriptors, reporting the
> associated
> process id PID.  Also run the 'strace' a second time with just the app,
> without valgrind.
> (By the way, what is the 'w' prefix and suffix in "wvalgrind myappw"?)
>
>
>
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>

Re: [Valgrind-users] Compilation fails on ARM

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

On 2/28/2023, Leon Pollak wrote:
> I recall my previous mail about cross-compilation.
> When i did exactly what is recommended, I managed to cross-compile.
> The unexpected issue appeared when I run wvalgrind myappw:
> FATAL: kernel too old
> My kernel is 2.6.37 and seemed to be ok.
> Is it final or can I do something further? Old Valgrind version, for example?

The string "kernel too old" does not appear in the sources for valgrind 3.20.0,
nor in the current 3.21.0, nor in previous 3.19.0.  The substring "too old"
likewise does not appear in the sources, except for configuration tests such as:
  ./configure:  { $as_echo "$as_me:${as_lineno-$LINENO}: WARNING: 'missing' script is too old or missing" >&5

So, which software wrote "FATAL: kernel too old"?  The utility 'strace' may help.
Something like
   strace -f -o strace.out -e trace=execve,write,writev,pwrite,pwritev  wvalgrind myappw
where 'execve' tells the command line for a given PID, and the 'write,writev,...'
trace various system calls which write to file descriptors, reporting the associated
process id PID.  Also run the 'strace' a second time with just the app, without valgrind.
(By the way, what is the 'w' prefix and suffix in "wvalgrind myappw"?)

Re: [Valgrind-users] Compilation fails on ARM

[Leon P. <leo...@gm...>]

Thank you, John for your humor...:-)))
This is ARMv7 (Cortex-A8) the TI TMS320DM8148 CPU with 1GB RAM and there is
no chance to switch to something else.
The Valgrind manual says that it supports Linux 2.6.31 and younger, 2.6.37
seems to be younger...:-)
Why are you so pessimistic...:-)

On Tue, 28 Feb 2023 at 22:44, John Reiser <jr...@bi...> wrote:

> On 2/28/2023, Leon Pollak wrote:
> > I recall my previous mail about cross-compilation.
> > When i did exactly what is recommended, I managed to cross-compile.
> > The unexpected issue appeared when I run wvalgrind myappw:
> > FATAL: kernel too old
> > My kernel is 2.6.37 and seemed to be ok.
> > Is it final or can I do something further? Old Valgrind version, for
> example?
> Stop.  Give it up.  Find something else to do.  If this is your job,
> then find a new job as soon as you can, so that you can quit this insanity.
>
> Even OpenWRT runs Linux 5.11.  It seems likely that your environment
> is some ARM (v4 or v5) embedded system that has an app with a horrendous
> bug
> that you are trying to find and fix.  Trying to do this natively, running
> such an old kernel and probably with severely limited RAM, is insane.
>
> Get a 4GB or 8GB Raspberry Pi running a current Debian or Fedora Linux,
> and debug the app there.  The Pi has GPIO, USB, Ethernet, camera, and
> dot-matrix display interfaces.  If there are other sensors on your
> device, then you should have hardware adapters so that they can use
> USB interfacing, so that you *can* use a Pi as a real-time development
> environment.  If your management won't spend the time or money to
> make or procure such adapters for the sensors, then there is *NO* hope.
>
>
>
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>

Re: [Valgrind-users] Compilation fails on ARM

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

On 2/28/2023, Leon Pollak wrote:
> I recall my previous mail about cross-compilation.
> When i did exactly what is recommended, I managed to cross-compile.
> The unexpected issue appeared when I run wvalgrind myappw:
> FATAL: kernel too old
> My kernel is 2.6.37 and seemed to be ok.
> Is it final or can I do something further? Old Valgrind version, for example?
Stop.  Give it up.  Find something else to do.  If this is your job,
then find a new job as soon as you can, so that you can quit this insanity.

Even OpenWRT runs Linux 5.11.  It seems likely that your environment
is some ARM (v4 or v5) embedded system that has an app with a horrendous bug
that you are trying to find and fix.  Trying to do this natively, running
such an old kernel and probably with severely limited RAM, is insane.

Get a 4GB or 8GB Raspberry Pi running a current Debian or Fedora Linux,
and debug the app there.  The Pi has GPIO, USB, Ethernet, camera, and
dot-matrix display interfaces.  If there are other sensors on your
device, then you should have hardware adapters so that they can use
USB interfacing, so that you *can* use a Pi as a real-time development
environment.  If your management won't spend the time or money to
make or procure such adapters for the sensors, then there is *NO* hope.

Re: [Valgrind-users] Compilation fails on ARM

[Leon P. <leo...@gm...>]

I recall my previous mail about cross-compilation.
When i did exactly what is recommended, I managed to cross-compile.
The unexpected issue appeared when I run wvalgrind myappw:
FATAL: kernel too old
My kernel is 2.6.37 and seemed to be ok.
Is it final or can I do something further? Old Valgrind version, for
example?

Thank a lot!!!

On Tue, 28 Feb 2023 at 13:52, Leon Pollak <leo...@gm...> wrote:

> Thank you, Paul - you were right - I missed the autogen.sh script.
> Doing it and trying to satisfy its and configure requirements brought me
> to so many incompatible version errors, that I gave up on "native"
> compilation (for DM8148 arm Cortex-A8, Linux 2.6.37) and decided to switch
> to cross-compilation. My PC is x86_64 Fedora 35.
> So, autogen.sh ran smoothly.
> Than I ran:
> export CROSS_COMPILE=/opt/gcc-linaro/bin/arm-linux-gnueabihf-
> ./configure --target=arm-linux-gnueabihf --host=x86_64-redhat-linux
> --prefix=/opt/valgrind CFLAGS=-static CC=${CROSS_COMPILE}gcc \
>              CPP=${CROSS_COMPILE}cpp CXX=${CROSS_COMPILE}g++
> LD=${CROSS_COMPILE}ld AR=${CROSS_COMPILE}ar
> Everything runs smoothly till:
> /opt/gcc-linaro/bin/arm-linux-gnueabihf-gcc -DHAVE_CONFIG_H -I. -I..  -I..
> -I../include -I../include -I../VEX/pub -I../VEX/pub -DVGA_amd64=1
> -DVGO_linux=1 -DVGP_amd64_linux=1 -DVGPV_amd64_linux_vanilla=1  -I../
> coregrind -DVG_LIBDIR="\"/opt/valgrind/libexec/valgrind"\"
> -DVG_PLATFORM="\"amd64-linux\""  -O2 -g -Wall -Wmissing-prototypes -Wshadow
> -Wpointer-arith -Wstrict-prototypes -Wmissing-declarations -Wcast-align -Wc
> ast-qual -Wwrite-strings -Wempty-body -Wformat -Wformat-signedness
> -Wformat-security -Wignored-qualifiers -Wmissing-parameter-type
> -Wlogical-op -Wold-style-declaration -finline-functions
> -fno-stack-protector -f
> no-strict-aliasing -fno-builtin   -fomit-frame-pointer   -static -MT
> valgrind-launcher-linux.o -MD -MP -MF .deps/valgrind-launcher-linux.Tpo -c
> -o valgrind-launcher-linux.o `test -f 'launcher-linux.c' || echo '
> ./'`launcher-linux.c
> In file included from ../include/pub_tool_vki.h:61:0,
>                 from pub_core_vki.h:42,
>                 from launcher-linux.c:39:
> ../include/vki/vki-xen.h:82:2: error: #error "Need to define per-ARCH Xen
> types for this platform"
> #error "Need to define per-ARCH Xen types for this platform"
>  ^~~~~
> ../include/vki/vki-xen.h:85:1: error: ‘void’ must be the only parameter
> DEFINE_VKI_XEN_GUEST_HANDLE(void);
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> and further thousands of errors.
>
>
> On Mon, 27 Feb 2023 at 23:24, Paul Floyd <pj...@wa...> wrote:
>
>>
>>
>> On 27-02-23 22:11, Leon Pollak wrote:
>> > Hello, all.
>> > I am trying to compile Valgrind 3.20.0 on ARMv7 Linux 2.6.37 (not
>> cross!).
>> > At first, compilation produced a lot of errors with binary constants in
>> > the form 0bXXXX, but I replaced them with normal numbers and
>> compilation
>> > continued.
>> > It failed with:
>> > ../coregrind/link_tool_exe_linux 0x58000000 gcc -std=gnu99     -o
>> > memcheck-arm-linux  -O2 -g -Wall -Wmissing-prototypes -Wshadow
>> > -Wpointer-arith -Wstrict-prototypes -Wmissing-declarations -Wcast-qual
>> > -Wwrite-st
>> > rings -Wformat -Wformat-security -finline-functions
>> -fno-stack-protector
>> > -fno-strict-aliasing -fno-builtin   -marm -mcpu=cortex-a8 -O2 -static
>> > -nodefaultlibs -nostartfiles -u _start   memcheck_arm_linux-mc_leak
>> > check.o memcheck_arm_linux-mc_malloc_wrappers.o
>> > memcheck_arm_linux-mc_main.o memcheck_arm_linux-mc_main_asm.o
>> > memcheck_arm_linux-mc_translate.o memcheck_arm_linux-mc_machine.o
>> > memcheck_arm_linux-mc_errors.o ../
>> > coregrind/libcoregrind-arm-linux.a ../VEX/libvex-arm-linux.a -lgcc
>> > ../coregrind/libgcc-sup-arm-linux.a
>> > ../coregrind/link_tool_exe_linux: line 58: use: command not found
>> > ../coregrind/link_tool_exe_linux: line 59: use: command not found
>> > ../coregrind/link_tool_exe_linux: line 62: die: command not found
>> > ../coregrind/link_tool_exe_linux: line 70: syntax error near unexpected
>> > token `$ala'
>> > ../coregrind/link_tool_exe_linux: line 70: `    if (length($ala) < 3 ||
>> > index($ala, "0x") != 0);'
>>
>> It sounds to me as though the script is failing to find the perl
>> interpreter and is running in whatever your default shell is.
>>
>> Can you ensure that you have perl installed?
>>
>> Is the path in link_tool_exe_linux correct?
>> If not you may need to run "autogen.sh" in the top source directory and
>> then rerun configure.
>>
>> A+
>> Paul
>>
>>
>>
>> _______________________________________________
>> Valgrind-users mailing list
>> Val...@li...
>> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>>
>

Re: [Valgrind-users] Compilation fails on ARM

[Leon P. <leo...@gm...>]

Thank you, Paul - you were right - I missed the autogen.sh script.
Doing it and trying to satisfy its and configure requirements brought me to
so many incompatible version errors, that I gave up on "native" compilation
(for DM8148 arm Cortex-A8, Linux 2.6.37) and decided to switch to
cross-compilation. My PC is x86_64 Fedora 35.
So, autogen.sh ran smoothly.
Than I ran:
export CROSS_COMPILE=/opt/gcc-linaro/bin/arm-linux-gnueabihf-
./configure --target=arm-linux-gnueabihf --host=x86_64-redhat-linux
--prefix=/opt/valgrind CFLAGS=-static CC=${CROSS_COMPILE}gcc \
             CPP=${CROSS_COMPILE}cpp CXX=${CROSS_COMPILE}g++
LD=${CROSS_COMPILE}ld AR=${CROSS_COMPILE}ar
Everything runs smoothly till:
/opt/gcc-linaro/bin/arm-linux-gnueabihf-gcc -DHAVE_CONFIG_H -I. -I..  -I..
-I../include -I../include -I../VEX/pub -I../VEX/pub -DVGA_amd64=1
-DVGO_linux=1 -DVGP_amd64_linux=1 -DVGPV_amd64_linux_vanilla=1  -I../
coregrind -DVG_LIBDIR="\"/opt/valgrind/libexec/valgrind"\"
-DVG_PLATFORM="\"amd64-linux\""  -O2 -g -Wall -Wmissing-prototypes -Wshadow
-Wpointer-arith -Wstrict-prototypes -Wmissing-declarations -Wcast-align -Wc
ast-qual -Wwrite-strings -Wempty-body -Wformat -Wformat-signedness
-Wformat-security -Wignored-qualifiers -Wmissing-parameter-type
-Wlogical-op -Wold-style-declaration -finline-functions
-fno-stack-protector -f
no-strict-aliasing -fno-builtin   -fomit-frame-pointer   -static -MT
valgrind-launcher-linux.o -MD -MP -MF .deps/valgrind-launcher-linux.Tpo -c
-o valgrind-launcher-linux.o `test -f 'launcher-linux.c' || echo '
./'`launcher-linux.c
In file included from ../include/pub_tool_vki.h:61:0,
                from pub_core_vki.h:42,
                from launcher-linux.c:39:
../include/vki/vki-xen.h:82:2: error: #error "Need to define per-ARCH Xen
types for this platform"
#error "Need to define per-ARCH Xen types for this platform"
 ^~~~~
../include/vki/vki-xen.h:85:1: error: ‘void’ must be the only parameter
DEFINE_VKI_XEN_GUEST_HANDLE(void);
^~~~~~~~~~~~~~~~~~~~~~~~~~~

and further thousands of errors.


On Mon, 27 Feb 2023 at 23:24, Paul Floyd <pj...@wa...> wrote:

>
>
> On 27-02-23 22:11, Leon Pollak wrote:
> > Hello, all.
> > I am trying to compile Valgrind 3.20.0 on ARMv7 Linux 2.6.37 (not
> cross!).
> > At first, compilation produced a lot of errors with binary constants in
> > the form 0bXXXX, but I replaced them with normal numbers and compilation
> > continued.
> > It failed with:
> > ../coregrind/link_tool_exe_linux 0x58000000 gcc -std=gnu99     -o
> > memcheck-arm-linux  -O2 -g -Wall -Wmissing-prototypes -Wshadow
> > -Wpointer-arith -Wstrict-prototypes -Wmissing-declarations -Wcast-qual
> > -Wwrite-st
> > rings -Wformat -Wformat-security -finline-functions -fno-stack-protector
> > -fno-strict-aliasing -fno-builtin   -marm -mcpu=cortex-a8 -O2 -static
> > -nodefaultlibs -nostartfiles -u _start   memcheck_arm_linux-mc_leak
> > check.o memcheck_arm_linux-mc_malloc_wrappers.o
> > memcheck_arm_linux-mc_main.o memcheck_arm_linux-mc_main_asm.o
> > memcheck_arm_linux-mc_translate.o memcheck_arm_linux-mc_machine.o
> > memcheck_arm_linux-mc_errors.o ../
> > coregrind/libcoregrind-arm-linux.a ../VEX/libvex-arm-linux.a -lgcc
> > ../coregrind/libgcc-sup-arm-linux.a
> > ../coregrind/link_tool_exe_linux: line 58: use: command not found
> > ../coregrind/link_tool_exe_linux: line 59: use: command not found
> > ../coregrind/link_tool_exe_linux: line 62: die: command not found
> > ../coregrind/link_tool_exe_linux: line 70: syntax error near unexpected
> > token `$ala'
> > ../coregrind/link_tool_exe_linux: line 70: `    if (length($ala) < 3 ||
> > index($ala, "0x") != 0);'
>
> It sounds to me as though the script is failing to find the perl
> interpreter and is running in whatever your default shell is.
>
> Can you ensure that you have perl installed?
>
> Is the path in link_tool_exe_linux correct?
> If not you may need to run "autogen.sh" in the top source directory and
> then rerun configure.
>
> A+
> Paul
>
>
>
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>

Re: [Valgrind-users] Compilation fails on ARM

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

On 27-02-23 22:11, Leon Pollak wrote:
> Hello, all.
> I am trying to compile Valgrind 3.20.0 on ARMv7 Linux 2.6.37 (not cross!).
> At first, compilation produced a lot of errors with binary constants in 
> the form 0bXXXX, but I replaced them with normal numbers and compilation 
> continued.
> It failed with:
> ../coregrind/link_tool_exe_linux 0x58000000 gcc -std=gnu99     -o 
> memcheck-arm-linux  -O2 -g -Wall -Wmissing-prototypes -Wshadow 
> -Wpointer-arith -Wstrict-prototypes -Wmissing-declarations -Wcast-qual 
> -Wwrite-st
> rings -Wformat -Wformat-security -finline-functions -fno-stack-protector 
> -fno-strict-aliasing -fno-builtin   -marm -mcpu=cortex-a8 -O2 -static 
> -nodefaultlibs -nostartfiles -u _start   memcheck_arm_linux-mc_leak
> check.o memcheck_arm_linux-mc_malloc_wrappers.o 
> memcheck_arm_linux-mc_main.o memcheck_arm_linux-mc_main_asm.o 
> memcheck_arm_linux-mc_translate.o memcheck_arm_linux-mc_machine.o 
> memcheck_arm_linux-mc_errors.o ../
> coregrind/libcoregrind-arm-linux.a ../VEX/libvex-arm-linux.a -lgcc 
> ../coregrind/libgcc-sup-arm-linux.a
> ../coregrind/link_tool_exe_linux: line 58: use: command not found
> ../coregrind/link_tool_exe_linux: line 59: use: command not found
> ../coregrind/link_tool_exe_linux: line 62: die: command not found
> ../coregrind/link_tool_exe_linux: line 70: syntax error near unexpected 
> token `$ala'
> ../coregrind/link_tool_exe_linux: line 70: `    if (length($ala) < 3 || 
> index($ala, "0x") != 0);'

It sounds to me as though the script is failing to find the perl 
interpreter and is running in whatever your default shell is.

Can you ensure that you have perl installed?

Is the path in link_tool_exe_linux correct?
If not you may need to run "autogen.sh" in the top source directory and 
then rerun configure.

A+
Paul

[Valgrind-users] Compilation fails on ARM

[Leon P. <leo...@gm...>]

Hello, all.
I am trying to compile Valgrind 3.20.0 on ARMv7 Linux 2.6.37 (not cross!).
At first, compilation produced a lot of errors with binary constants in the
form 0bXXXX, but I replaced them with normal numbers and compilation
continued.
It failed with:
../coregrind/link_tool_exe_linux 0x58000000 gcc -std=gnu99     -o
memcheck-arm-linux  -O2 -g -Wall -Wmissing-prototypes -Wshadow
-Wpointer-arith -Wstrict-prototypes -Wmissing-declarations -Wcast-qual
-Wwrite-st
rings -Wformat -Wformat-security -finline-functions -fno-stack-protector
-fno-strict-aliasing -fno-builtin   -marm -mcpu=cortex-a8 -O2 -static
-nodefaultlibs -nostartfiles -u _start   memcheck_arm_linux-mc_leak
check.o memcheck_arm_linux-mc_malloc_wrappers.o
memcheck_arm_linux-mc_main.o memcheck_arm_linux-mc_main_asm.o
memcheck_arm_linux-mc_translate.o memcheck_arm_linux-mc_machine.o
memcheck_arm_linux-mc_errors.o ../
coregrind/libcoregrind-arm-linux.a ../VEX/libvex-arm-linux.a -lgcc
../coregrind/libgcc-sup-arm-linux.a
../coregrind/link_tool_exe_linux: line 58: use: command not found
../coregrind/link_tool_exe_linux: line 59: use: command not found
../coregrind/link_tool_exe_linux: line 62: die: command not found
../coregrind/link_tool_exe_linux: line 70: syntax error near unexpected
token `$ala'
../coregrind/link_tool_exe_linux: line 70: `    if (length($ala) < 3 ||
index($ala, "0x") != 0);'


Looking into the link_tool_exe_linux script I must admit that I did not
understand a thing about what should be done...:-(

Please, help!!!
Many thanks ahead.
Leon

Re: [Valgrind-users] Recursive `who-points-at`

[Eliot M. <mo...@cs...>]

On 2/26/2023 4:29 AM, Philippe Waroquiers wrote:
> On Fri, 2023-02-24 at 10:42 -0700, User 10482 wrote:
>> Dear All,
>>
>> I am looking to fix dangling pointer issue and was pleasantly surprised to find the
>> `who-points-at` functionality in valgrind which tells the stack variable names (assuming
>> --read-var-info=yes) and any addresses on heap with holding the searched address.
>> [link](https://valgrind.org/docs/manual/mc-manual.html#mc-manual.monitor-commands)
>>
>> The tool is just splendid but I wish there was some way to do it recursively on the heap
>> addresses (i.e who-points-at on the output of previous who-points-at) until we get the
>> stack variable names holding the dangling pointers; something like how core-analyzer's
>> `ref` command does. [link](
>> https://core-analyzer.sourceforge.net/index_files/Page600.html).
> 
> Yes, a recursive who-points-at would be a nice thing to have.
> I have added this on my list of things to do (one day, whenever I have time :().
> 
> 
>>
>> On a side note, is there a way to know which variable/type a heap address points to?
>> That will be helpful too.
> The only information valgrind has about a (live) heap block is the stack trace that
> allocated it.
> Valgrind does not know the type of the object for which this memory was allocated.
> Unclear to me how that can be implemented (at least without support of the compiler).

I wonder if gdb (or whatever debugger) info about the types of the pointers
would allow providing useful information?  Presumably that could be had if the
executable had the information kept with it and not stripped.

Best - Eliot Moss

Re: [Valgrind-users] Recursive `who-points-at`

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

On Fri, 2023-02-24 at 10:42 -0700, User 10482 wrote:
> Dear All,
> 
> I am looking to fix dangling pointer issue and was pleasantly surprised to find the
> `who-points-at` functionality in valgrind which tells the stack variable names (assuming
> --read-var-info=yes) and any addresses on heap with holding the searched address.
> [link](https://valgrind.org/docs/manual/mc-manual.html#mc-manual.monitor-commands)
> 
> The tool is just splendid but I wish there was some way to do it recursively on the heap
> addresses (i.e who-points-at on the output of previous who-points-at) until we get the
> stack variable names holding the dangling pointers; something like how core-analyzer's
> `ref` command does. [link](
> https://core-analyzer.sourceforge.net/index_files/Page600.html).

Yes, a recursive who-points-at would be a nice thing to have.
I have added this on my list of things to do (one day, whenever I have time :().


> 
> On a side note, is there a way to know which variable/type a heap address points to?
> That will be helpful too.
The only information valgrind has about a (live) heap block is the stack trace that
allocated it.
Valgrind does not know the type of the object for which this memory was allocated.
Unclear to me how that can be implemented (at least without support of the compiler).

> 
> Thanks and have a good day!
> 
> best,
> Abhi
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users

[Valgrind-users] Recursive `who-points-at`

[User 1. <abh...@gm...>]

Dear All,

I am looking to fix dangling pointer issue and was pleasantly surprised to
find the `who-points-at` functionality in valgrind which tells the stack
variable names (assuming --read-var-info=yes) and any addresses on heap
with holding the searched address. [link](
https://valgrind.org/docs/manual/mc-manual.html#mc-manual.monitor-commands)

The tool is just splendid but I wish there was some way to do it
recursively on the heap addresses (i.e who-points-at on the output of
previous who-points-at) until we get the stack variable names holding the
dangling pointers; something like how core-analyzer's `ref` command does.
[link](https://core-analyzer.sourceforge.net/index_files/Page600.html).

On a side note, is there a way to know which variable/type a heap address
points to? That will be helpful too.

Thanks and have a good day!

best,
Abhi

Re: [Valgrind-users] Need Help

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

$ cat foo.s
.byte 0x66,0xF,0x3A,0x22
.byte 0,0,0,0
#
# For x86_64 on x86_64
#
$ gcc --version
gcc (GCC) 12.2.1 20221121 (Red Hat 12.2.1-4)
$ gcc -c foo.s
$ file foo.o
foo.o: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), stripped
$ gdb foo.o
GNU gdb (GDB) Fedora 12.1-2.fc36
(gdb) x/i 0
    0x0:	pinsrd $0x0,(%rax),%xmm0
(gdb)
    0x6:	add    %al,(%rax)

#
# For i686 on x86_64
#
$ gcc -m32 -c foo.s
$ file foo.o
foo.o: ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), stripped
$ gdb foo.o
(gdb) x/i 0
    0x0:	pinsrd $0x0,(%eax),%xmm0
(gdb)
    0x6:	add    %al,(%eax)

Re: [Valgrind-users] Need Help

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

> On 16 Feb 2023, at 00:37, Anand K R <kar...@gm...> wrote:
> 
> 0x66 0xF 0x3A 0x22
>  


I can’t see what that disassembles to.

Can you tell us what CPU exactly this is for, and which OS and compiler you are using?

Do you get any call stacks (for Valgtind itself or the test exe)?

Lastly, can you provide a small reproducer?

My guess is that somehow you are jumping to a memory location that is not on an instruction boundary. This could be caused by something like stack corruption overwriting a function return address.

A+
Paul

Re: [Valgrind-users] Need Help

[Anand K R <kar...@gm...>]

Hi,



I am getting the following error when using valgrind version 20. It
terminates with sigill. Request for any help in resolving this.



vex x86->IR: unhandled instruction bytes: 0x66 0xF 0x3A 0x22



Regards,

Anand

Re: [Valgrind-users] Cache conflict detection support in cachegrind

[Ivica B <ibo...@gm...>]

Thanks a lot :)

On Wed, Feb 8, 2023, 9:11 PM Paul Floyd <pj...@wa...> wrote:

>
>
> On 29-01-23 20:50, Ivica B wrote:
> > Hi Paul!
> >
> > I read the info you provided, but none of the programs actually
> > support detecting cache conflicts.
>
> Hi
>
> No, the tools I suggested would only give an indication, you would then
> have to use your code knowledge and maybe some trial and error to make
> improvements.
>
> Coincidentally about the same time as you asked about this I watched
> your cppcon talk an observability tools. Thumbs up.
>
> I'm looking at your bugzilla patch and will post feedback.
>
> A+
> Paul
>
>
>
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>

Re: [Valgrind-users] Cache conflict detection support in cachegrind

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

On 29-01-23 20:50, Ivica B wrote:
> Hi Paul!
> 
> I read the info you provided, but none of the programs actually
> support detecting cache conflicts.

Hi

No, the tools I suggested would only give an indication, you would then 
have to use your code knowledge and maybe some trial and error to make 
improvements.

Coincidentally about the same time as you asked about this I watched 
your cppcon talk an observability tools. Thumbs up.

I'm looking at your bugzilla patch and will post feedback.

A+
Paul