Re: Why module's global symbol cannot be displayed in crash? [ARM]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




----- 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@xxxxxx> 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
 

--
Crash-utility mailing list
Crash-utility@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/crash-utility




[Index of Archives]     [Fedora Development]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]

 

Powered by Linux