public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Pedro Alves <pedro@palves.net>
To: Thiago Jung Bauermann <thiago.bauermann@linaro.org>,
	Luis Machado <luis.machado@arm.com>
Cc: Simon Marchi <simark@simark.ca>,
	Andrew Burgess <aburgess@redhat.com>,
	Thiago Jung Bauermann via Gdb-patches
	<gdb-patches@sourceware.org>
Subject: Re: [PATCH v3 4/8] gdbserver/linux-aarch64: When thread stops, update its target description
Date: Mon, 6 Feb 2023 20:29:04 +0000	[thread overview]
Message-ID: <045c1e09-5b6d-22b6-df7a-39cfa339b0e1@palves.net> (raw)
In-Reply-To: <87leldmp6r.fsf@linaro.org>

On 2023-02-04 3:21 p.m., Thiago Jung Bauermann via Gdb-patches wrote:
> 
> Luis Machado <luis.machado@arm.com> writes:
> 
>> On 2/2/23 03:47, Simon Marchi wrote:
>>> On 2/1/23 21:54, Thiago Jung Bauermann wrote:
>>>> In any case, it wouldn't be possible to make get_thread_target_desc just
>>>> return thread_info->tdesc because at least the way these patches are
>>>> currently written, when the inferior starts or a new thread of the
>>>> inferior is spawned thread_info->tdesc is nullptr. gdbserver will only
>>>> call get_thread_tdesc after the first stop (in get_thread_regcache, in
>>>> the process of obtaining the pc register), so we will need to cope with
>>>> that situation.
>>> Ok.  Would it work if a new thread initially inherited the tdesc from
>>> its process?
>>>
>>
>> It should be fine because the first time we fetch a process target
>> description, it is eventually obtained from the first and only thread.
>> So the SVE vector length should be correct.
>>
>> Any subsequent attempts to use the process' target description (the
>> first one we obtained), after further stops, may end up using an
>> incorrect description.
>>
>> I think this is handled correctly by the target architecture target
>> hook though. But there are other places where this is potentially
>> incorrect.
>>
>> For example...
>>
>> - When using gcore to dump a core file, GDB only dumps a single target
>> description. While this might be correct for a target with a fixed
>> target description or a AArch64 target that doesn't support SVE, it
>> likely won't be correctly for one AArch64 target supporting SVE if its
>> threads changed vector length mid-execution. Either we emit target
>> description notes by thread, or we don't emit a target description
>> note for those cases.
>>
>> - When loading the above/older gcore core files back, GDB will use a
>> potentially incorrect target description. If we decide to emit
>> per-thread target descriptions, it should be fine. Otherwise we may
>> need to have a "thread architecture" hook for core files as well.
>>
>> - The remote has no concept of a thread architecture (Thiago is
>> addressing this with this patch series).
>>
>> - AArch64 frames may have slightly different vg values, which means
>> their gdbarches are different as well.
>>
>> Given the differences between two gdbarches are small, we mostly get
>> away with it. But if there are further differences (different hooks,
>> for example), I fear we may run into a situation where we use an
>> incorrect gdbarch to call a particular hook.
> 
> Indeed, good points! Thank you for bringing them up. I can address core
> file dumping/loading after this series.
> 
> Regarding frames with different vg values, it's important to be aware of
> this discrepancy but IMHO it makes sense to work on it when it becomes
> a problem...
> 


Yeah, one thought that keeps crossing my mind is if really modeling all this
stuff as different target descriptions is really the best approach.  The Intel AMX
support posted on the list last year also ran into a similar problem, with the 
matrix registers height/width changing at runtime, and it is impractical (or really,
it really smells like the wrong approach) to have different target descriptions for
every potential matrix size.  Which is not unlike different SVE sizes.  It feels like
a single tdesc should be able to be a bit more dynamic.  It's a bit funny that ptrace
manages to work with a single registers interface, while we don't.

What if we extended the target description mechanism so that a single description
could describe all SVE sizes?  For example, what if a tdesc could describe the SVE
width/length as a dynamic property, retrieved from elsewhere, e.g., from another register?

BTW, for core files, where are we going to retrieve the SVE length from?

  parent reply	other threads:[~2023-02-06 20:29 UTC|newest]

Thread overview: 94+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-30  4:45 [PATCH v3 0/8] gdbserver improvements for AArch64 SVE support Thiago Jung Bauermann
2023-01-30  4:45 ` [PATCH v3 1/8] gdbserver: Add assert in find_register_by_number Thiago Jung Bauermann
2023-01-31 17:05   ` Simon Marchi
2023-01-31 19:49     ` Thiago Jung Bauermann
2023-02-01 15:43       ` Simon Marchi
2023-01-30  4:45 ` [PATCH v3 2/8] gdbserver: Add PID parameter to linux_get_auxv and linux_get_hwcap Thiago Jung Bauermann
2023-02-01  9:07   ` Luis Machado
2023-02-01 10:54   ` Andrew Burgess
2023-02-01 16:01     ` Simon Marchi
2023-02-01 19:33       ` Thiago Jung Bauermann
2023-02-01 19:53         ` Simon Marchi
2023-02-01 21:55           ` Thiago Jung Bauermann
2023-02-06 19:54   ` Pedro Alves
2023-02-06 20:16     ` Simon Marchi
2023-02-07 15:19       ` Pedro Alves
2023-02-07 21:47         ` Thiago Jung Bauermann
2023-02-09  1:31           ` Simon Marchi
2023-02-10  3:54             ` Thiago Jung Bauermann
2023-02-07 22:28     ` Thiago Jung Bauermann
2023-01-30  4:45 ` [PATCH v3 3/8] gdbserver/linux-aarch64: Factor out function to get aarch64_features Thiago Jung Bauermann
2023-02-01  8:59   ` Luis Machado
2023-02-01 16:04     ` Simon Marchi
2023-02-01 22:13       ` Thiago Jung Bauermann
2023-01-30  4:45 ` [PATCH v3 4/8] gdbserver/linux-aarch64: When thread stops, update its target description Thiago Jung Bauermann
2023-02-01  9:05   ` Luis Machado
2023-02-01 11:06   ` Andrew Burgess
2023-02-01 16:21     ` Simon Marchi
2023-02-01 16:32       ` Luis Machado
2023-02-02  2:54         ` Thiago Jung Bauermann
2023-02-02  3:47           ` Simon Marchi
2023-02-03  3:47             ` Thiago Jung Bauermann
2023-02-03 11:13               ` Luis Machado
2023-02-04 15:26                 ` Thiago Jung Bauermann
2023-02-03 11:11             ` Luis Machado
2023-02-04 15:21               ` Thiago Jung Bauermann
2023-02-06  9:07                 ` Luis Machado
2023-02-06 12:15                   ` Thiago Jung Bauermann
2023-02-06 20:29                 ` Pedro Alves [this message]
2023-02-07  8:11                   ` Luis Machado
2023-02-07 14:39                     ` Thiago Jung Bauermann
2023-02-03 10:57           ` Luis Machado
2023-02-04  6:18             ` Thiago Jung Bauermann
2023-02-06 20:26           ` Pedro Alves
2023-02-07 21:06             ` Thiago Jung Bauermann
2023-02-09  2:46               ` Simon Marchi
2023-02-10  3:29                 ` Thiago Jung Bauermann
2023-02-10 14:56                   ` Luis Machado
2023-02-10 15:04                     ` Tom Tromey
2023-02-10 15:28                       ` Luis Machado
2023-02-10 17:26                       ` Thiago Jung Bauermann
2023-02-10 21:01                         ` Simon Marchi
2023-01-30  4:45 ` [PATCH v3 5/8] gdbserver: Transmit target description ID in thread list and stop reply Thiago Jung Bauermann
2023-01-30 12:52   ` Eli Zaretskii
2023-01-30 14:05     ` Thiago Jung Bauermann
2023-02-01  9:39   ` Luis Machado
2023-02-01 12:07   ` Andrew Burgess
2023-02-01 13:03     ` Eli Zaretskii
2023-02-01 17:37     ` Simon Marchi
2023-02-02 20:36       ` Thiago Jung Bauermann
2023-02-02 20:56         ` Simon Marchi
2023-02-01 20:46     ` Simon Marchi
2023-02-02 21:43       ` Thiago Jung Bauermann
2023-02-01 14:51   ` Andrew Burgess
2023-02-01 17:03     ` Simon Marchi
2023-02-02 19:52       ` Thiago Jung Bauermann
2023-02-02 20:51         ` Simon Marchi
2023-02-03  2:44           ` Thiago Jung Bauermann
2023-02-03 16:29             ` Andrew Burgess
2023-02-04  6:08               ` Thiago Jung Bauermann
2023-02-03 11:22       ` Luis Machado
2023-02-03 12:50         ` Simon Marchi
2023-01-30  4:45 ` [PATCH v3 6/8] gdb/remote: Parse tdesc field in stop reply and threads list XML Thiago Jung Bauermann
2023-02-01  9:52   ` Luis Machado
2023-02-05  0:06     ` Thiago Jung Bauermann
2023-02-06  9:10       ` Luis Machado
2023-02-01 14:32   ` Andrew Burgess
2023-02-01 19:50     ` Simon Marchi
2023-02-01 20:16       ` Simon Marchi
2023-02-03 11:27         ` Luis Machado
2023-02-03 13:19           ` Simon Marchi
2023-02-03 16:33             ` Andrew Burgess
2023-01-30  4:45 ` [PATCH v3 7/8] gdb/aarch64: Detect vector length changes when debugging remotely Thiago Jung Bauermann
2023-02-01  9:58   ` Luis Machado
2023-02-01 15:26   ` Andrew Burgess
2023-02-01 20:20     ` Simon Marchi
2023-02-03 11:31       ` Luis Machado
2023-02-03 16:38       ` Andrew Burgess
2023-02-03 19:07         ` Simon Marchi
2023-01-30  4:45 ` [PATCH v3 8/8] gdb/testsuite: Add test to exercise multi-threaded AArch64 SVE inferiors Thiago Jung Bauermann
2023-02-01 10:10   ` Luis Machado
2023-02-06 19:11 ` [PATCH v3 0/8] gdbserver improvements for AArch64 SVE support Pedro Alves
2023-02-06 20:05   ` Simon Marchi
2023-02-06 21:06     ` Pedro Alves
2023-02-07 13:49       ` Simon Marchi

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=045c1e09-5b6d-22b6-df7a-39cfa339b0e1@palves.net \
    --to=pedro@palves.net \
    --cc=aburgess@redhat.com \
    --cc=gdb-patches@sourceware.org \
    --cc=luis.machado@arm.com \
    --cc=simark@simark.ca \
    --cc=thiago.bauermann@linaro.org \
    /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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).