3:48 p.m.
On Thu, 10 Nov 2005, Dave Anderson wrote:
> I also did not feel comfortable accepting the extension-keyword
> stuff. While I do recognize that it would be useful to be
> able to dynamically determine what extension modules to load,
> I don't feel the extend command should be encumbered with the
> job, but rather such an implementation-specific chore should
> be handled by an instance of extension library code.
>
> For that reason I exported both the load_extension() and
> unload_extension() functions so that extension library code
> could use them to in turn load other extension libraries.
>
> The call to load_extension() could be made from either the
> _init() function or from an extension command. At those
> points in time, the "first" extension library will have all
> the information (kernel version, crash version, dumpfile,
> etc.) at its disposal, and then can make the decision as to
> what additional libraries to load.
Implementing this, I realized that the for this scheme to work,
if I want to access things like the crash version, the 'pc'
structure will have to remain the same. Perhaps a small
set of these functions can be exported to reduce the dependencies
of such a loader on defs.h?
The minimal expectation would be something which would export
pc->program_version
If pc->curcmd were exported, that would also remove dependencies
on calling cmd_usage.
-castor
4:46 p.m.
New subject: Miscellaneous fixes/enhancements to crash 4.0-2.10(fwd)
Castor Fu wrote:
On Thu, 10 Nov 2005, Dave Anderson wrote:
>> I also did not feel comfortable accepting the extension-keyword
>> stuff. While I do recognize that it would be useful to be
>> able to dynamically determine what extension modules to load,
>> I don't feel the extend command should be encumbered with the
>> job, but rather such an implementation-specific chore should
>> be handled by an instance of extension library code.
>>
>> For that reason I exported both the load_extension() and
>> unload_extension() functions so that extension library code
>> could use them to in turn load other extension libraries.
>>
>> The call to load_extension() could be made from either the
>> _init() function or from an extension command. At those
>> points in time, the "first" extension library will have all
>> the information (kernel version, crash version, dumpfile,
>> etc.) at its disposal, and then can make the decision as to
>> what additional libraries to load.
Implementing this, I realized that the for this scheme to work,
if I want to access things like the crash version, the 'pc'
structure will have to remain the same. Perhaps a small
set of these functions can be exported to reduce the dependencies
of such a loader on defs.h?
The minimal expectation would be something which would export
pc->program_version
If pc->curcmd were exported, that would also remove dependencies
on calling cmd_usage.
I do try my best to not muck with the basic data structures, and if changed,
to add the new struff onto the end of the data structure, so even if a module
were built with an older version, its dependencies would still be in place.
And with respect to the program_context structure specifically, I cannot
even remember the last time that it changed. We can always put a
moratorium on the data structure to enforce the "only-add-to-the-end"
rule. Or if you feel it's necessary, come up with a mechanism for
exporting stuff generically for extensions, come up with something
that we can put in extensions.c.
Dave
6:24 p.m.
New subject: Miscellaneous fixes/enhancements to crash 4.0-2.10(fwd)
On Wed, 16 Nov 2005, Dave Anderson wrote:
Castor Fu wrote:
> The minimal expectation would be something which would export
>
> pc->program_version
>
> If pc->curcmd were exported, that would also remove dependencies
> on calling cmd_usage.
>
I do try my best to not muck with the basic data structures, and if changed,
to add the new struff onto the end of the data structure, so even if a module
were built with an older version, its dependencies would still be in place.
And with respect to the program_context structure specifically, I cannot
even remember the last time that it changed. We can always put a
moratorium on the data structure to enforce the "only-add-to-the-end"
rule. Or if you feel it's necessary, come up with a mechanism for
exporting stuff generically for extensions, come up with something
that we can put in extensions.c.
If it doesn't change much, that's fine.
Regarding the 'bt -O' change... If I run 'crash' in root's $HOME
a '.crashrc' will get executed twice. I cannot put 'bt -O' in
a .crashrc file and get predictable behavior. It'd be good to
have a mechanism which is idempotent.
I've attached patches which change 'bt -O' to accept an optional 0/1 argument
to fix the value.
Thanks!
-castor
8:48 a.m.
New subject: Miscellaneous fixes/enhancements to crash 4.0-2.10(fwd)
Castor Fu wrote:
On Wed, 16 Nov 2005, Dave Anderson wrote:
> Castor Fu wrote:
>
>> The minimal expectation would be something which would export
>>
>> pc->program_version
>>
>> If pc->curcmd were exported, that would also remove dependencies
>> on calling cmd_usage.
>>
>
> I do try my best to not muck with the basic data structures, and if changed,
> to add the new struff onto the end of the data structure, so even if a module
> were built with an older version, its dependencies would still be in place.
> And with respect to the program_context structure specifically, I cannot
> even remember the last time that it changed. We can always put a
> moratorium on the data structure to enforce the "only-add-to-the-end"
> rule. Or if you feel it's necessary, come up with a mechanism for
> exporting stuff generically for extensions, come up with something
> that we can put in extensions.c.
If it doesn't change much, that's fine.
Regarding the 'bt -O' change... If I run 'crash' in root's $HOME
a '.crashrc' will get executed twice. I cannot put 'bt -O' in
a .crashrc file and get predictable behavior. It'd be good to
have a mechanism which is idempotent.
I've attached patches which change 'bt -O' to accept an optional 0/1
argument
to fix the value.
Well, first off, it's kind of stupid to run the same .crashrc file twice,
isn't it? I shall fix that oversight henceforth...
That leaves the case where "bt -O" is set in both the $HOME and
local .crashrc files. Whereas the local .crashrc is meant to override
whatever might be in the $HOME .crashrc, the "bt -O" case still wants
to be idempotent. That can be addressed by a little tinkering with cmd_bt(),
because the pc->flags will have RCHOME_IFILE or RCLOCAL_IFILE
set when it's executing those .crashrc commands.
With those two fixes in hand, we can keep "bt -O" simple-minded.
Dave
9:59 a.m.
New subject: Miscellaneous fixes/enhancements to crash 4.0-2.10(fwd)
Dave Anderson wrote:
Well, first off, it's kind of stupid to run the same .crashrc file twice,
isn't it? I shall fix that oversight henceforth...
That leaves the case where "bt -O" is set in both the $HOME and
local .crashrc files. Whereas the local .crashrc is meant to override
whatever might be in the $HOME .crashrc, the "bt -O" case still wants
to be idempotent. That can be addressed by a little tinkering with cmd_bt(),
because the pc->flags will have RCHOME_IFILE or RCLOCAL_IFILE
set when it's executing those .crashrc commands.
With those two fixes in hand, we can keep "bt -O" simple-minded.
There's also the potential case of the command line "-i inputfile" option.
But the initialization-time rule should still apply -- if "bt -O" is contained
in
any or all of the 3 possible initialization-time input files ($HOME/.crashrc,
./.crashrc, or "-i inputfile" files), the setting will remain idempotent.
I also fixed the redundant running of $HOME/.crashrc and ./.crashrc
files if they are the same file.
Thanks,
Dave
Index: cmdline.c
===================================================================
RCS file: /nfs/projects/cvs/crash/cmdline.c,v
retrieving revision 1.15
diff -u -p -r1.15 cmdline.c
--- cmdline.c 13 Apr 2005 20:48:17 -0000 1.15
+++ cmdline.c 18 Nov 2005 15:49:59 -0000
@@ -71,14 +71,17 @@ get_command_line(void)
* 4. from a terminal.
* 5. from a pipe, if stdin is a pipe rather than a terminal.
*/
- if (pc->flags & RCHOME_IFILE)
+ if (pc->flags & RCHOME_IFILE) {
sprintf(pc->command_line, "< %s/.%src",
pc->home, pc->program_name);
- else if (pc->flags & RCLOCAL_IFILE)
+ pc->flags |= INIT_IFILE;
+ } else if (pc->flags & RCLOCAL_IFILE) {
sprintf(pc->command_line, "< .%src",
pc->program_name);
- else if (pc->flags & CMDLINE_IFILE)
+ pc->flags |= INIT_IFILE;
+ } else if (pc->flags & CMDLINE_IFILE) {
sprintf(pc->command_line, "< %s", pc->input_file);
- else if (pc->flags & TTY) {
+ pc->flags |= INIT_IFILE;
+ } else if (pc->flags & TTY) {
if (!(pc->readline = readline(pc->prompt))) {
args[0] = NULL;
fprintf(fp, "\n");
@@ -918,7 +921,7 @@ restore_sanity(void)
wait_for_children(ZOMBIES_ONLY);
- pc->flags &= ~(RUNTIME_IFILE|_SIGINT_);
+ pc->flags &= ~(INIT_IFILE|RUNTIME_IFILE|_SIGINT_);
pc->sigint_cnt = 0;
pc->redirect = 0;
pc->pipe_command[0] = NULLCHAR;
Index: defs.h
===================================================================
RCS file: /nfs/projects/cvs/crash/defs.h,v
retrieving revision 1.238
diff -u -p -r1.238 defs.h
--- defs.h 10 Nov 2005 20:25:45 -0000 1.238
+++ defs.h 18 Nov 2005 15:40:07 -0000
@@ -169,6 +169,7 @@ struct number_option {
#define VERSION_QUERY (0x4000000000000ULL)
#define READNOW (0x8000000000000ULL)
#define NOCRASHRC (0x10000000000000ULL)
+#define INIT_IFILE (0x20000000000000ULL)
#define ACTIVE() (pc->flags & LIVE_SYSTEM)
#define DUMPFILE() (!(pc->flags & LIVE_SYSTEM))
Index: kernel.c
===================================================================
RCS file: /nfs/projects/cvs/crash/kernel.c,v
retrieving revision 1.129
diff -u -p -r1.129 kernel.c
--- kernel.c 10 Nov 2005 20:22:33 -0000 1.129
+++ kernel.c 18 Nov 2005 15:54:23 -0000
@@ -1156,9 +1156,19 @@ cmd_bt(void)
break;
case 'O':
- if (!(machine_type("X86"))) {
+ if (!machine_type("X86"))
option_not_supported(c);
- } else if (kt->flags & USE_OLD_BT) {
+ else if (kt->flags & USE_OLD_BT) {
+ /*
+ * Make this setting idempotent across the use of
+ * $HOME/.crashrc, ./.crashrc, and "-i input" files.
+ * If we've been here before during initialization,
+ * leave it alone.
+ */
+ if (pc->flags & INIT_IFILE) {
+ error(INFO, "use old bt method by default (already set)\n");
+ return;
+ }
kt->flags &= ~USE_OLD_BT;
error(INFO, "use new bt method by default\n");
} else {
Index: main.c
===================================================================
RCS file: /nfs/projects/cvs/crash/main.c,v
retrieving revision 1.50
diff -u -p -r1.50 main.c
--- main.c 15 Sep 2005 19:39:58 -0000 1.50
+++ main.c 18 Nov 2005 15:41:07 -0000
@@ -606,6 +606,8 @@ setup_environment(int argc, char **argv)
int i;
char *p1;
char buf[BUFSIZE];
+ char homerc[BUFSIZE];
+ char localrc[BUFSIZE];
FILE *afp;
char *program;
@@ -700,11 +702,11 @@ setup_environment(int argc, char **argv)
pc->home = "(unknown)";
} else
strcpy(pc->home, p1);
- sprintf(buf, "%s/.%src", pc->home, pc->program_name);
- if (!(pc->flags & NOCRASHRC) && file_exists(buf, NULL)) {
- if ((afp = fopen(buf, "r")) == NULL)
+ sprintf(homerc, "%s/.%src", pc->home, pc->program_name);
+ if (!(pc->flags & NOCRASHRC) && file_exists(homerc, NULL)) {
+ if ((afp = fopen(homerc, "r")) == NULL)
error(INFO, "cannot open %s: %s\n",
- buf, strerror(errno));
+ homerc, strerror(errno));
else {
while (fgets(buf, BUFSIZE, afp))
resolve_rc_cmd(buf, ALIAS_RCHOME);
@@ -713,11 +715,12 @@ setup_environment(int argc, char **argv)
}
}
- sprintf(buf, ".%src", pc->program_name);
- if (!(pc->flags & NOCRASHRC) && file_exists(buf, NULL)) {
- if ((afp = fopen(buf, "r")) == NULL)
+ sprintf(localrc, ".%src", pc->program_name);
+ if (!same_file(homerc, localrc) &&
+ !(pc->flags & NOCRASHRC) && file_exists(localrc, NULL)) {
+ if ((afp = fopen(localrc, "r")) == NULL)
error(INFO, "cannot open %s: %s\n",
- buf, strerror(errno));
+ localrc, strerror(errno));
else {
while (fgets(buf, BUFSIZE, afp))
resolve_rc_cmd(buf, ALIAS_RCLOCAL);
@@ -891,6 +894,9 @@ dump_program_context(void)
if (pc->flags & NOCRASHRC)
sprintf(&buf[strlen(buf)],
"%sNOCRASHRC", others++ ? "|" :
"");
+ if (pc->flags & INIT_IFILE)
+ sprintf(&buf[strlen(buf)],
+ "%sINIT_IFILE", others++ ? "|" :
"");
if (pc->flags)
strcat(buf, ")");
12:10 p.m.
New subject: Miscellaneous fixes/enhancements to crash 4.0-2.10(fwd)
On Fri, 18 Nov 2005, Dave Anderson wrote:
Dave Anderson wrote:
>
> Well, first off, it's kind of stupid to run the same .crashrc file twice,
> isn't it? I shall fix that oversight henceforth...
Yes, I suppose so, but I was actually seeing this first with
a local .crashrc...
>
> That leaves the case where "bt -O" is set in both the $HOME and
> local .crashrc files. Whereas the local .crashrc is meant to override
> whatever might be in the $HOME .crashrc, the "bt -O" case still wants
> to be idempotent. That can be addressed by a little tinkering with cmd_bt(),
> because the pc->flags will have RCHOME_IFILE or RCLOCAL_IFILE
> set when it's executing those .crashrc commands.
>
> With those two fixes in hand, we can keep "bt -O" simple-minded.
There's also the potential case of the command line "-i inputfile" option.
But the initialization-time rule should still apply -- if "bt -O" is contained
in
any or all of the 3 possible initialization-time input files ($HOME/.crashrc,
./.crashrc, or "-i inputfile" files), the setting will remain idempotent.
I also fixed the redundant running of $HOME/.crashrc and ./.crashrc
files if they are the same file.
Just so I understand, what you're saying is that if 'bt -O' is specified
in an initialization file, it always means 'use old' otherwise it's a toggle?
-castor
12:46 p.m.
New subject: Miscellaneous fixes/enhancements to crash 4.0-2.10(fwd)
Castor Fu wrote:
On Fri, 18 Nov 2005, Dave Anderson wrote:
> Dave Anderson wrote:
>
>>
>> Well, first off, it's kind of stupid to run the same .crashrc file twice,
>> isn't it? I shall fix that oversight henceforth...
Yes, I suppose so, but I was actually seeing this first with
a local .crashrc...
Right -- you were seeing it when the local .crashrc *was* also $HOME/.crashrc.
So it was executed twice, first as the $HOME version, and subsequently as
the local version.
>>
>> That leaves the case where "bt -O" is set in both the $HOME and
>> local .crashrc files. Whereas the local .crashrc is meant to override
>> whatever might be in the $HOME .crashrc, the "bt -O" case still wants
>> to be idempotent. That can be addressed by a little tinkering with cmd_bt(),
>> because the pc->flags will have RCHOME_IFILE or RCLOCAL_IFILE
>> set when it's executing those .crashrc commands.
>>
>> With those two fixes in hand, we can keep "bt -O" simple-minded.
>
> There's also the potential case of the command line "-i inputfile"
option.
> But the initialization-time rule should still apply -- if "bt -O" is
contained in
> any or all of the 3 possible initialization-time input files ($HOME/.crashrc,
> ./.crashrc, or "-i inputfile" files), the setting will remain idempotent.
>
> I also fixed the redundant running of $HOME/.crashrc and ./.crashrc
> files if they are the same file.
Just so I understand, what you're saying is that if 'bt -O' is specified
in an initialization file, it always means 'use old' otherwise it's a toggle?
Right -- it's only toggle-able during runtime.
Dave
6896
days inactive
6898
days old
devel@lists.crash-utility.osci.io
6 comments
2 participants
participants (2)
-
Castor Fu -
Dave Anderson