[Crash-utility] Why module's global symbol cannot be displayed in crash? [ARM]

[Mika Westerberg]

On Sun, Mar 24, 2013 at 04:58:33PM +0800, Lei Wen wrote:
> Mika,
> 
> On Fri, Mar 22, 2013 at 9:03 PM, Mika Westerberg <mika.westerberg at iki.fi> wrote:
> > On Thu, Mar 21, 2013 at 03:02:54PM -0400, Dave Anderson wrote:
> >> If for some reason you can't get them, I can make them available to you.
> >> And Lei Wen can also give you a sample dumpfile from his environment.
> >
> > Got them from Luc.
> >
> >> > Are you able to access module symbols on ARM dump (the one that Luc provided)?
> >> > Or is it failing completely?
> >>
> >> I *think* so...
> >>
> >> This module text disassembly looks right:
> >>
> >> crash> dis usbnet_suspend
> >> 0xbf000ae8 <usbnet_suspend>:    push    {r3, r4, r5, lr}
> >> 0xbf000aec <usbnet_suspend+4>:  add     r0, r0, #32
> >> 0xbf000af0 <usbnet_suspend+8>:  mov     r5, r1
> >> 0xbf000af4 <usbnet_suspend+12>: bl      0xc01b8264 <dev_get_drvdata>
> >> 0xbf000af8 <usbnet_suspend+16>: ldrb    r3, [r0, #36]   ; 0x24
> >> 0xbf000afc <usbnet_suspend+20>: mov     r4, r0
> >> 0xbf000b00 <usbnet_suspend+24>: add     r2, r3, #1
> >> 0xbf000b04 <usbnet_suspend+28>: cmp     r3, #0
> >> 0xbf000b08 <usbnet_suspend+32>: strb    r2, [r0, #36]   ; 0x24
> >> 0xbf000b0c <usbnet_suspend+36>: bne     0xbf000bdc <usbnet_suspend+244>
> >> 0xbf000b10 <usbnet_suspend+40>: mrs     r3, CPSR
> >> 0xbf000b14 <usbnet_suspend+44>: orr     r3, r3, #128    ; 0x80
> >> 0xbf000b18 <usbnet_suspend+48>: msr     CPSR_c, r3
> >> 0xbf000b1c <usbnet_suspend+52>: mov     r0, #1
> >> 0xbf000b20 <usbnet_suspend+56>: bl      0xc0015f40 <add_preempt_count>
> >> 0xbf000b24 <usbnet_suspend+60>: ldr     r3, [r4, #200]  ; 0xc8
> >> 0xbf000b28 <usbnet_suspend+64>: cmp     r3, #0
> >> 0xbf000b2c <usbnet_suspend+68>: beq     0xbf000b70 <usbnet_suspend+136>
> >> 0xbf000b30 <usbnet_suspend+72>: tst     r5, #1024       ; 0x400
> >> 0xbf000b34 <usbnet_suspend+76>: beq     0xbf000b70 <usbnet_suspend+136>
> >> 0xbf000b38 <usbnet_suspend+80>: mrs     r3, CPSR
> >> ...
> >>
> >> This (r) data looks OK:
> >>
> >> crash> p smsc95xx_netdev_ops
> >> smsc95xx_netdev_ops = $8 = {
> >>   ndo_init = 0,
> >>   ndo_uninit = 0,
> >>   ndo_open = 0xbf000514 <usbnet_open>,
> >>   ndo_stop = 0xbf000bec <usbnet_stop>,
> >>   ndo_start_xmit = 0xbf001a60 <usbnet_start_xmit>,
> >>   ndo_select_queue = 0,
> >>   ndo_change_rx_flags = 0,
> >>   ndo_set_rx_mode = 0,
> >>   ndo_set_multicast_list = 0xbf008abc <smsc95xx_set_multicast>,
> >>   ndo_set_mac_address = 0xc025d854 <eth_mac_addr>,
> >>   ndo_validate_addr = 0xc025d6f8 <eth_validate_addr>,
> >>   ndo_do_ioctl = 0xbf00926c <smsc95xx_ioctl>,
> >>   ndo_set_config = 0,
> >>   ndo_change_mtu = 0xbf000de0 <usbnet_change_mtu>,
> >>   ndo_neigh_setup = 0,
> >>   ndo_tx_timeout = 0xbf000d4c <usbnet_tx_timeout>,
> >>   ndo_get_stats64 = 0,
> >>   ndo_get_stats = 0,
> >>   ndo_vlan_rx_add_vid = 0,
> >>   ndo_vlan_rx_kill_vid = 0,
> >>   ndo_set_vf_mac = 0,
> >>   ndo_set_vf_vlan = 0,
> >>   ndo_set_vf_tx_rate = 0,
> >>   ndo_get_vf_config = 0,
> >>   ndo_set_vf_port = 0,
> >>   ndo_get_vf_port = 0,
> >>   ndo_setup_tc = 0,
> >>   ndo_add_slave = 0,
> >>   ndo_del_slave = 0,
> >>   ndo_fix_features = 0,
> >> crash>
> >
> > I'm able to see the same.
> >
> > Setting suitable debug level reveals:
> >
> >         bf00f040 (bf00f000): scsi_wait_scan syms: 0 gplsyms: 0 ksyms: 1
> >         bf00a1f8 (bf008000): smsc95xx syms: 0 gplsyms: 0 ksyms: 60
> >         bf002a40 (bf000000): usbnet syms: 0 gplsyms: 24 ksyms: 65
> >
> > The ksyms comes from KALLSYMS and by default it only includes text and
> > inittext symbols. This explains why Lei is not able to see data etc. symbols
> > when he runs 'sym -m <module>'.
> 
> Yep, that is my case. For data symbol would only be included in core section
> if CONFIG_KALLSYMS_ALL option is defined, so crash fail to extract
> the data symbol since it fail to see the data section is included in
> the dump image.
> 
> But what I am confused is that since mod -S would reload all module image,
> which already include all symbols. So why we should confine us to only
> extract those symbol in the core section defined by the dump image?

Well, crash (or the embedded GDB) is able to extract data symbols as well even
though you can't see them by running 'sym' command.

> I mean even with CONFIG_KALLSYMS be defined, I think it maybe doable to
> extract all data symbol. What are your guys' opinion here? :)

We can always review a patch that adds such support ;-)