Re: Tracing NetBSD sun4v issues

[Sad Clouds <cryintothebluesky%gmail.com@localhost>]

On Sun, 18 Oct 2026 18:11:36 +0000 (UTC)
Palle Lyckegaard <palle%netbsd.org@localhost> wrote:

> 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.
> 
> 

Yes, 64-bit ABI incorporates 2047 bytes stack bias, which I think
should be added to the current register value to calculate the actual
memory address, which should be 16-byte aligned.

Below is what the registers in this call chain look like on sun4u at
the start of ecache_alloc_grow() function. And 0xffffffffffffb7c1 -
0xffffffffffffb6f1 = 208 bytes in decimal.

The bad value in %fp may not be valid at all. I said it was truncated,
because the upper 32-bit were set to 0, but it could be any random
value.

(gdb) info reg 
g0             0x0                 0
g1             0x0                 0
g2             0x12                18
g3             0x4a9400            4887552
g4             0x9528              38184
g5             0x1fff              8191
g6             0x206e69730a        139291357962
g7             0x40216ac0          1075931840
o0             0x40216050          1075929168
o1             0x40a03a00          1084242432
o2             0x40a00100          1084227840
o3             0x40a0cf28          1084280616
o4             0x0                 0
o5             0x2000              8192
sp             0xffffffffffffb6f1  0xffffffffffffb6f1
o7             0x4057c264          1079493220
l0             0x0                 0
l1             0x0                 0
l2             0x0                 0
l3             0x0                 0
l4             0x0                 0
l5             0x0                 0
l6             0x0                 0
l7             0x0                 0
i0             0x40216050          1075929168
i1             0x40a03a00          1084242432
i2             0x40a00100          1084227840
i3             0x2000              8192
i4             0x2000              8192
i5             0x0                 0
fp             0xffffffffffffb7c1  0xffffffffffffb7c1
i7             0x4057c3f4          1079493620
pc             0x40589460          0x40589460 <ecache_alloc_grow>
npc            0x40589464          0x40589464 <ecache_alloc_grow+4>
state          0x4482008205        294238847493
fsr            0x0                 [ ]
fprs           <unavailable>
y              0x0                 0
cwp            0x5                 5
pstate         0x82                [ IE ]
asi            0x82                130
ccr            0x44                [ icc.z xcc.z ]