Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   Crash Utility (http://www.linux-archive.org/crash-utility/)
-   -   "gdb" by itself ought to put crash into a "gdb" mode (http://www.linux-archive.org/crash-utility/644521-gdb-itself-ought-put-crash-into-gdb-mode.html)

Dave Anderson 03-14-2012 12:37 PM

"gdb" by itself ought to put crash into a "gdb" mode
 
----- Original Message -----
> Hi,
>
> I might actually write the patch for this one. Piping back to crash,
> as useful as it would be, requires too much context shuffling. Here,
> all that'd be necessary is a "we are in pass through to gdb" mode
> meaning that the "gdb " prefix to gdb commands would not be necessary.
> Just monitor the input for a "crash" line and flip the bit. It's a
> nuisance to have to remember that prefix when typing a long series of
> gdb commands that mostly work as crash commands.
>
> Possible? Thanks ! Regards, Bruce

Definitely sounds possible. Maybe create a new "gdb" environment
variable that can be flipped with "set gdb on/off" commands. Then
check for the mode in process_command_line() and exec_input_file()
and insert/shift the "gdb" string into args[0].

Dave

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

Dave Anderson 03-14-2012 04:37 PM

"gdb" by itself ought to put crash into a "gdb" mode
 
----- Original Message -----
> On 03/14/12 06:37, Dave Anderson wrote:
>
> Well, I guess I ought to have tested it a little more.
> The reserved command checking is not correct now.
> Also, the prompt needs to change from "crash>" to "gdb>".
>

I would prefer a usage that's either a command and its
option, such as "gdb on" and "gdb off", or my original
suggestion of using the "set" command to set your flags2
mode bit. (and which would be documented in their
respective help page). And I'm not clear on what
you mean by "reserved command checking", but maybe
using "set gdb on" as a clear epoch would help?

Dave

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

Dave Anderson 03-14-2012 04:42 PM

"gdb" by itself ought to put crash into a "gdb" mode
 
----- Original Message -----
> On 03/14/12 06:37, Dave Anderson wrote:
>
> Sorry. I polished the patch, but it still fails here:
>
> $7 = (struct _IO_FILE *) 0x7ffff750f7e0
> (gdb) n
> 1001 pc->stdpipe = NULL;
> (gdb)
> 1002 if (pc->stdpipe_pid &&
> PID_ALIVE(pc->stdpipe_pid)) {
> (gdb)
> 1003 while (!waitpid(pc->stdpipe_pid,
> &waitstatus, WNOHANG))
> (gdb) p pc->stdpipe_pid
> $8 = 4180
> $ ps -f -p 4180
> UID PID PPID C STIME TTY TIME CMD
> bkorb 4180 4168 0 10:20 pts/1 00:00:00 /usr/bin/less -E -X
> -Ps -- MORE -
>
>
> So there's some magic going on that is expecting gdb to produce some output
> or do something that will make more or less stop. Unless you know, it'll be
> for another day.

No, I don't...

Dave


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

Bruce Korb 03-14-2012 05:11 PM

"gdb" by itself ought to put crash into a "gdb" mode
 
On Wed, Mar 14, 2012 at 10:37 AM, Dave Anderson <anderson@redhat.com> wrote:
> I would prefer a usage that's either a command and its
> option, such as "gdb on" and "gdb off", or my original
> suggestion of using the "set" command to set your flags2
> mode bit. *(and which would be documented in their
> respective help page). *And I'm not clear on what
> you mean by "reserved command checking", but maybe

I spelled "restricted" as "reserved" :)

/*
* If the command is not restricted, pass it on.
*/
if (!is_restricted_command(av[0], FAULT_ON_ERROR)) {
> using "set gdb on" as a clear epoch would help?

Probably would, so "another day" I'll give that a spin.
And I'll fiddle the command prompt....

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

Dave Anderson 03-14-2012 08:08 PM

"gdb" by itself ought to put crash into a "gdb" mode
 
----- Original Message -----
> On 03/14/12 06:37, Dave Anderson wrote:
>
> Well, ok, I kept stumble fingering the gdb commands, so here's a working patch.
> Under the covers, the "cmd_gdb" peeks into the command when it sees it is a
> "set" command. It already does this. But if it is a "set gdb" command, then
> it just redirects to the internal "cmd_set" function. I also jiggered the
> arguments to accommodate the fact that the first argument is no longer "gdb".
> And I fixed the prompt to be "gdb> " to distinguish from both "crash> " and
> "(gdb) ".

OK, sounds reasonable...

> I also really hate procedures that go beyond 100 lines or so,
> so I did not add to the cmd_set length.

Sorry, but with respect to the cmd_set() length, I'm afraid that's not going
to change. Since every other command does -- and has always done -- its own
getopt() handling, I'm not interested in forking it off to its own 100-line
function. I don't care about the length in that case, conformity trumps
function length.

Anyway, I'll try to take a look at the patch's functionality tomorrow.

Thanks,
Dave


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

Dave Anderson 03-16-2012 08:10 PM

"gdb" by itself ought to put crash into a "gdb" mode
 
----- Original Message -----
> On 03/14/12 06:37, Dave Anderson wrote:
>
> Well, ok, I kept stumble fingering the gdb commands, so here's a working patch.
> Under the covers, the "cmd_gdb" peeks into the command when it sees it is a
> "set" command. It already does this. But if it is a "set gdb" command, then
> it just redirects to the internal "cmd_set" function. I also jiggered the
> arguments to accommodate the fact that the first argument is no longer "gdb".
> And I fixed the prompt to be "gdb> " to distinguish from both "crash> " and
> "(gdb) ". I also really hate procedures that go beyond 100 lines or so,
> so I did not add to the cmd_set length.

Hi Bruce,

I just ran a quick test of your patch, and one thing I noted
immediately is when running "set variable" with no argument,
which should just show the current setting:

crash> help set
...
This command may also be used to set internal crash variables. If no value
argument is entered, the current value of the crash variable is shown. These
are the crash variables, acceptable arguments, and purpose:
...

But with your patch,

crash> set scroll
scroll: on (/usr/bin/less)
crash> set debug
debug: 0
crash> set silent
silent: off
crash> set gdb
Segmentation fault
$

I'm not exactly sure why it works OK for the other variables,
but not for "gdb". Anyway, I'll get back to it on Monday...

Thanks,
Dave


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

Dave Anderson 03-20-2012 05:54 PM

"gdb" by itself ought to put crash into a "gdb" mode
 
----- Original Message -----
> On 03/16/12 14:10, Dave Anderson wrote:
> > crash> set gdb
> > Segmentation fault
> > $
>
> I guess it's a good hint that you typed in something incorrectly.
> Anyway, the problem is that I discovered that STREQ() detects a NULL
> pointer and does something reasonable if it is NULL. That was
> not the case with IS_A_NUMBER(). It is now. :)
>
>
> crash> set gdb
> gdb> set gdb
> crash> set gdb
> gdb> set gdb
> crash> set gdb off
> crash> set gdb
> gdb> set gdb on
> gdb> set gdb off
> crash> quit
>

Hi Bruce,

OK, I took your latest patch and re-worked it a bit
in order to make the "gdb" environment variable behave
the same way as the other boolean variables. That being
the case, I just added an "if" statement to cmd_set() for
"gdb" that mimics the other booleans; the mode is turned
on/off by entering "set gdb on" and "set gdb off", while
"set gdb" shows the current setting. I also had to prevent
turning it on if crash was invoked with --minimal.

Also, I didn't make any of your changes to stol(), stoll(),
decimal() and hexadecimal(). There are several instances
where it is perfectly legitimate to pass a NULL pointer to
STREQ() and STREQ() -- which is one of the reasons that they
exist. But that's really not the case with the translation
functions. If they receive a NULL pointer, then there is
a bug in the calling function.

Your patch to get_command_table_entry() was a pretty nifty
way to bait-and-switch the command; I enhanced it a bit by
allowing you to run native crash commands while in "gdb" mode
by preceding them with the "crash" directive, for example,
entering "crash ps".

I documented this new mode in both the "set" and "gdb" help
pages.

And lastly I made a new, exported, set_command_prompt()
function that cmd_set() uses, but could also be used by, say,
an extension module to change the prompt when it is loaded
and unloaded.

It is queued for crash-6.0.5. Hopefully it will meet your needs...

Thanks,
Dave



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


All times are GMT. The time now is 08:46 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.