Hack to get filename completion for the mod command

The mod command won't do filename completion.
Sometimes I set up a big ugly directory path for mod -S by starting with
the dir command, using its filename completion to get the modules
directory, and then command-line editing the dir command into a mod -S
command before executing it.  Ahem.

This hacky patch allows crash to tell gdb that "mod" is a command that
should get filename completion.  It's pretty un-smart filename
completion, e.g. doesn't know that sometimes it should be selecting from
a list of modules instead of filenames, etc.  And it messes with the
separation of crash and gdb.  

But mod -S <tab><tab> seems to work.

It does change the behavior of "crash> gdb help mod" and "crash> gdb
mod".  

Bob Montgomery

The mod command won't do filename completion.
Sometimes I set up a big ugly directory path for mod -S by starting with
the dir command, using its filename completion to get the modules
directory, and then command-line editing the dir command into a mod -S
command before executing it.  Ahem.

This hacky patch allows crash to tell gdb that "mod" is a command that
should get filename completion.  It's pretty un-smart filename

Re: Hack to get filename completion for the mod command

----- "Bob Montgomery" <bob.montgomery <at> hp.com> wrote:

> The mod command won't do filename completion.
> Sometimes I set up a big ugly directory path for mod -S by starting with
> the dir command, using its filename completion to get the modules
> directory, and then command-line editing the dir command into a mod -S
> command before executing it.  Ahem.
> 
> This hacky patch allows crash to tell gdb that "mod" is a command that
> should get filename completion.  It's pretty un-smart filename
> completion, e.g. doesn't know that sometimes it should be selecting from
> a list of modules instead of filenames, etc.  And it messes with the
> separation of crash and gdb.  
> 
> But mod -S <tab><tab> seems to work.

By any chance, does the "non-standard module directory option" that went
into 4.0-8.10 work for you, i.e., letting the bash command line do the
command line completion work:

  # crash vmlinux [vmcore] --mod <directory>

Then "mod -S" works by searching from the specified <directory> on down.

  http://people.redhat.com/anderson/crash.changelog.html#4_0_8_10

> It does change the behavior of "crash> gdb help mod" and "crash> gdb
> mod".  

Re: Hack to get filename completion for the mod command

On Mon, 2009-11-02 at 22:31 +0000, Dave Anderson wrote:
> ----- "Bob Montgomery" <bob.montgomery <at> hp.com> wrote:

> > This hacky patch allows crash to tell gdb that "mod" is a command that
> > should get filename completion. 

> 
> By any chance, does the "non-standard module directory option" that went
> into 4.0-8.10 work for you, i.e., letting the bash command line do the
> command line completion work:
> 
>   # crash vmlinux [vmcore] --mod <directory>
> 
> Then "mod -S" works by searching from the specified <directory> on down.

>   http://people.redhat.com/anderson/crash.changelog.html#4_0_8_10

I'll take a look at this.  I was mostly curious why some crash commands
had filename completion and some (like mod) did not.
>  
> > It does change the behavior of "crash> gdb help mod" and "crash> gdb
> > mod".

> Huh?

I was trying to point out that by adding "mod" to gdb's list of
commands, so that I could tell gdb to use filename completion when
working on the command line of a "mod" command, I also made it appear to
gdb that "mod" was one of its commands (with a dummy do-nothing
execution function).  Normally crash grabs mod, so gdb never gets a

Re: Hack to get filename completion for the mod command

----- "Bob Montgomery" <bob.montgomery <at> hp.com> wrote:

> On Mon, 2009-11-02 at 22:31 +0000, Dave Anderson wrote:
> > ----- "Bob Montgomery" <bob.montgomery <at> hp.com> wrote:
> 
> > > This hacky patch allows crash to tell gdb that "mod" is a command that
> > > should get filename completion. 
> 
> > 
> > By any chance, does the "non-standard module directory option" that went
> > into 4.0-8.10 work for you, i.e., letting the bash command line do the
> > command line completion work:
> > 
> >   # crash vmlinux [vmcore] --mod <directory>
> > 
> > Then "mod -S" works by searching from the specified <directory> on down.
> 
> >   http://people.redhat.com/anderson/crash.changelog.html#4_0_8_10
> 
> I'll take a look at this.  I was mostly curious why some crash commands
> had filename completion and some (like mod) did not.

I'm sure I don't know why some crasg commands would and some wouldn't? 
I've never tried it, but it must have something to do with the setting
up of the readline interface, right?  

> >  
> > > It does change the behavior of "crash> gdb help mod" and "crash> gdb mod".
> 

Re: Hack to get filename completion for the mod command

On Tue, 2009-11-03 at 19:00 +0000, Dave Anderson wrote:
> ----- "Bob Montgomery" <bob.montgomery <at> hp.com> wrote:

> I'm sure I don't know why some crasg commands would and some wouldn't? 
> I've never tried it, but it must have something to do with the setting
> up of the readline interface, right? 

No crash commands do right now, only gdb commands.

> What would worry me about that is the error/exception handling, because
> it would take it out of the crash code and put it in the gdb code.
> Especially in the case of the "mod" command.  It's all set up in the
> upper-level crash sources, so by somehow having gdb take over the "mod"
> command, and then have gdb call back to the upper-level crash function,
> and then having some part of that piece fail, the error handling and
> exception thow-backs get a bit murky.  I suppose it could be done, but
> I would prefer that crash commands stay as crash commands and gdb commands
> stay as gdb commands, and I would hate to intermingle them.  If you follow
> the filename completion code in gdb (I haven't looked at it), I wonder if it
> just tinkers with readline settings?

There is no issue with error handling because gdb is not executing
crash's mod function.  gdb is only doing the readline like it always
has, and sending back the completed command line to crash.  Then crash
executes the command line with exec_command like it always has.  The
only thing I've changed is to modify gdb's readline settings to include
allowing filename completion for any command line that starts with "mod"
(or "less", or "ls"...).  The reason I pointed out what happens when you
do "gdb mod", was to show that I was *not* having gdb do a callback to
crash to execute mod, since what gdb executes when it thinks it's doing

Re: Hack to get filename completion for the mod command

----- "Bob Montgomery" <bob.montgomery <at> hp.com> wrote:

> On Tue, 2009-11-03 at 19:00 +0000, Dave Anderson wrote:
> > ----- "Bob Montgomery" <bob.montgomery <at> hp.com> wrote:
>
> > I'm sure I don't know why some crasg commands would and some wouldn't?
> > I've never tried it, but it must have something to do with the setting
> > up of the readline interface, right?
>
> No crash commands do right now, only gdb commands.

(at least one of them does -- see below...)

> > What would worry me about that is the error/exception handling, because
> > it would take it out of the crash code and put it in the gdb code.
> > Especially in the case of the "mod" command.  It's all set up in the
> > upper-level crash sources, so by somehow having gdb take over the "mod"
> > command, and then have gdb call back to the upper-level crash function,
> > and then having some part of that piece fail, the error handling and
> > exception thow-backs get a bit murky.  I suppose it could be done, but
> > I would prefer that crash commands stay as crash commands and gdb commands
> > stay as gdb commands, and I would hate to intermingle them.  If you follow
> > the filename completion code in gdb (I haven't looked at it), I wonder if it
> > just tinkers with readline settings?
>
> There is no issue with error handling because gdb is not executing
> crash's mod function.  gdb is only doing the readline like it always
> has, and sending back the completed command line to crash.  Then crash
> executes the command line with exec_command like it always has.  The

invalid kernel virtual address: cc08 type: "cpu number (per_cpu)"

I have a dump from a 2.6.31-based x86_64 system where the number of
"possible" cpus equals the system's NR_CPUS (32).  

On that system, the __per_cpu_offset table in the kernel consists of 32
valid offset pointers.

When crash loads this table into its __per_cpu_offset[NR_CPUS=4096]
array in struct kernel_table, it knows the length of the kernel's array
(32*sizeof(long)), and copies the 32 pointers, leaving the rest of its
(much longer) array full of 0x0s.

(This happens in kernel.c)

 193      if (symbol_exists("__per_cpu_offset")) {
 194              if (LKCD_KERNTYPES())
 195                      i = get_cpus_possible();
 196              else
 197                      i = get_array_length("__per_cpu_offset", NULL, 0);
 198              get_symbol_data("__per_cpu_offset",
 199                      sizeof(long)*((i && (i <= NR_CPUS)) ? i : NR_CPUS),
 200                      &kt->__per_cpu_offset[0]);
 201              kt->flags |= PER_CPU_OFF;
 202      }

Later, in a couple of places, crash checks for the maximum valid
__per_cpu_offset by reading the cpu_number value out of each per_cpu
area and comparing it to the expected number until the comparison fails.
(Remember NR_CPUS in crash is much larger then the kernel's NR_CPUS, and
that's OK).

Re: invalid kernel virtual address: cc08 type: "cpu number (per_cpu)"

----- "Bob Montgomery" <bob.montgomery <at> hp.com> wrote:

> I have a dump from a 2.6.31-based x86_64 system where the number of
> "possible" cpus equals the system's NR_CPUS (32).  
> On that system, the __per_cpu_offset table in the kernel consists of 32
> valid offset pointers.
> 
> When crash loads this table into its __per_cpu_offset[NR_CPUS=4096]
> array in struct kernel_table, it knows the length of the kernel's array
> (32*sizeof(long)), and copies the 32 pointers, leaving the rest of its
> (much longer) array full of 0x0s.
> 
> (This happens in kernel.c)
> 
>  193      if (symbol_exists("__per_cpu_offset")) {
>  194              if (LKCD_KERNTYPES())
>  195                      i = get_cpus_possible();
>  196              else
>  197                      i = get_array_length("__per_cpu_offset", NULL, 0);
>  198              get_symbol_data("__per_cpu_offset",
>  199                      sizeof(long)*((i && (i <= NR_CPUS)) ? i : NR_CPUS),
>  200                      &kt->__per_cpu_offset[0]);
>  201              kt->flags |= PER_CPU_OFF;
>  202      }
> 
> Later, in a couple of places, crash checks for the maximum valid
> __per_cpu_offset by reading the cpu_number value out of each per_cpu
> area and comparing it to the expected number until the comparison fails.
> (Remember NR_CPUS in crash is much larger then the kernel's NR_CPUS, and

Re: invalid kernel virtual address: cc08 type: "cpu number (per_cpu)"

On Wed, 2009-11-11 at 14:52 +0000, Dave Anderson wrote:
> ----- "Bob Montgomery" <bob.montgomery <at> hp.com> wrote:
> 
> > I have a dump from a 2.6.31-based x86_64 system where the number of
> > "possible" cpus equals the system's NR_CPUS (32).  
> > On that system, the __per_cpu_offset table in the kernel consists of 32
> > valid offset pointers.

> I have a similar-but-different fix queued for this, but instead of
> checking for a NULL kt->__per_cpu_offset[i] entry, it changes the
> readmem() call to RETURN_ON_ERROR|QUIET instead of FAULT_ON_ERROR
> like this:
> 
>                 if (!readmem(symbol_value("per_cpu__cpu_number") +
>                     kt->__per_cpu_offset[i],
>                     KVADDR, &cpunumber, sizeof(int),
>                     "cpu number (per_cpu)", QUIET|RETURN_ON_ERROR))
>                         break;

> That should prevent the failure you're seeing.

I did that first, and thought it was sort of cheating 

> But another question is in the (extremely) rare circumstance of a
> non-CONFIG_SMP kernel.  In that case, the kt->__per_cpu_offset[] array
> would be all NULL, and the symbol_value("per_cpu__cpu_number")
> call would return the qualified unity-mapped address.  So the
> virtual address calculation should work in x86_64_per_cpu_init(),
> and the loop wouldn't even be entered in x86_64_get_smp_cpus()
> 

Re: invalid kernel virtual address: cc08 type: "cpu number (per_cpu)"

----- "Bob Montgomery" <bob.montgomery <at> hp.com> wrote:

> On Wed, 2009-11-11 at 14:52 +0000, Dave Anderson wrote:
> > ----- "Bob Montgomery" <bob.montgomery <at> hp.com> wrote:
> > 
> > > I have a dump from a 2.6.31-based x86_64 system where the number of
> > > "possible" cpus equals the system's NR_CPUS (32).  
> > > On that system, the __per_cpu_offset table in the kernel consists of 32
> > > valid offset pointers.
> 
> > I have a similar-but-different fix queued for this, but instead of
> > checking for a NULL kt->__per_cpu_offset[i] entry, it changes the
> > readmem() call to RETURN_ON_ERROR|QUIET instead of FAULT_ON_ERROR
> > like this:
> > 
> >                 if (!readmem(symbol_value("per_cpu__cpu_number") +
> >                     kt->__per_cpu_offset[i],
> >                     KVADDR, &cpunumber, sizeof(int),
> >                     "cpu number (per_cpu)", QUIET|RETURN_ON_ERROR))
> >                         break;
> 
> > That should prevent the failure you're seeing.
> 
> I did that first, and thought it was sort of cheating 

Sort of.  But at that point in time we're still kind of blindly
wading around in the murk trying to figure out what we're 
running on...