RE: modules and data / bss initialization

"Castor Fu" <castor.fu@xxxxxxxxxxxx> · Mon, 4 Dec 2006 11:16:05 -0800

I'm 
attaching a revised patch against 4.0-3.14...  This 
should
work a 
bit better as I no longer make assumptions about the 
ordering
of 
symbols, it's less whiny, and I even compiled with with -Werror 
so
those 
sign-extension problems should be gone.

Thanks 
for the feedback!

  -----Original Message-----
From: 
  crash-utility-bounces@xxxxxxxxxx 
  [mailto:crash-utility-bounces@xxxxxxxxxx]On Behalf Of Dave 
  Anderson
Sent: Friday, December 01, 2006 11:46 AM
To: 
  Discussion list for crash utility usage, maintenance and 
  development
Subject: Re:  modules and data / bss 
  initialization

Castor Fu wrote: 
   I don't think this made it out 
    earlier...Here's a fix.  I've also 
    added something so 'MODULES_IN_CWD' will work on 
    2.6since modules will end with 
    .koI hope this looks good to 
  others....

Hi Castor, 

Upon quick testing with RHEL4 and RHEL5 x86_64 kernels, 

this patch certainly looks promising... 

Although I don't particularly care to see these 
  messages: 

ffffffff8810ae80  
  serio_raw         41157  
  /lib/modules/2.6.18-1.2747.el5/kernel/drivers/input/serio/serio_raw.ko 

ffffffff8811b580  
  uhci_hcd          59353  
  /lib/modules/2.6.18-1.2747.el5/kernel/drivers/usb/host/uhci-hcd.ko 

ffffffff88130b00  
  shpchp            
  73069  
  /lib/modules/2.6.18-1.2747.el5/kernel/drivers/pci/hotplug/shpchp.ko 

unexpected sym __key.10825 8814a180 sec .bss offset e180 mod_base 
  8813c000 
XXX sym __key.10825 @ 8814a180 bfd val 0  
  section .bss 
unexpected sym __key.10826 8814a180 sec .bss 
  offset e180 mod_base 8813c000 
XXX sym __key.10826 @ 
  8814a180 bfd val 0  section .bss 
ffffffff88141f80  
  i2c_core          57793  
  /lib/modules/2.6.18-1.2747.el5/kernel/drivers/i2c/i2c-core.ko 

I would think they could be CRASHDEBUG(1)'d, couldn't they? 

Plus, those error messages will clip 64-bit values as shown 

above. 

I'm also presuming that the new add-symbol-file operation will 

harmlessly take a "0" mod_data_start, mod_rodata_start or 

mod_bss_start address argument; seemingly it does, since several 

of my test modules have 0 as one or more of those start 
  addresses. 

Anyway, I also would be interested in the experiences of others 

on the list who are using different architectures and kernel 

versions. 

Thanks, 
  Dave 

Attachment:
crash-4.0-3.14-sym.patch

Description: crash-4.0-3.14-sym.patch
--
Crash-utility mailing list
Crash-utility@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/crash-utility