[Crash-utility] Re: Bt -r on IA64

[Dave Anderson]

----- "Dave Anderson" <anderson at redhat.com> wrote:

> This is a post from a non-member that I approved (as list moderator),
> but for some reason it didn't get sent out:
> 
> caiqian at redhat.com wrote:
> > Hi,
> >
> > I would like to check with you about one thing happened on IA64
> only.
> >
> > crash> bt -r
> >
> > ...
> > a0000001007ec100:  0000000000000000 00000000000001f4
> > a0000001007ec110:  0000000000000000 0000000000000000
> > a0000001007ec120:  0000000000000000 0000000000000000
> > a0000001007ec130:  0000000000000000 v+10731618616
> > a0000001007ec140:  v+4808933688     0000000000000000
> > a0000001007ec150:  v+4350567296     0000000000000000
> > a0000001007ec160:  0000000000000000 0000000000000000
> > a0000001007ec170:  0000000000000000 0000000000000000
> > a0000001007ec180:  0000000000000000 0000000000000000
> > a0000001007ec190:  init_task        v+10731618728
> > a0000001007ec1a0:  v+10731618728    init_task+424
> > a0000001007ec1b0:  init_task+424    init_task
> > ...
> >
> > What are those "v+XXXXXXXXXX"?
> >
> > Thanks,
> > Cai Qian
> 
> 
> Yean, you'll also see the same thing if you do a "rd -s <address>",
> like this example:
> 
>   crash> bt -r
>   ...
>   e0000100ff0d1640:  v+1103759521536  v+1103765979464
>   e0000100ff0d1650:  v+1103758983168  scsi_softirq_done+656
>   e0000100ff0d1660:  000000000000030a scsi_execute_async+6928
>   e0000100ff0d1670:  v+1103759521536  000000000251e042
>   ...
>   crash> rd -s e0000100ff0d1640 8
>   e0000100ff0d1640:  v+1103759521536  v+1103765979464
>   e0000100ff0d1650:  v+1103758983168  scsi_softirq_done+656
>   e0000100ff0d1660:  000000000000030a scsi_execute_async+6928
>   e0000100ff0d1670:  v+1103759521536  000000000251e042
>   crash>
> 
> The "v+offset" values are translations of unity-mapped (ia64 region 7)
> kernel virtual addresses:
> 
>   crash> rd e0000100ff0d1640 8
>   e0000100ff0d1640:  e0000100fd31b700 e0000100fd944148  
> ..1.....HA......
>   e0000100ff0d1650:  e0000100fd298000 a000000203f9bb90  
> ..).............
>   e0000100ff0d1660:  000000000000030a a000000203fbc3d0  
> ................
>   e0000100ff0d1670:  e0000100fd31b700 000000000251e042  
> ..1.....B.Q.....
>   crash>
> 
> which are seen as offsets from the closest "symbol", which is "v":
> 
>   crash> sym -l
>   ...
>   a000000100dc1e00 (b) xfrm_state_gc_work
>   a000000100dc1e60 (b) __key.33744
>   a000000100dc1e68 (B) unix_socket_table
>   a000000100dc2670 (A) _end
>   e000000000000000 (A) v
>   ffffffffffff0000 (D) __per_cpu_start
>   ffffffffffff0000 (d) per_cpu__cpu_idle_state
>   ffffffffffff0008 (D) per_cpu__pfm_syst_info
>   ffffffffffff0010 (D) per_cpu__pmu_owner
>   ...
> 
> This has to do with older ia64 kernels which compiled the kernel text
> and data segments into region 7, based at e000000000000000.  Newer
> ia64 kernels map the kernel text and static data segments into
> ia64 region 5, based at a000000000000000, although all other
> physical memory is still unity-mapped at ia64 region 7.
> 
> Although it could probably be done with an ia64-specific hack,
> I'm somewhat hesitant to change this behavior.

I've overcome my hesitation, and will address this in the next release.

The problem is that the ia64 contains legitimate kernel symbols
beyond "_end", namely the "v" and the per_cpu pseudo-symbols.

As it turns out, as long is the change is restricted to the
"bt -r" and "rd -[sS]" commands, it's not a particularly
ugly hack.  And if in the future another architecture ends up
containing base kernel symbols beyond "_end", the patch can be
adapted for use in those cases as well.

Dave