[Crash-utility] crash-4.0-3.14-sym.3.patch (was: modules and data/bss initialization)

[Castor Fu]

Oops, I sent the wrong patch...  
 
I had found the second problem when reading 
through the patch, but somehow grabbed the wrong file.  The 'mod -l'
thing
seems like it'll take more to fix, but there's another problem which I
found and 
had fixed.
 
Sections which are not '.text' '.data' or '.bss' will get loaded at the
wrong
addresses, which is unfortunate.  The following patch addresses this
by providing addreses for each section.
 
Happy New Year!
 
 -castor

________________________________

From: crash-utility-bounces at redhat.com
[mailto:crash-utility-bounces at redhat.com] On Behalf Of Dave Anderson
Sent: Tuesday, January 02, 2007 1:04 PM
To: Discussion list for crash utility usage, maintenance and development
Subject: Re: [Crash-utility] crash-4.0-3.14-sym.3.patch (was: modules
and data/bss initialization)


Castor Fu wrote: 

	  
	Hi Dave!
	
	Sorry about the regression.
	
	I looked further through the code, and have modified it to only
add the symbols
	for which it has actually identified a matching section, and to
do it in a way
	which supports whatever sections are defined.
	This doesn't explain why a match isn't being found in the ia64
case, but shouldat least avoid the regression in the s390x case.I've
also attached a test which one could run which dumps output which
mighthelp me fix things by tracing through loading the 'md5' module. By
default the new code is off, as requested, and can be forced witha '-l'
option to 'mod', e.g.crash> mod -l -s md5Thanks again for the testing,
and hopefully this will work for most people.It would be great if
someone could send me output from the rarerplatforms like ppc64 or 390
if it doesn't work.Happy New Year!    -castor


Somebody forgot to QA this patch...    ;-) 

Unfortunately, "mod -l -s module-name" won't work, nor will 
"mod -l -S", because of the unique way that cmd_mod() handles 
-s and -S -- which can optionally take additional "objfile" or
"directory" 
arguments respectively: 

crash> mod -l -S 
mod: -S is not a directory 
Usage: mod [ -s module [objfile] | -d module | -S [directory] | -D | -r
] 
Enter "help mod" for details. 
crash> mod -l -s nfs 
mod: /usr/lib/debug/lib/modules/2.4.21-37.ELsmp/kernel/fs/nfs: not an
ELF format object file 
Usage: mod [ -s module [objfile] | -d module | -S [directory] | -D | -r
] 
Enter "help mod" for details. 
crash> 

So to get around that, you can just enter "mod -l" alone 
prior to any -s or -S commands, which will just set the 
flag. 

But having done that, it actually does just the opposite, 
because of backwards logic here: 

@@ -7288,7 +7410,10 @@ 
                        strcpy(lm->mod_namelist, namelist); 
                else 
                        strncpy(lm->mod_namelist, namelist,
MAX_MOD_NAMELIST-1); 
-               goto add_symbols; 
+                if (USE_V2_MOD_SYM()) { 
+                        goto add_symbols; 
+                } 
+ 
        } 

        if ((mbfd = bfd_openr(namelist, NULL)) == NULL) 

It should be: "if (!USE_V2_MOD_SYM())". 

Anyway, don't bother updating the patch for the above, 
because I can keep testing with the two work-arounds. 

I'd also appreciate any ppc64, s390 and s390x testers 
out there... 

Thanks, 
  Dave 
  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/crash-utility/attachments/20070102/e7fe1fbc/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: crash-4.0-3.16.patch
Type: application/octet-stream
Size: 20343 bytes
Desc: crash-4.0-3.16.patch
URL: <http://listman.redhat.com/archives/crash-utility/attachments/20070102/e7fe1fbc/attachment.obj>