Re: [RFC PATCH v3 3/3] perf tools: Support sparc user register samples and dwarf unwinding

[Stian Halseth <stian@itx.no>]

[-- Attachment #1: Type: text/plain, Size: 2589 bytes --]

On Wed, 2026-09-23 at 09:14 +0000, sashiko-bot@kernel.org wrote:
> 
> > +	case PERF_REG_SPARC_Y:
> > +		return "y";
> > +	default:
> > +		return NULL;
> > +	}
> > +
> > +	return NULL;
> 
> [Severity: Low]
> Does this rely on implicit header inclusion for NULL?
> 
> The NULL macro is used here, but neither <stddef.h> nor <stdlib.h> is
> explicitly included in this file. It appears to rely on the implicit
> inclusion
> of <stdlib.h> via the ../../arch/sparc/include/perf_regs.h header.
> 
> Should this explicitly include <stddef.h> or <stdlib.h>?

My take is: No.

perf_regs.h includes <stdlib.h>

It's done like this to maintain consistency with perf_regs_arm.c,
perf_regs_mips.c and perf_regs_loongarch.c.



> > +/*
> > + * The sampled window's %l and %i registers (DWARF 16-31) are not
> > in the
> > + * sample; the kernel flushed them to the register save area at
> > the start
> > + * of the dumped stack.
> > + */
> > +static void libdw_set_sparc_window_registers(struct unwind_info
> > *ui,
> > +					     struct regs_dump
> > *user_regs,
> > +					     Dwarf_Word
> > *dwarf_regs)
> > +{
> > +	struct stack_dump *stack = &ui->sample->user_stack;
> > +	u64 sp;
> > +
> > +	if (perf_reg_value(&sp, user_regs, perf_arch_reg_sp(ui-
> > >e_machine)))
> > +		return;
> > +	if (!(sp & 1) || 16 * sizeof(u64) > stack->size)
> > +		return;
> > +
> > +	memcpy(&dwarf_regs[16], stack->data, 16 * sizeof(u64));
> 
> [Severity: Medium]
> When analyzing a SPARC perf.data file on a little-endian host, will
> this
> memcpy() write raw big-endian bytes into the little-endian host
> variables?
> 
> The dwarf_regs array is composed of Dwarf_Word (uint64_t) elements
> and expects
> values in host endianness, while the stack dump (stack->data) retains
> the
> target's original memory layout and endianness (SPARC is strictly
> big-endian).
> 
> This can cause the 64-bit integer values read by libdw to be byte-
> swapped,
> breaking cross-architecture DWARF unwinding for SPARC as the stack
> unwinder
> relies on %i6 and %i7 (DWARF registers 30 and 31) to find the
> caller's frame.
> 
> Should this code perform conditional byte-swapping when copying from
> the stack
> dump?

No.

Checked by analyzing a sparc64 perf.data on x86 with this series.

unwinds leaf -> mid2 -> mid1 -> main -> __libc_start_main -> _start,
the same as on the SPARC T4.

The dump of a 64-bit sparc stack starts at %sp + 2047. It's 16-byte
aligned, so each saved register is one swap unit and is already in host
order.



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 228 bytes --]