From: Luis Machado via Gdb-patches <gdb-patches@sourceware.org>
To: Simon Marchi <simon.marchi@polymtl.ca>, gdb-patches@sourceware.org
Cc: david.spickett@linaro.org
Subject: Re: [PATCH v3 13/24] Refactor parsing of /proc/<pid>/smaps
Date: Tue, 29 Dec 2020 07:57:53 -0300 [thread overview]
Message-ID: <b709c687-f563-19b6-b81e-891ebb4fbcf2@linaro.org> (raw)
In-Reply-To: <e5ba29f7-1ef2-58d4-0e7a-afa19c4ed25f@polymtl.ca>
On 12/26/20 3:36 AM, Simon Marchi wrote:
>
>
> 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.
>
Fixed.
>> +
>> +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.
>
There has been some changes to this function. I recall it returning 1 as
well. I've changed it as suggested. It makes it simpler.
>> +{
>> + 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.
>
Fixed.
>> +
>> + 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)
>
Fixed now.
>> + {
>> + /* 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).
>
Yeah. That looks like it will benefit from a cleanup. I'll do as a
separate patch.
>> 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
>
Fixed. Thanks.
next prev parent reply other threads:[~2020-12-29 10:58 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
2020-12-29 10:57 ` Luis Machado via Gdb-patches [this message]
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=b709c687-f563-19b6-b81e-891ebb4fbcf2@linaro.org \
--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