This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

[Fwd: $(PWD)/.gdbinit]

Looks like a real bug.
	Andrew


hi again,

as i was tromping around in the gdb code i found something else that
was sort of funny that i thought i'd bring to your attention.

there is a bit of logic that will allow a '.gdbinit' file in the
current directory to be executed, but only if it is different than
the one found in the user's $HOME. however the test condition for the
'if()' statement isn't quite strong enough because it will try to
execute the '.gdbinit' file in the current directory even if such a
file doesn't exist!

the fact that there is no such file passes the test that the
(non-existant) one in the current directory is different than the one
in the user's $HOME directory.

around line 647 of $(gdb-5.0)/gdb/main.c you'll find the call to
'catch_command_errors()' which is what starts processing the
'$(PWD)/.gdbinit' file. if you change the third parameter from '0' to
'!batch' and watch the output of gdb you'll see that it tries to
processes '.gdbinit' but can't find any such file.

it's really not such a big deal. i can add more checks and provide a
'diff' if anyone's interested (i haven't done anything about this one
yet).

interested?

best regards,
	trevor

ps. sorry about the mangling thing again, see my previous email

-- 
http://home.ica.net/~vjbtlw/

_______________________________________________
Bug-gdb mailing list
Bug-gdb@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-gdb




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
Bug-gdb@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-gdb




hi again everyone,

i've been thinking more about the code i was looking at this past 
weekend. there's a bit of logic that goes something like the following:

"if there's a '.gdbinit' in the current directory read and process it, 
unless it's the same as the one in the user's $HOME directory"

i've talked about this in a past email. basically the if() condition 
isn't strong enough, if you change the third parameter to 
'catch_command_errors()' from "0" to "!batch" you'll see some error 
output.

as it currently stands, even if the file in the current directory 
doesn't exist that is considered sufficiently different from the one in 
the $HOME directory to allow this code to execute (which, of course, if 
the file doesn't exist, it shouldn't!)

i think a good C function to call here is "access". if you pass the 
constant "F_OK" as the mode, the "access" function will basically check 
to see if you can access this file, "F_OK" just checks to make sure the 
file exists. we could also OR "F_OK" with "R_OK" to make sure that we 
can also read this file.

the logic that is used to check to see if the two files are different 
involves the use of the "stat" function. the entire structure the 
"stat" function fills in is checked (using "memcmp"), but this 
structure also gives information about inodes and other such stuff. 
what i'm pointing out is that the one file would have to be a link to 
the other in order for them to compare equal. so if you have two 
distinct files, each of which has the exact same contents, the 
comparison will show that they are different. i believe the original 
intent was that the init file in the current directory should only be 
processed if its contents aren't the same as the contents of the init 
file in the $HOME directory.

so is there a C function that will compare the contents of two files? i 
don't think so (but i could be wrong of course). i'd gladly write up 
such a little function and provide it if anyone cares. i've added the 
call to "access" in my own version, but without the check for file 
differences it doesn't amount to much.

best regards,
	trevor

ps. again, sorry for mangling my email, just remove the caps if you 
want to reply personally.
-- 
http://home.ica.net/~vjbtlw/

_______________________________________________
Bug-gdb mailing list
Bug-gdb@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-gdb

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]