Re: Tracing NetBSD sun4v issues

[Palle Lyckegaard <palle%netbsd.org@localhost>]

On Sun, 18 Oct 2026, Sad Clouds wrote:

> And looking at the registers, value in %fp looks to be truncated in the
> upper 32 bits. It should be similar to the value in %sp:
>
> (gdb) info reg
> g0             0x0                 0
> g1             0xdfb               3579
> g2             0x0                 0
> g3             0x0                 0
> g4             0x0                 0
> g5             0xe8000000000000    65302194596872192
> g6             0x206e69730a        139291357962
> g7             0x40216ac0          1075931840
> o0             0x40a17e80          1084325504
> o1             0x40a03a00          1084242432
> o2             0x0                 0
> o3             0xffffbc00          4294949888
> o4             0x2000              8192
> o5             0x0                 0
> sp             0xffffffffffffb7d1  0xffffffffffffb7d1
> o7             0x40589784          1079547780
> l0             0xe030              57392
> l1             0x40a11a00          1084299776
> l2             0x0                 0
> l3             0x40827d54          1082293588
> l4             0x0                 0
> l5             0x40a0cf28          1084280616
> l6             0x40a00100          1084227840
> l7             0x0                 0
> i0             0x6000              24576
> i1             0x3fff              16383
> i2             0xffffffffffffb881  -18303
> i3             0x40589784          1079547780
> i4             0x8                 8
> i5             0xffffffffffffc3d0  -15408
> fp             0xffffc4b8          0xffffc4b8
> i7             0x40208000          1075871744
> pc             0x40589790          0x40589790 <ecache_alloc_grow+816>
> npc            0x40208008          0x40208008
> state          0x4482000200        294238814720
> fsr            0x0                 [ ]
> fprs           <unavailable>
> y              0x0                 0
> cwp            0x0                 0
> pstate         0x2                 [ IE ]
> asi            0x82                130
> ccr            0x44                [ icc.z xcc.z ]
>
> So what we need to find out is exactly why the frame pointer value gets
> corrupted.

Shoudn't %fp be a odd value?

My understanding is that odd values for %sp and %fp are 64-bit,
whereas even values are for the 32-bit scenario?

The value of %sp looks sane to me though, since the stack grows downwards 
in memory it should be less than %fp.

If we assume that %fp is ok (even if the upper 32-bits are cleared), then 
the difference between %fp and %sp

ffffc4b8 - ffffb7d1 = ce7 (base 16) = 3303 (base 10)

Quickly looking at the code for ecache_alloc_grow() 
https://nxr.netbsd.org/xref/src/external/bsd/jemalloc/dist/src/extent.c#113

I don't understand why more than 3 kB is allocated on the stack.