5:03 p.m.
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
8:37 a.m.
----- 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
11:01 a.m.
On 03/14/12 06:37, Dave Anderson wrote:
> 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].
I did the patch as a "flags2" flag bit.
"gdb_cmd()" already leaves the first bytes of the command alone,
but I found it difficult to leave it alone. I eliminated the
extra copy....
11:35 a.m.
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>".
12:37 p.m.
----- 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
1:11 p.m.
On Wed, Mar 14, 2012 at 10:37 AM, Dave Anderson <anderson(a)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....
12:30 p.m.
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.
12:42 p.m.
----- 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
3:04 p.m.
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.
4:08 p.m.
----- 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
4:10 p.m.
----- 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
5:31 p.m.
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
1:54 p.m.
----- 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
2:46 p.m.
On 03/20/12 11:54, Dave Anderson wrote:
OK, I took your latest patch and re-worked it a bit
Excellent. Thank you.
I documented this new mode in both the "set" and
"gdb" help
pages.
Thanks for being thorough. Personally, I don't think a feature
exists before it gets documented. Thanks for finishing it.
It is queued for crash-6.0.5. Hopefully it will meet your needs...
Wonderfully. Thank you. Regards, Bruce
4634
days inactive
4641
days old
devel@lists.crash-utility.osci.io
13 comments
2 participants
participants (2)
-
Bruce Korb -
Dave Anderson