Hi Jason, thank you for mentioning my work! I'm usually not getting any feedback from my blog posts and sometimes I'm wondering if it makes sense to write them at all. I'm going to have another article published soon, it's about improvements in file descriptors tracking in Valgrind. Everyone is welcome to comment on my blog posts, so I know what's actually interesting for the audience.
@@vberthiaume Yes. UA-cam auto deleted my first reply. Search for "redhat valgrind blog gdb close cooperation". Alexandra also wrote an excellent article, search for "Debug memory errors with Valgrind and GDB".
Its quite intresting. While exploring i found that there are literally so less of information about cpp memory management or debugging tools like gdb. Mostly their are basic stuffs only. Thnx for this.
Sometimes two terminals is better (e.g., when the test exe generates a lot of output). We need to work with gdb to make this a bit easier. You can simplify the startup if you put the following in your .gdbinit file define set-program-name set logging file tmp.gdb set logging overwrite on set logging redirect on set logging enabled on python print(f"set $programname = \"{gdb.current_progspace().filename}\"") set logging enabled off set logging redirect off set logging overwrite off source tmp.gdb end define start_vg set-program-name eval "set remote exec-file %s", $programname show remote exec-file set sysroot / target extended-remote | vgdb --multi --vargs -q start end Then you can do something like $ gdb test_exe (gdb) start_vg and then you are in gdb connected to Valgrind.
Yes! This is an undeservedly obscure feature of valgrind. And it's scriptable just like regular old gdb. If I may plug my own CppCon video: ua-cam.com/video/ck_jCH_G7pA/v-deo.html
Hi Jason, thank you for mentioning my work! I'm usually not getting any feedback from my blog posts and sometimes I'm wondering if it makes sense to write them at all. I'm going to have another article published soon, it's about improvements in file descriptors tracking in Valgrind. Everyone is welcome to comment on my blog posts, so I know what's actually interesting for the audience.
Got a link to the blog?
@@vberthiaume Yes. UA-cam auto deleted my first reply. Search for "redhat valgrind blog gdb close cooperation". Alexandra also wrote an excellent article, search for "Debug memory errors with Valgrind and GDB".
@@vberthiaume Search for "Valgrind and GDB in close cooperation"
@@vberthiaume And also ua-cam.com/video/1VubqWmloZU/v-deo.html
Honestly, I would love a large UA-cam series of just different valgrind features, and another on exploring the features of gdb from the command line
Oh, this looks really useful! I'd love to see another video on the aformentioned reverse debugging in gdb too
Its quite intresting. While exploring i found that there are literally so less of information about cpp memory management or debugging tools like gdb. Mostly their are basic stuffs only. Thnx for this.
I have used it, and found it quite useful.
Nice tutorial
I suppose valgrind + gdb could not work together for remote debugging MCU embedded program running on bare platform ?
I might suggest it is pronounced val-grind like coffee-grind, and no haven't grined since writing this 😁. Regardless, great video!
can you stop making videos so I can catch up? I'm 35 years behind in c++ topics.
For your simple use case like here, wouldn't it be just simpler to launch valgrind with --db-attach=yes option?
Sometimes two terminals is better (e.g., when the test exe generates a lot of output). We need to work with gdb to make this a bit easier.
You can simplify the startup if you put the following in your .gdbinit file
define set-program-name
set logging file tmp.gdb
set logging overwrite on
set logging redirect on
set logging enabled on
python print(f"set $programname = \"{gdb.current_progspace().filename}\"")
set logging enabled off
set logging redirect off
set logging overwrite off
source tmp.gdb
end
define start_vg
set-program-name
eval "set remote exec-file %s", $programname
show remote exec-file
set sysroot /
target extended-remote | vgdb --multi --vargs -q
start
end
Then you can do something like
$ gdb test_exe
(gdb) start_vg
and then you are in gdb connected to Valgrind.
Yes! This is an undeservedly obscure feature of valgrind. And it's scriptable just like regular old gdb. If I may plug my own CppCon video: ua-cam.com/video/ck_jCH_G7pA/v-deo.html
It is now scripted in Python (thanks to Philippe Waroquiers). Would it be possible for us to integrate your ppl, script?