git compile with debug symbols

git compile with debug symbols

[Mahesh Pujari]

Hello,
 I am trying to compile git with debug symbols and failed to do so (basically I am a noob), can some one direct me to links or mailing list (have searched but couldn't find) or doc's so that I can debug git using gdb.

thanks,
mpujari

Re: git compile with debug symbols

[David Kastrup]

Mahesh Pujari <pujarimahesh_kumar@yahoo.com> writes:

> Hello,
>  I am trying to compile git with debug symbols and failed to do so
> (basically I am a noob), can some one direct me to links or mailing
> list (have searched but couldn't find) or doc's so that I can debug
> git using gdb.

git is compiled with debug symbols by default.

-- 
David Kastrup

Re: git compile with debug symbols

[karthik nayak]

A quick look at the Makefile shows that -g is enabled by default. so
debugging is enabled by default

On Tue, Mar 4, 2014 at 9:16 PM, Mahesh Pujari
<pujarimahesh_kumar@yahoo.com> wrote:
>
>
> Hello,
>  I am trying to compile git with debug symbols and failed to do so (basically I am a noob), can some one direct me to links or mailing list (have searched but couldn't find) or doc's so that I can debug git using gdb.
>
> thanks,
> mpujari
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: git compile with debug symbols

[Matthieu Moy]

David Kastrup <dak@gnu.org> writes:

> Mahesh Pujari <pujarimahesh_kumar@yahoo.com> writes:
>
>> Hello,
>>  I am trying to compile git with debug symbols and failed to do so
>> (basically I am a noob), can some one direct me to links or mailing
>> list (have searched but couldn't find) or doc's so that I can debug
>> git using gdb.
>
> git is compiled with debug symbols by default.

... but:

1) some Git commands are shell-scripts, on which you can't use gdb.

2) some Git commands fork other commands, and then you have to deal with
   multiple processes (i.e. putting a breakpoint in a piece of code
   executed by the subprocess won't work if gdb is running on the other
   one).

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: git compile with debug symbols

[Mahesh Pujari]

Thanks David for the reply. I think I need to do more ground work of going through how to use gdb.
Basically I am java programmer and I was trying out to debug git source using eclipse CDT and as we do in java, I was trying out to set break point but failed with errors as "No line 396 in file "help.c"".
And using gdb too I end up with same error.

# (gdb) break help.c:396
# No line 396 in file "help.c".


Am I missing something.

thanks,
mpujari


On Tuesday, March 4, 2014 9:34 PM, Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> wrote:
David Kastrup <dak@gnu.org> writes:

> Mahesh Pujari <pujarimahesh_kumar@yahoo.com> writes:
>
>> Hello,
>>  I am trying to compile git with debug symbols and failed to do so
>> (basically I am a noob), can some one direct me to links or mailing
>> list (have searched but couldn't find) or doc's so that I can debug
>> git using gdb.
>
> git is compiled with debug symbols by default.

... but:

1) some Git commands are shell-scripts, on which you can't use gdb.

2) some Git commands fork other commands, and then you have to deal with
   multiple processes (i.e. putting a breakpoint in a piece of code
   executed by the subprocess won't work if gdb is running on the other

   one).

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: git compile with debug symbols

[David Kastrup]

Mahesh Pujari <pujarimahesh_kumar@yahoo.com> writes:

> Thanks David for the reply. I think I need to do more ground work of
> going through how to use gdb.
> Basically I am java programmer and I was trying out to debug git
> source using eclipse CDT and as we do in java, I was trying out to set
> break point but failed with errors as "No line 396 in file "help.c"".
> And using gdb too I end up with same error.
>
> # (gdb) break help.c:396
> # No line 396 in file "help.c".
>
>
> Am I missing something.

There is just no line 396 known to gdb.  It seems like you are
indicating a function header.  That's not code.  Either take the
function _name_ rather than a line number (that's usually most reliable)
or take the first line of actual code.

-- 
David Kastrup

Re: git compile with debug symbols

[Tanay Abhra]

Mahesh Pujari <pujarimahesh_kumar <at> yahoo.com> writes:

> 
> 
> Hello,
>  I am trying to compile git with debug symbols and failed to do so
(basically I am a noob), can some one direct
> me to links or mailing list (have searched but couldn't find) or doc's so
that I can debug git using gdb.
> 
> thanks,
> mpujari
> 
> 


Hi,

I tried to put a break point at help.c:396 and it was successful . I think
that the problem is either your symbols are not loaded.
Nevertheless I will walk you through the steps.

$ git clone https://github.com/git/git
$ make
$ gdb ./git
$(gdb)> gdb break help.c:396
Breakpoint 1 at 0x80f8b40: file help.c, line 396.

Cheers,
Tanay Abhra.

Re: git compile with debug symbols

[Mahesh Pujari]

Hello all,
 Thanks for replying back, figured out (offcourse had to search in net) that 'gdb' version I had was 6.7.1 (OS Ubuntu 12.04 LST), not sure how I got this. Then I upgraded gdb to version 7.4-2012.04 and things got going.


thanks,
mpujari


On Tuesday, March 4, 2014 10:13 PM, David Kastrup <dak@gnu.org> wrote:
Mahesh Pujari <pujarimahesh_kumar@yahoo.com> writes:

> Thanks David for the reply. I think I need to do more ground work of
> going through how to use gdb.
> Basically I am java programmer and I was trying out to debug git
> source using eclipse CDT and as we do in java, I was trying out to set
> break point but failed with errors as "No line 396 in file "help.c"".
> And using gdb too I end up with same error.
>
> # (gdb) break help.c:396
> # No line 396 in file "help.c".
>
>
> Am I missing something.

There is just no line 396 known to gdb.  It seems like you are
indicating a function header.  That's not code.  Either take the
function _name_ rather than a line number (that's usually most reliable)
or take the first line of actual code.


-- 
David Kastrup