You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(122) |
Nov
(152) |
Dec
(69) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(6) |
Feb
(25) |
Mar
(73) |
Apr
(82) |
May
(24) |
Jun
(25) |
Jul
(10) |
Aug
(11) |
Sep
(10) |
Oct
(54) |
Nov
(203) |
Dec
(182) |
| 2004 |
Jan
(307) |
Feb
(305) |
Mar
(430) |
Apr
(312) |
May
(187) |
Jun
(342) |
Jul
(487) |
Aug
(637) |
Sep
(336) |
Oct
(373) |
Nov
(441) |
Dec
(210) |
| 2005 |
Jan
(385) |
Feb
(480) |
Mar
(636) |
Apr
(544) |
May
(679) |
Jun
(625) |
Jul
(810) |
Aug
(838) |
Sep
(634) |
Oct
(521) |
Nov
(965) |
Dec
(543) |
| 2006 |
Jan
(494) |
Feb
(431) |
Mar
(546) |
Apr
(411) |
May
(406) |
Jun
(322) |
Jul
(256) |
Aug
(401) |
Sep
(345) |
Oct
(542) |
Nov
(308) |
Dec
(481) |
| 2007 |
Jan
(427) |
Feb
(326) |
Mar
(367) |
Apr
(255) |
May
(244) |
Jun
(204) |
Jul
(223) |
Aug
(231) |
Sep
(354) |
Oct
(374) |
Nov
(497) |
Dec
(362) |
| 2008 |
Jan
(322) |
Feb
(482) |
Mar
(658) |
Apr
(422) |
May
(476) |
Jun
(396) |
Jul
(455) |
Aug
(267) |
Sep
(280) |
Oct
(253) |
Nov
(232) |
Dec
(304) |
| 2009 |
Jan
(486) |
Feb
(470) |
Mar
(458) |
Apr
(423) |
May
(696) |
Jun
(461) |
Jul
(551) |
Aug
(575) |
Sep
(134) |
Oct
(110) |
Nov
(157) |
Dec
(102) |
| 2010 |
Jan
(226) |
Feb
(86) |
Mar
(147) |
Apr
(117) |
May
(107) |
Jun
(203) |
Jul
(193) |
Aug
(238) |
Sep
(300) |
Oct
(246) |
Nov
(23) |
Dec
(75) |
| 2011 |
Jan
(133) |
Feb
(195) |
Mar
(315) |
Apr
(200) |
May
(267) |
Jun
(293) |
Jul
(353) |
Aug
(237) |
Sep
(278) |
Oct
(611) |
Nov
(274) |
Dec
(260) |
| 2012 |
Jan
(303) |
Feb
(391) |
Mar
(417) |
Apr
(441) |
May
(488) |
Jun
(655) |
Jul
(590) |
Aug
(610) |
Sep
(526) |
Oct
(478) |
Nov
(359) |
Dec
(372) |
| 2013 |
Jan
(467) |
Feb
(226) |
Mar
(391) |
Apr
(281) |
May
(299) |
Jun
(252) |
Jul
(311) |
Aug
(352) |
Sep
(481) |
Oct
(571) |
Nov
(222) |
Dec
(231) |
| 2014 |
Jan
(185) |
Feb
(329) |
Mar
(245) |
Apr
(238) |
May
(281) |
Jun
(399) |
Jul
(382) |
Aug
(500) |
Sep
(579) |
Oct
(435) |
Nov
(487) |
Dec
(256) |
| 2015 |
Jan
(338) |
Feb
(357) |
Mar
(330) |
Apr
(294) |
May
(191) |
Jun
(108) |
Jul
(142) |
Aug
(261) |
Sep
(190) |
Oct
(54) |
Nov
(83) |
Dec
(22) |
| 2016 |
Jan
(49) |
Feb
(89) |
Mar
(33) |
Apr
(50) |
May
(27) |
Jun
(34) |
Jul
(53) |
Aug
(53) |
Sep
(98) |
Oct
(206) |
Nov
(93) |
Dec
(53) |
| 2017 |
Jan
(65) |
Feb
(82) |
Mar
(102) |
Apr
(86) |
May
(187) |
Jun
(67) |
Jul
(23) |
Aug
(93) |
Sep
(65) |
Oct
(45) |
Nov
(35) |
Dec
(17) |
| 2018 |
Jan
(26) |
Feb
(35) |
Mar
(38) |
Apr
(32) |
May
(8) |
Jun
(43) |
Jul
(27) |
Aug
(30) |
Sep
(43) |
Oct
(42) |
Nov
(38) |
Dec
(67) |
| 2019 |
Jan
(32) |
Feb
(37) |
Mar
(53) |
Apr
(64) |
May
(49) |
Jun
(18) |
Jul
(14) |
Aug
(53) |
Sep
(25) |
Oct
(30) |
Nov
(49) |
Dec
(31) |
| 2020 |
Jan
(87) |
Feb
(45) |
Mar
(37) |
Apr
(51) |
May
(99) |
Jun
(36) |
Jul
(11) |
Aug
(14) |
Sep
(20) |
Oct
(24) |
Nov
(40) |
Dec
(23) |
| 2021 |
Jan
(14) |
Feb
(53) |
Mar
(85) |
Apr
(15) |
May
(19) |
Jun
(3) |
Jul
(14) |
Aug
(1) |
Sep
(57) |
Oct
(73) |
Nov
(56) |
Dec
(22) |
| 2022 |
Jan
(3) |
Feb
(22) |
Mar
(6) |
Apr
(55) |
May
(46) |
Jun
(39) |
Jul
(15) |
Aug
(9) |
Sep
(11) |
Oct
(34) |
Nov
(20) |
Dec
(36) |
| 2023 |
Jan
(79) |
Feb
(41) |
Mar
(99) |
Apr
(169) |
May
(48) |
Jun
(16) |
Jul
(16) |
Aug
(57) |
Sep
(19) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
|
|
|
|
1
(6) |
|
2
(6) |
3
(9) |
4
(4) |
5
(1) |
6
|
7
|
8
|
|
9
|
10
(2) |
11
(1) |
12
(2) |
13
(4) |
14
(6) |
15
(8) |
|
16
(9) |
17
(5) |
18
(13) |
19
(6) |
20
(15) |
21
(17) |
22
(19) |
|
23
(2) |
24
(4) |
25
(2) |
26
(10) |
27
(6) |
28
(9) |
29
(3) |
|
30
|
|
|
|
|
|
|
|
From: Philippe W. <phi...@sk...> - 2023-04-15 20:27:53
|
Some additional comments below ... Thanks Philippe On Thu, 2023-04-13 at 22:09 +0000, Mark Wielaard wrote: > https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=0432ce486d61f84f6fcbeab0d812bb1f61c57561 > > commit 0432ce486d61f84f6fcbeab0d812bb1f61c57561 > Author: Alexandra Petlanova Hajkova <aha...@re...> > Date: Thu Mar 3 04:46:03 2022 -0500 > > vgdb: implement the extended-remote protocol > > > > Executing vgdb --multi makes vgdb talk the gdb extended-remote > protocol. This means that the gdb run command is supported and > vgdb will start up the program under valgrind. Which means you > don't need to run gdb and valgrind from different terminals. > Also vgdb keeps being connected to gdb after valgrind exits. So > you can easily rerun the program with the same breakpoints in > place. > > > > vgdb now implements a minimal gdbserver that just recognizes > a few extended-remote protocol packets. Once it starts up valgrind > it sets up noack and qsupported then it will forward packets > between gdb and valgrind gdbserver. After valgrind shutsdown it > resumes handling gdb packets itself. > > > > https://bugs.kde.org/show_bug.cgi?id=434057 > > > > Co-authored-by: Mark Wielaard <ma...@kl...> valgrind --help does not describe the 'multi' related option, but --help-debug describes it. That was a little bit surprising to me. As this is not a real user option, it however does not fully fit in the section: uncommon user options for all Valgrind tools: > > diff --git a/coregrind/vgdb.c b/coregrind/vgdb.c > index 9a9b90e585..1cc37a3566 100644 > --- a/coregrind/vgdb.c > +++ b/coregrind/vgdb.c > > /* vgdb has two usages: Maybe this should describe here 3 usages ? > @@ -169,7 +175,17 @@ void map_vgdbshared(char* shared_mem) > { > struct stat fdstat; > void **s; > - shared_mem_fd = open(shared_mem, O_RDWR); > + int tries = 50; > + int err; > + > + /* valgrind might still be starting up, give it 5 seconds. */ Maybe the --wait arg (if provided) could override this hard-coded value ? > +/* Returns an allocated hex-decoded string from the buf starting at offset > + off. Will update off to where the buf has been decoded. Stops decoding > + at end of buf (zero) or when seeing the delim char. */ The comment seems not aligned with the below function (e.g. there is no off arg). > +static > +char *decode_hexstring (const char *buf, size_t prefixlen, size_t len) > +{ > + int buflen; > + char *buf_print; > + > + if (len) > + buflen = len; > + else > + buflen = strlen(buf) - prefixlen; > + > + buf_print = vmalloc (buflen/2 + 1); > + > + for (int i = 0; i < buflen; i = i + 2) { > + buf_print[i/2] = ((fromhex(buf[i+prefixlen]) << 4) > + + fromhex(buf[i+prefixlen+1])); > + } > + buf_print[buflen/2] = '\0'; > + DEBUG(1, "decode_hexstring: %s\n", buf_print); > + return buf_print; > +} > + > > > > + > +/* Creates a packet from a string message, called needs to free. */ caller needs to free ? > +static char * > +create_packet(const char *msg) > In some functions from here onwards, there are a bunch of indentation with 4 spaces while the rest of vgdb.c is 3. > + > +static int read_one_char (char *c) > +{ > + int i; > + do > + i = read (from_gdb, c, 1); > + while (i == -1 && errno == EINTR); > + > + return i; > +} > + > > + > +// Throws away the packet name and decodes the hex string, which is placed in What is the packet name ? > +// decoded_string (the caller owns this and is responsible for freeing it). > +static int split_hexdecode(const char *buf, const char *string, > + const char *delim, char **decoded_string) > +{ > + const char *next_str = next_delim_string(buf, *delim); > + if (next_str) { > + *decoded_string = decode_hexstring (next_str, 0, 0); > + DEBUG(1, "split_hexdecode decoded %s\n", *decoded_string); > + return 1; > + } else { > + TSFPRINTF(stderr, "%s decoding error: finding the hex string in %s failed!\n", string, buf); > + return 0; > + } > +} > + > +static int count_delims(char delim, char *buf) This should return a size_t > +{ > + size_t count = 0; > + char *ptr = buf; > + > + while (*ptr) > + count += *ptr++ == delim; > + return count; > +} > + > > > +/* Do multi stuff. */ > +static > +void do_multi_mode(void) > +{ > + char *buf = vmalloc(PBUFSIZ+1); > + char *q_buf = vmalloc(PBUFSIZ+1); //save the qSupported packet sent by gdb > + //to send it to the valgrind gdbserver later > + q_buf[0] = '\0'; > + int noackmode = 0, pkt_size = 0, bad_unknown_packets = 0; > + char *string = NULL; > + char *working_dir = NULL; > + DEBUG(1, "doing multi stuff...\n"); > + while (1){ > + /* We get zero if the pipe was closed (EOF), or -1 on error reading from > + the pipe to gdb. */ > + pkt_size = receive_packet(buf, noackmode); > + if (pkt_size <= 0) { > + DEBUG(1, "receive_packet: %d\n", pkt_size); > + break; > + } > + > + DEBUG(1, "packet recieved: '%s'\n", buf); typo: received > + > +#define QSUPPORTED "qSupported:" > +#define STARTNOACKMODE "QStartNoAckMode" > +#define QRCMD "qRcmd" // This is the monitor command in gdb > +#define VRUN "vRun" > +#define XFER "qXfer" > +#define QATTACHED "qAttached" > +#define QENVIRONMENTHEXENCODED "QEnvironmentHexEncoded" > +#define QENVIRONMENTRESET "QEnvironmentReset" > +#define QENVIRONMENTUNSET "QEnvironmentUnset" > +#define QSETWORKINGDIR "QSetWorkingDir" > +#define QTSTATUS "qTStatus" > + > + if (strncmp(QSUPPORTED, buf, strlen(QSUPPORTED)) == 0) { > + DEBUG(1, "CASE %s\n", QSUPPORTED); > + // And here is our reply. > + // XXX error handling? We don't check the arguments. > + char *reply; > + strcpy(q_buf, buf); > + // Keep this in sync with coregrind/m_gdbserver/server.c Worth adding a note in server.c to also point at this place ? > + asprintf (&reply, > + "PacketSize=%x;" > + "QStartNoAckMode+;" > + "QPassSignals+;" > + "QCatchSyscalls+;" > + /* Just report support always. */ > + "qXfer:auxv:read+;" > + /* We'll force --vgdb-shadow-registers=yes */ > + "qXfer:features:read+;" > + "qXfer:exec-file:read+;" > + "qXfer:siginfo:read+;" > + /* Some extra's vgdb support before valgrind starts up. */ > + "QEnvironmentHexEncoded+;" > + "QEnvironmentReset+;" > + "QEnvironmentUnset+;" > + "QSetWorkingDir+", (UInt)PBUFSIZ - 1); > + send_packet(reply, noackmode); > + free (reply); > + } > + else if (strncmp(STARTNOACKMODE, buf, strlen(STARTNOACKMODE)) == 0) { > + // We have to ack this one > + send_packet("OK", 0); > + noackmode = 1; > + } > + else if (buf[0] == '!') { > + send_packet("OK", noackmode); > + } > + else if (buf[0] == '?') { > + send_packet("W00", noackmode); > + } > + else if (strncmp("H", buf, strlen("H")) == 0) { > + // Set thread packet, but we are not running yet. > + send_packet("E01", noackmode); > + } > + else if (strncmp("vMustReplyEmpty", buf, strlen("vMustReplyEmpty")) == 0) { > + send_packet ("", noackmode); > + } > + else if (strncmp(QRCMD, buf, strlen(QRCMD)) == 0) { > + send_packet ("No running target, monitor commands not available yet.", noackmode); > + > + char *decoded_string = decode_hexstring (buf, strlen (QRCMD) + 1, 0); > + DEBUG(1, "qRcmd decoded: %s\n", decoded_string); > + free (decoded_string); > + } > + else if (strncmp(VRUN, buf, strlen(VRUN)) == 0) { > + // vRun;filename[;argument]* > + // vRun, filename and arguments are split on ';', > + // no ';' at the end. > + // If there are no arguments count is one (just the filename). > + // Otherwise it is the number of arguments plus one (the filename). > + // The filename must be there and starts after the first ';'. > + // TODO: Handle vRun;[;argument]* > + // https://www.sourceware.org/gdb/onlinedocs/gdb/Packets.html#Packets > + // If filename is an empty string, the stub may use a default program > + // (e.g. the last program run). > + size_t count = count_delims(';', buf); > + size_t *len = vmalloc(count * sizeof(count)); > + const char *delim = ";"; > + const char *next_str = next_delim_string(buf, *delim); > + char **decoded_string = vmalloc(count * sizeof (char *)); > + > + // Count the lenghts of each substring, init to -1 to compensate for typo: lenghts > + // each substring starting with a delim char. > + for (int i = 0; i < count; i++) > + len[i] = -1; > + count_len(';', buf, len); > + if (next_str) { > + DEBUG(1, "vRun: next_str %s\n", next_str); > + for (int i = 0; i < count; i++) { > + /* Handle the case when the arguments > + * was specified to gdb's run command > + * but no remote exec-file was set, > + * so the first vRun argument is missing. > + * For example vRun;;6c. */ > + if (*next_str == *delim) { > + next_str++; > + /* empty string that can be freed. */ > + decoded_string[i] = strdup(""); > + } > + else { > + decoded_string[i] = decode_hexstring (next_str, 0, len[i]); > + if (i < count - 1) > + next_str = next_delim_string(next_str, *delim); > + } > + DEBUG(1, "vRun decoded: %s, next_str %s, len[%d] %d\n", decoded_string[i], next_str, i, len[i]); Line too long. > + } > + > + /* If we didn't get any arguments or the filename is an empty > + string, valgrind won't know which program to run. */ > + DEBUG (1, "count: %d, len[0]: %d\n", count, len[0]); > + if (! count || len[0] == 0) { > + free(len); > + for (int i = 0; i < count; i++) > + free (decoded_string[i]); > + free (decoded_string); > + send_packet ("E01", noackmode); > + continue; > + } > + > + /* We have collected the decoded strings so we can use them to > + launch valgrind with the correct arguments... We then use the > + valgrind pid to start relaying packets. */ > + pid_t valgrind_pid = -1; > + int res = fork_and_exec_valgrind (count, > + decoded_string, > + working_dir, > + &valgrind_pid); > + > + if (res == 0) { > + // Lets report we Stopped with SIGTRAP (05). > + send_packet ("S05", noackmode); > + prepare_fifos_and_shared_mem(valgrind_pid); > + DEBUG(1, "from_gdb_to_pid %s, to_gdb_from_pid %s\n", from_gdb_to_pid, to_gdb_from_pid); line too long > + // gdb_rely is an endless loop till valgrind quits. typo: gdb_rely > + shutting_down = False; > + > + gdb_relay (valgrind_pid, 1, q_buf); > + cleanup_fifos_and_shared_mem(); > + DEBUG(1, "valgrind relay done\n"); > + int status; > + pid_t p = waitpid (valgrind_pid, &status, 0); > + DEBUG(2, "waitpid: %d\n", (int) p); > + if (p == -1) > + DEBUG(1, "waitpid error %s\n", strerror (errno)); > + else { > + if (WIFEXITED(status)) > + DEBUG(1, "valgrind exited with %d\n", > + WEXITSTATUS(status)); > + else if (WIFSIGNALED(status)) > + DEBUG(1, "valgrind kill by signal %d\n", > + WTERMSIG(status)); > + else > + DEBUG(1, "valgind unexpectedly stopped or continued"); typo: valgind > + } > + } else { > + send_packet ("E01", noackmode); > + DEBUG(1, "OOPS! couldn't launch valgrind %s\n", > + strerror (res)); > + } > + > + free(len); > + for (int i = 0; i < count; i++) > + free (decoded_string[i]); > + free (decoded_string); > + } else { > + free(len); > + send_packet ("E01", noackmode); missing indentation > + DEBUG(1, "vRun decoding error: no next_string!\n"); > + continue; > + } > + } else if (strncmp(QATTACHED, buf, strlen(QATTACHED)) == 0) { > + send_packet ("1", noackmode); > + DEBUG(1, "qAttached sent: '1'\n"); > + const char *next_str = next_delim_string(buf, ':'); > + if (next_str) { > + char *decoded_string = decode_hexstring (next_str, 0, 0); > + DEBUG(1, "qAttached decoded: %s, next_str %s\n", decoded_string, next_str); > + free (decoded_string); > + } else { > + DEBUG(1, "qAttached decoding error: strdup of %s failed!\n", buf); > + continue; > + } > + } /* Reset the state of environment variables in the remote target before starting > + the inferior. In this context, reset means unsetting all environment variables > + that were previously set by the user (i.e., were not initially present in the environment). */ line too long Below we have indentation with 5 chars at many places. > + else if (strncmp(QENVIRONMENTRESET, buf, > + strlen(QENVIRONMENTRESET)) == 0) { > + send_packet ("OK", noackmode); > + // TODO clear all environment strings. We're not using > + // environment strings now. But we should. > + } else if (strncmp(QENVIRONMENTHEXENCODED, buf, > + strlen(QENVIRONMENTHEXENCODED)) == 0) { > + send_packet ("OK", noackmode); > + if (!split_hexdecode(buf, QENVIRONMENTHEXENCODED, ":", &string)) > + break; > + // TODO Collect all environment strings and add them to environ > + // before launcing valgrind. typo: launcing > + free (string); > + string = NULL; > + } else if (strncmp(QENVIRONMENTUNSET, buf, > + strlen(QENVIRONMENTUNSET)) == 0) { > + send_packet ("OK", noackmode); > + if (!split_hexdecode(buf, QENVIRONMENTUNSET, ":", &string)) > + break; > + // TODO Remove this environment string from the collection. > + free (string); > + string = NULL; > + } else if (strncmp(QSETWORKINGDIR, buf, > + strlen(QSETWORKINGDIR)) == 0) { > + // Silly, but we can only reply OK, even if the working directory is > + // bad. Errors will be reported when we try to execute the actual > + // process. > + send_packet ("OK", noackmode); > + // Free any previously set working_dir > + free (working_dir); > + working_dir = NULL; > + if (!split_hexdecode(buf, QSETWORKINGDIR, ":", &working_dir)) { > + continue; // We cannot report the error to gdb... > + } > + DEBUG(1, "set working dir to: %s\n", working_dir); > + } else if (strncmp(XFER, buf, strlen(XFER)) == 0) { > + char *buf_dup = strdup(buf); > + DEBUG(1, "strdup: buf_dup %s\n", buf_dup); > + if (buf_dup) { > + const char *delim = ":"; > + size_t count = count_delims(delim[0], buf); > + if (count < 4) { > + strsep(&buf_dup, delim); > + strsep(&buf_dup, delim); > + strsep(&buf_dup, delim); > + char *decoded_string = decode_hexstring (buf_dup, 0, 0); > + DEBUG(1, "qXfer decoded: %s, buf_dup %s\n", decoded_string, buf_dup); > + free (decoded_string); > + } > + free (buf_dup); > + } else { > + DEBUG(1, "qXfer decoding error: strdup of %s failed!\n", buf); > + free (buf_dup); > + continue; > + } > + // Whether we could decode it or not, we cannot handle it now. We > + // need valgrind gdbserver to properly reply. So error out here. > + send_packet ("E00", noackmode); > + } else if (strncmp(QTSTATUS, buf, strlen(QTSTATUS)) == 0) { > + // We don't support trace experiments > + DEBUG(1, "Got QTSTATUS\n"); > + send_packet ("", noackmode); > + } else if (strcmp("qfThreadInfo", buf) == 0) { > + DEBUG(1, "Got qfThreadInfo\n"); > + /* There are no threads yet, reply 'l' end of list. */ > + send_packet ("l", noackmode); > + } else if (buf[0] != '\0') { > + // We didn't understand. > + DEBUG(1, "Unknown packet received: '%s'\n", buf); > + bad_unknown_packets++; > + if (bad_unknown_packets > 10) { > + DEBUG(1, "Too many bad/unknown packets received\n"); > + break; > + } > + send_packet ("", noackmode); > + } > + } > + DEBUG(1, "done doing multi stuff...\n"); > + free(working_dir); > + free(buf); > + free(q_buf); > + > + shutting_down = True; > + close (to_gdb); > + close (from_gdb); > +} > + > +/* Relay data between gdb and Valgrind gdbserver, till EOF or an error is > + encountered. q_buf is the qSupported packet received from gdb. */ > +static > +void gdb_relay(int pid, int send_noack_mode, char *q_buf) > { > int from_pid = -1; /* fd to read from pid */ > int to_pid = -1; /* fd to write to pid */ > @@ -863,6 +1569,16 @@ void gdb_relay(int pid) ... > @@ -1379,6 +2135,7 @@ void parse_options(int argc, char** argv, > TSFPRINTF(stderr, "%s is not a correct path. %s, exiting.\n", path, strerror (errno)); Line too long. ... > // argc - i is the number of left over arguments > // allocate enough space, but all args in it. Not clear what is meant by 'but all args in it.' > @@ -1275,6 +1298,19 @@ Therefore, it has two usage modes: > </para> > </listitem> > > + <listitem id="manual-core-adv.vgdb-multi" xreflabel="vgdb multi"> > + <para>In the <option>--multi</option> mode, Vgdb uses the extended Elsewhere in the doc, we use vgdb, not Vgdb. > + remote protocol to communicate with Gdb. This allows you to view And we use GDB, not Gdb. > + output from both valgrind and GDB in the GDB session. This is > + accomplished via the "target extended-remote | vgdb --multi". In > + this mode you no longer need to start valgrind yourself. vgdb will > + start up valgrind when gdb tells it to run a new program. For this > + usage, the vgdb OPTIONS(s) can also include <option>--valgrind</option> > + and <option>--vargs</option> to describe how valgrind should be > + started. > + </para> > + </listitem> |
|
From: Paul F. <pj...@wa...> - 2023-04-15 19:43:30
|
On 15-04-23 19:58, Philippe Waroquiers via Valgrind-developers wrote:
> Not too sure what is going wrong/what I am doing wrong ...
> (tested with 53834800424510b177c59d097c3a51a66bbaf659)
At first I tried running from the build dir, but that was complicated so
I switched to using it from my home dir install.
I also use the following functions in my .gdbinit file (hopefully this
will become easier eventually). It works, but doesn't allow you to
specify your own --vargs
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
A+
Paul
|
|
From: Philippe W. <phi...@sk...> - 2023-04-15 17:58:27
|
On Thu, 2023-04-13 at 22:09 +0000, Mark Wielaard wrote: > +* The vgdb utility now supports extended-remote protocol when > + invoked with --multi. In this mode the GDB run command is > + supported. Which means you don't need to run gdb and valgrind > + from different terminals. So for example to start you program > + in gdb and run it under valgrind you can do: > + $ gdb prog > + (gdb) set remote exec-file prog > + (gdb) set sysroot / > + (gdb) target extended-remote | vgdb --multi > + (gdb) start Thanks to Mark and Alexandra for this work (and sorry for the lack of earlier feedback about this). I did some tests: philippe@md:gdbserver_tests$ gdb sleepers GNU gdb (GDB) 14.0.50.20230402-git Copyright (C) 2023 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-pc-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <https://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Loaded DUEL.py 0.9.6, high level data exploration language Reading symbols from sleepers... (gdb) set remote exec-file sleepers (gdb) set sysroot / (gdb) target extended-remote | vgdb --multi Remote debugging using | vgdb --multi (gdb) start Temporary breakpoint 1 at 0x16fc: file sleepers.c, line 138. Starting program: /home/philippe/valgrind/git/trunk_untouched/gdbserver_tests/sleepers valgrind: sleepers: command not found syscall failed: No such file or directory error opening /tmp/vgdb-pipe-shared-mem-vgdb-52790-by-philippe-on-md shared memory file Remote communication error. Target disconnected.: Connection reset by peer. (gdb) The problem is solved by giving an absolute path for the remote exec-file: (gdb) set remote exec-file /home/philippe/valgrind/git/trunk_untouched/gdbserver_tests/sleepers So, it looks like gdb knows the absolute path of the program to launch, but does not pass it to valgrind. It might be possible to have the full path given to vgdb ? The vgdb --help output is missing the --valgrind and the --vargs in the OPTIONS summary: OPTIONS are [--pid=<number>] [--vgdb-prefix=<prefix>] [--wait=<number>] [--max-invoke-ms=<number>] [--port=<portnr> [--cmd-time-out=<number>] [-l] [-T] [-D] [-d] [--multi] The vgdb --help is missing \n after the --vargs description: --vargs everything that follows is an argument for valgrind. -l arg tells to show the list of running Valgrind gdbserver and then exit. For --valgrind, pass the path to valgrind to use. If not specified, the system valgrind will be launched. Wouldn't it better (if possible) to by default launch the valgrind found at the same place as where vgdb is found ? Finally, once giving an absolute remote exec-file and an absolute path to the valgrind to launch, I cannot have it working: gdb sleepers GNU gdb (GDB) 14.0.50.20230402-git Copyright (C) 2023 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-pc-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <https://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Loaded DUEL.py 0.9.6, high level data exploration language Reading symbols from sleepers... (gdb) set remote exec-file /home/philippe/valgrind/git/trunk_untouched/gdbserver_tests/sleepers (gdb) set sysroot / (gdb) target extended-remote | vgdb --multi --valgrind=/home/philippe/valgrind/git/trunk_untouched/Inst/bin/valgrind Remote debugging using | vgdb --multi --valgrind=/home/philippe/valgrind/git/trunk_untouched/Inst/bin/valgrind (gdb) start Temporary breakpoint 1 at 0x16fc: file sleepers.c, line 138. Starting program: /home/philippe/valgrind/git/trunk_untouched/gdbserver_tests/sleepers ==100738== Memcheck, a memory error detector ==100738== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al. ==100738== Using Valgrind-3.21.0.RC1 and LibVEX; rerun with -h for copyright info ==100738== Command: /home/philippe/valgrind/git/trunk_untouched/gdbserver_tests/sleepers ==100738== relaying data between gdb and process 100738 syscall failed: Resource temporarily unavailable error reading static buf readchar syscall failed: Resource temporarily unavailable readchar no ack mode: unexpected buflen -1, buf Unknown remote qXfer reply: 1 (gdb) quit Not too sure what is going wrong/what I am doing wrong ... (tested with 53834800424510b177c59d097c3a51a66bbaf659) Thanks Philippe |
|
From: Paul F. <pj...@wa...> - 2023-04-15 11:29:04
|
Hi Here's a list of the items that, time permitting, I'd like to get into 3.21. Plus any recently-released FreeBSD 13.2 fixes. inconsistent RDTSCP support on x86_64 https://bugs.kde.org/show_bug.cgi?id=374596 I was recently contacted by the patch author for this one. It's a bit tricky to test as it requires ancient hardware or some sort of virtualization. That or a good knowledge of all possible hwcaps combinations. Likely false positive "uninitialised value(s)" for __wmemchr_avx2 and __wmemcmp_avx2_movbe https://bugs.kde.org/show_bug.cgi?id=397083 Looks fairly straightforward, I just need to find a machine less old than mine to test it on. Enhancement: add a client request to DHAT to mark memory to be histogrammed https://bugs.kde.org/show_bug.cgi?id=464103 Again fairly simple and straightforward. Add mismatched detection to C++ 17 aligned new/delete https://bugs.kde.org/show_bug.cgi?id=433859 Add validation to C++17 aligned new/delete alignment size https://bugs.kde.org/show_bug.cgi?id=433857 Add mismatched detection to C++ 14 sized delete https://bugs.kde.org/show_bug.cgi?id=467441 aligned_alloc problems, part 2 https://bugs.kde.org/show_bug.cgi?id=466105 There's a lot of stuff there (patch in the first bugzi item). All the C++ stuff is nice to have (and mostly also covered by ASan) but I don't think that that kind of error happens frequently in the wild. memalign and aligned alloc are more likely to be useful for detecting implementation defined behaviour. A+ Paul |
|
From: Mark W. <ma...@kl...> - 2023-04-15 02:07:05
|
An RC1 tarball for 3.21.0 is now available at https://sourceware.org/pub/valgrind/valgrind-3.21.0.RC1.tar.bz2 (md5sum = a3c7eeff47262cecdf5f1d68b38710b7) (sha1sum = 46fc5898415001e045abc1b4e2909a41144ed9c4) https://sourceware.org/pub/valgrind/valgrind-3.21.0.RC1.tar.bz2.asc Please give it a try in configurations that are important for you and report any problems you have, either on this mailing list, or (preferably) via our bug tracker at https://bugs.kde.org/enter_bug.cgi?product=valgrind There are still some patches being reviewed and a RC2 will appear end of next week. If nothing critical emerges after that, a final release will happen on Friday 28 April. |
|
From: Nicholas N. <n.n...@gm...> - 2023-04-15 01:50:36
|
On Sat, 15 Apr 2023 at 11:00, Mark Wielaard <ma...@kl...> wrote: > > When you add the doc changes could you also add a NEWS entry? > Yes, it's on my todo list. > Note that under --branch-sim=no|yes [no] cachegrind/docs/cg-manual.xml > says: > > <para>Enables or disables collection of branch instruction and > misprediction counts. By default this is disabled as it > slows Cachegrind down by approximately 25%. Note that you > cannot specify <option>--cache-sim=no</option> > and <option>--branch-sim=no</option> > together, as that would leave Cachegrind with no > information to collect.</para> > > Which seems untrue now that both --cache-sim= and --branch-sim= > default to no. > True, I will update that. Nick |
|
From: Mark W. <ma...@so...> - 2023-04-15 01:49:45
|
https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=53834800424510b177c59d097c3a51a66bbaf659 commit 53834800424510b177c59d097c3a51a66bbaf659 Author: Mark Wielaard <ma...@kl...> Date: Sat Apr 15 03:49:15 2023 +0200 Set version to 3.21.0-RC1 Diff: --- NEWS | 2 +- configure.ac | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/NEWS b/NEWS index e8225fdd40..a8ab817e17 100644 --- a/NEWS +++ b/NEWS @@ -157,7 +157,7 @@ To see details of a given bug, visit https://bugs.kde.org/show_bug.cgi?id=XXXXXX where XXXXXX is the bug number as listed above. -(3.21.0.RC1: ?? Apr 2023) +(3.21.0.RC1: 14 Apr 2023) Release 3.20.0 (24 Oct 2022) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ diff --git a/configure.ac b/configure.ac index 80bdbb417c..66437a8000 100755 --- a/configure.ac +++ b/configure.ac @@ -17,8 +17,8 @@ m4_define([v_major_ver], [3]) m4_define([v_minor_ver], [21]) m4_define([v_micro_ver], [0]) -m4_define([v_suffix_ver], [GIT]) -m4_define([v_rel_date], ["?? Apr 2023"]) +m4_define([v_suffix_ver], [RC1]) +m4_define([v_rel_date], ["14 Apr 2023"]) m4_define([v_version], m4_if(v_suffix_ver, [], [v_major_ver.v_minor_ver.v_micro_ver], |
|
From: Mark W. <ma...@kl...> - 2023-04-15 01:01:02
|
Hi Nick,
On Wed, Apr 12, 2023 at 03:48:15AM +0000, Nicholas Nethercote wrote:
> Make `--cache-sim=no` the default for Cachegrind.
>
> Also, don't print cache simulation details in the `desc:` line when the
> cache simulation is disabled.
>
> Docs changes are yet to come.
When you add the doc changes could you also add a NEWS entry?
Note that under --branch-sim=no|yes [no] cachegrind/docs/cg-manual.xml
says:
<para>Enables or disables collection of branch instruction and
misprediction counts. By default this is disabled as it
slows Cachegrind down by approximately 25%. Note that you
cannot specify <option>--cache-sim=no</option>
and <option>--branch-sim=no</option>
together, as that would leave Cachegrind with no
information to collect.</para>
Which seems untrue now that both --cache-sim= and --branch-sim=
default to no.
Thanks,
Mark
|