hi everyone,
i had one of those "scratch the item" moments and decided to
investigate.
[PROBLEM]
i had created a "~/.gdbinit" file that contained simply:
===== $HOME/.gdbinit
display/i $pc
=====
but no matter what i tried i couldn't get it to work. this command
instructs 'gdb' to print out the next asm instruction whenever there
is a 'break'. as it stands now, whenever i would debug some code
'gdb' wouldn't print out the next instruction when the execution
would 'break'.
[OTHER OBSERVATIONS]
copying that file to the current directory did make it work, but this
isn't really acceptable.
using the '--x ~/.gdbinit' command line argument works. (and no, i
wouldn've been satisfied to create a simple shell script or alias
that would do this for me "behind the scenes", like i said, i had an
itch to scratch and decided to dig down for the root cause of the
problem).
[VERSION]
i am using the gdb rpm that comes with RedHat 7.1. at first i had
assumed that whoever created the RedHat rpm had perhaps turned off
this feature (for security reasons?) because i've encountered this
same sort of thing with RedHat and vim (why don't they have syntax
highlighting enabled in the vim rpm?)
[INVESTIGATION]
so i unpacked the gdb source and did a basic compile (./configure;
make) that didn't solve my problem.
so i went to the source and started looking around. actually my first
step was to browse through the various 'info' documents on gdb,
gdb-int, and so forth. after numerous greps i started inserting
'fprintf()' statements to get a feel for the flow of the code. i
think i've found the problem.
[CAUSE OF PROBLEM]
in 'main.c' there are a number of 'catch_command_errors()' calls
where commands are executed. the order that these are called in is
what's giving the problem. the very first one that's called is to
process the commands in the '~/.gdbinit' file. only sometime after
this are the command-line arguments processed -- one of which is the
name of the executable to debug.
as we know, gdb is very smart and therefore won't execute commands
that it actually can't execute. as it so happens, the one and only
command in my '~/.gdbinit' file requires a program to be loaded in
order to execute.
[SOLUTION]
therefore a simple solution is to move the processing of the commands
in the '~/.gdbinit' file to a point after the other command-line
arguments have been processed.
this explains why things work okay when i use a '.gdbinit' file in
the current directory and why the '--x' comamnd-line argument works;
they are both processed after the command-line argument...
actually, i just realised something funny, something i hadn't noticed
before. whenever i would use the '--x' cmd-line arg to test i
coincidently placed it after the name of the executable to debug, and
things worked fine. when i moved the location of the '--x' cmd-line
arg to before the name of the executable, things stopped working.
[ISSUES]
of course, the order of these calls to 'catch_command_errors()' might
not be arbitrary.
giving a program to debug is an optional command-line argument to
'gdb' so perhaps whoever originally wrote this code placed the
'~/.gdbinit' processing before the cmd-line args processing on
purpose.
humerously enough, had i not used this particular command (i.e. had i
simply put commands in my '~/.gdbinit' file for setting line length
and stuff like that) i wouldn't have noticed that it didn't appear to
be working.
[CONCLUSION]
so to make a long story even longer, in $(gdb-5.0)/gdb/main.c,
somewhere around line 563 you'll find something like this:
===== $(gdb-5.0)/gdb/main.c
if( !inhibit_gdbinit ) {
catch_command_errors( source_command, homeinit, 0,
RETURN_MASK_ALL );
}
=====
if i move this down to somewhere around line 649 things will work for
me.
i can provide a 'diff' if someone would tell me how to do it (what is
prefered).
best regards,
trevor
ps. i'm sorry for mangling my reply addresses but because this list
is echoed on USENET... remove the CAPS to email me directly
--
http://home.ica.net/~vjbtlw/
_______________________________________________
Bug-gdb mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-gdb
