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

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

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....
--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility

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>".

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

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.
--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility

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.
--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility

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
--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility

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

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