----- Original Message -----
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(a)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 ;-)
Right, and again, when I modified store_load_module_symbols_v2() as indicated here:
https://www.redhat.com/archives/crash-utility/2013-March/msg00130.html
I *do* see some of the (d) symbols in the "sym" display. There's something
odd about the ARM module.ko files such that lm->mod_sections is not quite
the right count. There must be something w/respect to section name strings
or something that is not seen with the other architectures.
Dave