Re: [PATCH] aarch64: Fix an infinite loop on bt when the core dump has an SVE section but the target does not support it.

[Luis Machado <luis.machado@arm.com>]

Hi,

On 3/29/23 13:42, Дмитро Медвєдь wrote:
> Hi Luis,
> 
> On Mon, Mar 27, 2023 at 12:43 PM Luis Machado <luis.machado@arm.com> wrote:
>> Hi,
>>
>> That's interesting. If the target doesn't support SVE, why is the SVE_MAGIC context being generated in the first place?
>>
>> It should've been handled by the default case, where we increment the section by the size.
>>
>> If gdb knows about SVE, it should be able to handle it, unless the target says the vector length is 0.
>>
>> Could you please clarify what target you observed this on?
> 
> The core dump was generated on the Amazon EC2 instance that is powered
> by Arm-based AWS Graviton3 processor. It was not generated by gdb. To
> make the core dump a modification of a third party tool
> https://github.com/Percona-Lab/coredumper was used.  I assume that
> this coredumper does not write all the info that is needed for gdb to
> resolve the SVE section correctly.

Thanks for the additional information. That's very useful to give the bug
some context.

> 
> I will prepare a minimal working example which reproduces the issue
> with modified Percona-Lab coredumper and will provide the source and

I don't think that's going to be needed.

> the core dump, but I still think that infinite loop should be fixed in
> gdb as well and maybe a warning should be added in this case.

I agree. Even if it is a case of inconsistent state/data, gdb should still be able
to cope with it gracefully. A warning would be appropriate, stating SVE state has
been found, but it is being skipped because the target hasn't reported SVE support.

Do you have a copyright assignment with the FSF so we can take your contribution? The patch
may be trivial, but I thought I'd check anyway.