From: Simon Marchi via Gdb-patches <gdb-patches@sourceware.org>
To: Luis Machado <luis.machado@linaro.org>, gdb-patches@sourceware.org
Cc: david.spickett@linaro.org
Subject: Re: [PATCH v3 13/24] Refactor parsing of /proc/<pid>/smaps
Date: Sat, 26 Dec 2020 01:36:52 -0500 [thread overview]
Message-ID: <e5ba29f7-1ef2-58d4-0e7a-afa19c4ed25f@polymtl.ca> (raw)
In-Reply-To: <20201109170435.15766-14-luis.machado@linaro.org>
On 2020-11-09 12:04 p.m., Luis Machado via Gdb-patches wrote:
> The Linux kernel exposes the information about MTE-protected pages via the
> proc filesystem, more specifically through the smaps file.
>
> What we're looking for is a mapping with the 'mt' flag, which tells us that
> mapping was created with a PROT_MTE flag and, thus, is capable of using memory
> tagging.
>
> We already parse that file for other purposes (core file
> generation/filtering), so this patch refactors the code to make the parsing
> of the smaps file reusable for memory tagging.
>
> The function linux_address_in_memtag_page uses the refactored code to allow
> querying for memory tag support in a particular address, and it gets used in the
> next patch.
>
> gdb/ChangeLog:
>
> YYYY-MM-DD Luis Machado <luis.machado@linaro.org>
>
> * linux-tdep.c (struct smaps_vmflags) <memory_tagging>: New flag
> bit.
> (struct smaps_data): New struct.
> (decode_vmflags): Handle the 'mt' flag.
> (parse_smaps_data): New function, refactored from
> linux_find_memory_regions_full.
> (linux_address_in_memtag_page): New function.
> (linux_find_memory_regions_full): Refactor into parse_smaps_data.
> * linux-tdep.h (linux_address_in_memtag_page): New prototype.
> ---
> gdb/linux-tdep.c | 358 +++++++++++++++++++++++++++++++----------------
> gdb/linux-tdep.h | 4 +
> 2 files changed, 241 insertions(+), 121 deletions(-)
>
> diff --git a/gdb/linux-tdep.c b/gdb/linux-tdep.c
> index bacb61398f..91bdcc133b 100644
> --- a/gdb/linux-tdep.c
> +++ b/gdb/linux-tdep.c
> @@ -86,8 +86,33 @@ struct smaps_vmflags
> /* Is this a MAP_SHARED mapping (VM_SHARED, "sh"). */
>
> unsigned int shared_mapping : 1;
> +
> + /* Memory map has memory tagging enabled. */
> +
> + unsigned int memory_tagging : 1;
> };
>
> +/* Data structure that holds the information contained in the
> + /proc/<pid>/smaps file. */
> +
> +struct smaps_data
> +{
> + ULONGEST start_address;
> + ULONGEST end_address;
> + std::string filename;
> + struct smaps_vmflags vmflags;
> + bool read;
> + bool write;
> + bool exec;
> + bool priv;
> + bool has_anonymous;
> + bool mapping_anon_p;
> + bool mapping_file_p;
> +
> + ULONGEST inode;
> + ULONGEST offset;
> +};
> +
> /* Whether to take the /proc/PID/coredump_filter into account when
> generating a corefile. */
>
> @@ -472,6 +497,8 @@ decode_vmflags (char *p, struct smaps_vmflags *v)
> v->exclude_coredump = 1;
> else if (strcmp (s, "sh") == 0)
> v->shared_mapping = 1;
> + else if (strcmp (s, "mt") == 0)
> + v->memory_tagging = 1;
> }
> }
>
> @@ -1267,6 +1294,184 @@ typedef int linux_dump_mapping_p_ftype (filter_flags filterflags,
> const char *filename,
> ULONGEST addr,
> ULONGEST offset);
> +/* Helper function to parse the contents of /proc/<pid>/smaps into a data
> + structure, for easy access.
> +
> + DATA is the contents of the smaps file. The parsed contents are stored
> + into the SMAPS vector. */
Add a blank line above this comment.
> +
> +static int
> +parse_smaps_data (const char *data,
> + std::vector<struct smaps_data> &smaps,
> + const char *mapsfilename)
The return value of that function is unused, it always return 0. I'd suggest
making it return the std::vector directly.
> +{
> + char *line, *t;
> +
> + gdb_assert (data != nullptr);
> +
> + smaps.clear ();
> +
> + line = strtok_r ((char *) data, "\n", &t);
> +
> + while (line != NULL)
> + {
> + ULONGEST addr, endaddr, offset, inode;
> + const char *permissions, *device, *filename;
> + struct smaps_vmflags v;
> + size_t permissions_len, device_len;
> + int read, write, exec, priv;
> + int has_anonymous = 0;
> + int mapping_anon_p;
> + int mapping_file_p;
> +
> + memset (&v, 0, sizeof (v));
> + read_mapping (line, &addr, &endaddr, &permissions, &permissions_len,
> + &offset, &device, &device_len, &inode, &filename);
> + mapping_anon_p = mapping_is_anonymous_p (filename);
> + /* If the mapping is not anonymous, then we can consider it
> + to be file-backed. These two states (anonymous or
> + file-backed) seem to be exclusive, but they can actually
> + coexist. For example, if a file-backed mapping has
> + "Anonymous:" pages (see more below), then the Linux
> + kernel will dump this mapping when the user specified
> + that she only wants anonymous mappings in the corefile
> + (*even* when she explicitly disabled the dumping of
> + file-backed mappings). */
> + mapping_file_p = !mapping_anon_p;
> +
> + /* Decode permissions. */
> + read = (memchr (permissions, 'r', permissions_len) != 0);
> + write = (memchr (permissions, 'w', permissions_len) != 0);
> + exec = (memchr (permissions, 'x', permissions_len) != 0);
> + /* 'private' here actually means VM_MAYSHARE, and not
> + VM_SHARED. In order to know if a mapping is really
> + private or not, we must check the flag "sh" in the
> + VmFlags field. This is done by decode_vmflags. However,
> + if we are using a Linux kernel released before the commit
> + 834f82e2aa9a8ede94b17b656329f850c1471514 (3.10), we will
> + not have the VmFlags there. In this case, there is
> + really no way to know if we are dealing with VM_SHARED,
> + so we just assume that VM_MAYSHARE is enough. */
> + priv = memchr (permissions, 'p', permissions_len) != 0;
> +
> + /* Try to detect if region should be dumped by parsing smaps
> + counters. */
> + for (line = strtok_r (NULL, "\n", &t);
> + line != NULL && line[0] >= 'A' && line[0] <= 'Z';
> + line = strtok_r (NULL, "\n", &t))
> + {
> + char keyword[64 + 1];
> +
> + if (sscanf (line, "%64s", keyword) != 1)
> + {
> + warning (_("Error parsing {s,}maps file '%s'"), mapsfilename);
> + break;
> + }
> +
> + if (strcmp (keyword, "Anonymous:") == 0)
> + {
> + /* Older Linux kernels did not support the
> + "Anonymous:" counter. Check it here. */
> + has_anonymous = 1;
> + }
> + else if (strcmp (keyword, "VmFlags:") == 0)
> + decode_vmflags (line, &v);
> +
> + if (strcmp (keyword, "AnonHugePages:") == 0
> + || strcmp (keyword, "Anonymous:") == 0)
> + {
> + unsigned long number;
> +
> + if (sscanf (line, "%*s%lu", &number) != 1)
> + {
> + warning (_("Error parsing {s,}maps file '%s' number"),
> + mapsfilename);
> + break;
> + }
> + if (number > 0)
> + {
> + /* Even if we are dealing with a file-backed
> + mapping, if it contains anonymous pages we
> + consider it to be *also* an anonymous
> + mapping, because this is what the Linux
> + kernel does:
> +
> + // Dump segments that have been written to.
> + if (vma->anon_vma && FILTER(ANON_PRIVATE))
> + goto whole;
> +
> + Note that if the mapping is already marked as
> + file-backed (i.e., mapping_file_p is
> + non-zero), then this is a special case, and
> + this mapping will be dumped either when the
> + user wants to dump file-backed *or* anonymous
> + mappings. */
> + mapping_anon_p = 1;
> + }
> + }
> + }
> + /* Save the smaps entry to the vector. */
> + struct smaps_data map;
> + std::string fname (filename);
You don't need to create the string here, just do
map.filename = filename;
below.
> +
> + smaps.emplace_back (map);
> + }
> +
> + return 0;
> +}
> +
> +/* See linux-tdep.h. */
> +
> +bool
> +linux_address_in_memtag_page (CORE_ADDR address)
> +{
> + if (current_inferior ()->fake_pid_p)
> + return false;> +
> + pid_t pid = current_inferior ()->pid;
> +
> + std::string smaps_file = string_printf ("/proc/%d/smaps", pid);
> +
> + gdb::unique_xmalloc_ptr<char> data
> + = target_fileio_read_stralloc (NULL, smaps_file.c_str ());
> +
> + if (data == nullptr)
> + return false;
> +
> + std::vector<struct smaps_data> smaps;
> +
> + /* Parse the contents of smaps into a vector. */
> + parse_smaps_data (data.get (), smaps, smaps_file.c_str ());
> +
> + if (!smaps.empty ())
> + {
No need for this `if`.
> + for (struct smaps_data map : smaps)
Iterate by const reference:
for (const smaps_data &map : smaps)
> + {
> + /* Is the address within [start_address, end_address) in a page
> + mapped with memory tagging? */
> + if (address >= map.start_address
> + && address < map.end_address
> + && map.vmflags.memory_tagging)
> + return true;
> + }
> + }
> +
> + return false;
> +}
>
> /* List memory regions in the inferior for a corefile. */
>
> @@ -1276,8 +1481,7 @@ linux_find_memory_regions_full (struct gdbarch *gdbarch,
> linux_find_memory_region_ftype *func,
> void *obfd)
> {
> - char mapsfilename[100];
> - char coredumpfilter_name[100];
> + std::string coredumpfilter_name;
Declare this on first use (we could push some preparatory patches to change
these to std::string, to make this patch simpler).
> pid_t pid;
> /* Default dump behavior of coredump_filter (0x33), according to
> Documentation/filesystems/proc.txt from the Linux kernel
> @@ -1295,10 +1499,9 @@ linux_find_memory_regions_full (struct gdbarch *gdbarch,
>
> if (use_coredump_filter)
> {
> - xsnprintf (coredumpfilter_name, sizeof (coredumpfilter_name),
> - "/proc/%d/coredump_filter", pid);
> + coredumpfilter_name = string_printf ("/proc/%d/coredump_filter", pid);
> gdb::unique_xmalloc_ptr<char> coredumpfilterdata
> - = target_fileio_read_stralloc (NULL, coredumpfilter_name);
> + = target_fileio_read_stralloc (NULL, coredumpfilter_name.c_str ());
> if (coredumpfilterdata != NULL)
> {
> unsigned int flags;
> @@ -1308,125 +1511,39 @@ linux_find_memory_regions_full (struct gdbarch *gdbarch,
> }
> }
>
> - xsnprintf (mapsfilename, sizeof mapsfilename, "/proc/%d/smaps", pid);
> + std::string mapsfilename = string_printf ("/proc/%d/smaps", pid);
> gdb::unique_xmalloc_ptr<char> data
> - = target_fileio_read_stralloc (NULL, mapsfilename);
> + = target_fileio_read_stralloc (NULL, mapsfilename.c_str ());
> if (data == NULL)
> {
> /* Older Linux kernels did not support /proc/PID/smaps. */
> - xsnprintf (mapsfilename, sizeof mapsfilename, "/proc/%d/maps", pid);
> - data = target_fileio_read_stralloc (NULL, mapsfilename);
> + mapsfilename = string_printf ("/proc/%d/maps", pid);
> + data = target_fileio_read_stralloc (NULL, mapsfilename.c_str ());
> }
>
> - if (data != NULL)
> - {
> - char *line, *t;
> -
> - line = strtok_r (data.get (), "\n", &t);
> - while (line != NULL)
> - {
> - ULONGEST addr, endaddr, offset, inode;
> - const char *permissions, *device, *filename;
> - struct smaps_vmflags v;
> - size_t permissions_len, device_len;
> - int read, write, exec, priv;
> - int has_anonymous = 0;
> - int should_dump_p = 0;
> - int mapping_anon_p;
> - int mapping_file_p;
> -
> - memset (&v, 0, sizeof (v));
> - read_mapping (line, &addr, &endaddr, &permissions, &permissions_len,
> - &offset, &device, &device_len, &inode, &filename);
> - mapping_anon_p = mapping_is_anonymous_p (filename);
> - /* If the mapping is not anonymous, then we can consider it
> - to be file-backed. These two states (anonymous or
> - file-backed) seem to be exclusive, but they can actually
> - coexist. For example, if a file-backed mapping has
> - "Anonymous:" pages (see more below), then the Linux
> - kernel will dump this mapping when the user specified
> - that she only wants anonymous mappings in the corefile
> - (*even* when she explicitly disabled the dumping of
> - file-backed mappings). */
> - mapping_file_p = !mapping_anon_p;
> -
> - /* Decode permissions. */
> - read = (memchr (permissions, 'r', permissions_len) != 0);
> - write = (memchr (permissions, 'w', permissions_len) != 0);
> - exec = (memchr (permissions, 'x', permissions_len) != 0);
> - /* 'private' here actually means VM_MAYSHARE, and not
> - VM_SHARED. In order to know if a mapping is really
> - private or not, we must check the flag "sh" in the
> - VmFlags field. This is done by decode_vmflags. However,
> - if we are using a Linux kernel released before the commit
> - 834f82e2aa9a8ede94b17b656329f850c1471514 (3.10), we will
> - not have the VmFlags there. In this case, there is
> - really no way to know if we are dealing with VM_SHARED,
> - so we just assume that VM_MAYSHARE is enough. */
> - priv = memchr (permissions, 'p', permissions_len) != 0;
> -
> - /* Try to detect if region should be dumped by parsing smaps
> - counters. */
> - for (line = strtok_r (NULL, "\n", &t);
> - line != NULL && line[0] >= 'A' && line[0] <= 'Z';
> - line = strtok_r (NULL, "\n", &t))
> - {
> - char keyword[64 + 1];
> + if (data == nullptr)
> + return 1;
>
> - if (sscanf (line, "%64s", keyword) != 1)
> - {
> - warning (_("Error parsing {s,}maps file '%s'"), mapsfilename);
> - break;
> - }
> + std::vector<struct smaps_data> smaps;
>
> - if (strcmp (keyword, "Anonymous:") == 0)
> - {
> - /* Older Linux kernels did not support the
> - "Anonymous:" counter. Check it here. */
> - has_anonymous = 1;
> - }
> - else if (strcmp (keyword, "VmFlags:") == 0)
> - decode_vmflags (line, &v);
> + /* Parse the contents of smaps into a vector. */
> + parse_smaps_data (data.get (), smaps, mapsfilename.c_str ());
>
> - if (strcmp (keyword, "AnonHugePages:") == 0
> - || strcmp (keyword, "Anonymous:") == 0)
> - {
> - unsigned long number;
> -
> - if (sscanf (line, "%*s%lu", &number) != 1)
> - {
> - warning (_("Error parsing {s,}maps file '%s' number"),
> - mapsfilename);
> - break;
> - }
> - if (number > 0)
> - {
> - /* Even if we are dealing with a file-backed
> - mapping, if it contains anonymous pages we
> - consider it to be *also* an anonymous
> - mapping, because this is what the Linux
> - kernel does:
> -
> - // Dump segments that have been written to.
> - if (vma->anon_vma && FILTER(ANON_PRIVATE))
> - goto whole;
> -
> - Note that if the mapping is already marked as
> - file-backed (i.e., mapping_file_p is
> - non-zero), then this is a special case, and
> - this mapping will be dumped either when the
> - user wants to dump file-backed *or* anonymous
> - mappings. */
> - mapping_anon_p = 1;
> - }
> - }
> - }
> + if (!smaps.empty ())
> + {
> + for (struct smaps_data map : smaps)
Same comments as above.
Simon
next prev parent reply other threads:[~2020-12-26 6:37 UTC|newest]
Thread overview: 96+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-09 17:04 [PATCH v3 00/24] Memory Tagging Support + AArch64 Linux implementation Luis Machado via Gdb-patches
2020-11-09 17:04 ` [PATCH v3 01/24] New target methods for memory tagging support Luis Machado via Gdb-patches
2020-12-25 4:26 ` Simon Marchi via Gdb-patches
2020-12-28 15:05 ` Luis Machado via Gdb-patches
2020-12-25 5:08 ` Simon Marchi via Gdb-patches
2020-11-09 17:04 ` [PATCH v3 02/24] New gdbarch memory tagging hooks Luis Machado via Gdb-patches
2020-12-25 4:40 ` Simon Marchi via Gdb-patches
2020-12-28 15:44 ` Luis Machado via Gdb-patches
2020-11-09 17:04 ` [PATCH v3 03/24] Add GDB-side remote target support for memory tagging Luis Machado via Gdb-patches
2020-12-25 5:08 ` Simon Marchi via Gdb-patches
2020-12-28 16:28 ` Luis Machado via Gdb-patches
2020-11-09 17:04 ` [PATCH v3 04/24] Unit testing for GDB-side remote memory tagging handling Luis Machado via Gdb-patches
2020-12-25 5:34 ` Simon Marchi via Gdb-patches
2020-12-28 17:17 ` Luis Machado via Gdb-patches
2020-11-09 17:04 ` [PATCH v3 05/24] GDBserver remote packet support for memory tagging Luis Machado via Gdb-patches
2020-12-25 5:50 ` Simon Marchi via Gdb-patches
2020-12-28 17:46 ` Luis Machado via Gdb-patches
2020-11-09 17:04 ` [PATCH v3 06/24] Unit tests for gdbserver memory tagging remote packets Luis Machado via Gdb-patches
2020-12-25 20:13 ` Simon Marchi via Gdb-patches
2020-12-28 18:12 ` Luis Machado via Gdb-patches
2020-11-09 17:04 ` [PATCH v3 07/24] Documentation for " Luis Machado via Gdb-patches
2020-11-09 17:08 ` Eli Zaretskii via Gdb-patches
2020-11-16 15:44 ` David Spickett via Gdb-patches
2020-11-16 16:04 ` David Spickett via Gdb-patches
2020-11-16 17:22 ` Luis Machado via Gdb-patches
2020-11-17 10:05 ` David Spickett via Gdb-patches
2020-11-17 12:01 ` Luis Machado via Gdb-patches
2020-11-17 12:29 ` David Spickett via Gdb-patches
2020-11-17 14:44 ` Luis Machado via Gdb-patches
2020-11-17 15:16 ` David Spickett via Gdb-patches
2020-11-17 17:29 ` Luis Machado via Gdb-patches
2020-11-18 10:39 ` David Spickett via Gdb-patches
2020-11-18 10:56 ` Luis Machado via Gdb-patches
2020-11-18 11:22 ` David Spickett via Gdb-patches
2020-11-16 16:49 ` Luis Machado via Gdb-patches
2020-11-09 17:04 ` [PATCH v3 08/24] AArch64: Add MTE CPU feature check support Luis Machado via Gdb-patches
2020-12-26 0:04 ` Simon Marchi via Gdb-patches
2020-11-09 17:04 ` [PATCH v3 09/24] AArch64: Add target description/feature for MTE registers Luis Machado via Gdb-patches
2020-12-26 0:10 ` Simon Marchi via Gdb-patches
2020-12-28 18:28 ` Luis Machado via Gdb-patches
2020-11-09 17:04 ` [PATCH v3 10/24] AArch64: Add MTE register set support for GDB and gdbserver Luis Machado via Gdb-patches
2020-12-26 0:17 ` Simon Marchi via Gdb-patches
2020-12-28 18:41 ` Luis Machado via Gdb-patches
2020-11-09 17:04 ` [PATCH v3 11/24] AArch64: Add MTE ptrace requests Luis Machado via Gdb-patches
2020-12-26 0:19 ` Simon Marchi via Gdb-patches
2020-12-28 19:12 ` Luis Machado via Gdb-patches
2020-11-09 17:04 ` [PATCH v3 12/24] AArch64: Implement memory tagging target methods for AArch64 Luis Machado via Gdb-patches
2020-12-26 0:33 ` Simon Marchi via Gdb-patches
2020-12-28 19:50 ` Luis Machado via Gdb-patches
2020-11-09 17:04 ` [PATCH v3 13/24] Refactor parsing of /proc/<pid>/smaps Luis Machado via Gdb-patches
2020-12-26 6:36 ` Simon Marchi via Gdb-patches [this message]
2020-12-29 10:57 ` Luis Machado via Gdb-patches
2020-11-09 17:04 ` [PATCH v3 14/24] AArch64: Implement the memory tagging gdbarch hooks Luis Machado via Gdb-patches
2020-12-26 6:52 ` Simon Marchi via Gdb-patches
2020-12-29 12:16 ` Luis Machado via Gdb-patches
2021-01-18 16:29 ` Simon Marchi via Gdb-patches
2021-01-20 20:01 ` Tom Tromey
2020-11-09 17:04 ` [PATCH v3 15/24] AArch64: Add unit testing for logical tag set/get operations Luis Machado via Gdb-patches
2020-11-09 17:04 ` [PATCH v3 16/24] AArch64: Report tag violation error information Luis Machado via Gdb-patches
2020-11-16 15:43 ` David Spickett via Gdb-patches
2020-11-16 16:45 ` Luis Machado via Gdb-patches
2020-11-17 9:36 ` David Spickett via Gdb-patches
2020-12-26 22:23 ` Simon Marchi via Gdb-patches
2020-12-30 0:50 ` Luis Machado via Gdb-patches
2020-11-09 17:04 ` [PATCH v3 17/24] AArch64: Add gdbserver MTE support Luis Machado via Gdb-patches
2020-12-26 22:30 ` Simon Marchi via Gdb-patches
2020-12-29 14:32 ` Luis Machado via Gdb-patches
2020-11-09 17:04 ` [PATCH v3 18/24] AArch64: Add MTE register set support for core files Luis Machado via Gdb-patches
2020-11-09 17:04 ` [PATCH v3 19/24] New mtag commands Luis Machado via Gdb-patches
2020-12-27 3:32 ` Simon Marchi via Gdb-patches
2020-12-29 17:21 ` Luis Machado via Gdb-patches
2020-11-09 17:04 ` [PATCH v3 20/24] Documentation for the new " Luis Machado via Gdb-patches
2020-11-09 17:11 ` Eli Zaretskii via Gdb-patches
2020-11-09 17:04 ` [PATCH v3 21/24] Extend "x" and "print" commands to support memory tagging Luis Machado via Gdb-patches
2020-11-09 17:14 ` Eli Zaretskii via Gdb-patches
2020-11-09 17:20 ` Luis Machado via Gdb-patches
2020-12-27 4:18 ` Simon Marchi via Gdb-patches
2020-12-29 18:50 ` Luis Machado via Gdb-patches
2021-01-18 17:56 ` Simon Marchi via Gdb-patches
2021-01-18 20:20 ` Luis Machado via Gdb-patches
2020-11-09 17:04 ` [PATCH v3 22/24] Document new "x" and "print" memory tagging extensions Luis Machado via Gdb-patches
2020-11-09 17:16 ` Eli Zaretskii via Gdb-patches
2020-11-09 17:04 ` [PATCH v3 23/24] Add NEWS entry Luis Machado via Gdb-patches
2020-11-09 17:19 ` Eli Zaretskii via Gdb-patches
2020-11-09 17:22 ` Luis Machado via Gdb-patches
2020-11-09 17:04 ` [PATCH v3 24/24] Add memory tagging testcases Luis Machado via Gdb-patches
2020-11-16 15:47 ` David Spickett via Gdb-patches
2020-11-16 16:51 ` Luis Machado via Gdb-patches
2020-12-27 4:36 ` Simon Marchi via Gdb-patches
2020-12-29 19:32 ` Luis Machado via Gdb-patches
2020-11-16 13:48 ` [PATCH v3 00/24] Memory Tagging Support + AArch64 Linux implementation Luis Machado via Gdb-patches
2020-11-16 14:37 ` Alan Hayward via Gdb-patches
2020-11-23 16:08 ` Luis Machado via Gdb-patches
2020-11-30 13:38 ` Luis Machado via Gdb-patches
2020-12-07 13:17 ` Luis Machado via Gdb-patches
2020-12-07 14:17 ` Alan Hayward via Gdb-patches
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=e5ba29f7-1ef2-58d4-0e7a-afa19c4ed25f@polymtl.ca \
--to=gdb-patches@sourceware.org \
--cc=david.spickett@linaro.org \
--cc=luis.machado@linaro.org \
--cc=simon.marchi@polymtl.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox