Issue with GDB 7.0 on MIPS(gcc 4.4.1)

Issue with GDB 7.0 on MIPS(gcc 4.4.1)

[naveen yadav]

Hi All,

I am running one application and it generate core dump. When I run bt .
(gdb) bt
#0  wepp (gn=0x5d5f58, ef=0x5c43000, Bytes=429496729, gcOs=0x5c3408f)
#1  CompactCollect (gn=0x5d5f58, ef=0x5c43000, Bytes=429496729, gcOs=0x5c3408f)
...

In above case
we got crash in wepp().
CompactCollect () is main function and wepp() is another function
which got called from CompactCollect ().

When I check the assembly wepp() become inline.
So i got bit surprise when i check that function parameter;s for both
wepp() and CompactCollect () are same.

So is it correct behaviour ? that calling and calle have same parameter

Thanks.

Issue with GDB 7.0 on MIPS(gcc 4.4.1)

[naveen yadav]

Hi All,

I am running one application and it generate core dump. When I run bt .
(gdb) bt
#0  wepp (gn=0x5d5f58, ef=0x5c43000, Bytes=429496729, gcOs=0x5c3408f)
#1  CompactCollect (gn=0x5d5f58, ef=0x5c43000, Bytes=429496729, gcOs=0x5c3408f)
...

In above case
we got crash in wepp().
CompactCollect () is main function and wepp() is another function
which got called from CompactCollect ().

When I check the assembly wepp() become inline.
So i got bit surprise when i check that function parameter;s for both
wepp() and CompactCollect () are same.

So is it correct behaviour ? that calling and calle have same parameter

Thanks.

Re: Issue with GDB 7.0 on MIPS(gcc 4.4.1)

[Ian Lance Taylor]

naveen yadav <yad.naveen@gmail.com> writes:

> I am running one application and it generate core dump. When I run bt .
> (gdb) bt
> #0  wepp (gn=0x5d5f58, ef=0x5c43000, Bytes=429496729, gcOs=0x5c3408f)
> #1  CompactCollect (gn=0x5d5f58, ef=0x5c43000, Bytes=429496729, gcOs=0x5c3408f)
> ...
>
> In above case
> we got crash in wepp().
> CompactCollect () is main function and wepp() is another function
> which got called from CompactCollect ().
>
> When I check the assembly wepp() become inline.
> So i got bit surprise when i check that function parameter;s for both
> wepp() and CompactCollect () are same.
>
> So is it correct behaviour ? that calling and calle have same parameter

Without any information about the source code, I don't see how we can
tell whether having the same parameters is correct behaviour or not.

That said, it is certainly possible that the arguments of the inlined
function are not being displayed correctly.  Mainline gcc has gotten
quite a bit better about debug info for inlined functions and in general
for avoiding incorrect display of variables in optimized code.

Ian

Re: Issue with GDB 7.0 on MIPS(gcc 4.4.1)

[naveen yadav]

Hi Ian,

My GCC  version 4.4.1. and  here is source code.

http://gingacdn.lavid.ufpb.br/projects/ginga-j/repository/revisions/7e233c1906624b0e01698415987aada3fd8c3fe4/entry/gingaj/jvm/src/share/javavm/runtime/gc/generational/gen_markcompact.c

and here is backtrace.

mips-gdb> bt
sweep (gen=0x5d5f508, ee=0x5c4300d0, numBytes=4294967295,
gcOpts=0x5c3408f8) #1
CVMgenMarkCompactCollect (gen=0x5d5f508, ee=0x5c4300d0,
numBytes=4294967295, gcOpts=0x5c3408f8)

 ......

If you need more detail pls let me know..
Thanks.

On Fri, Nov 11, 2011 at 10:01 PM, Ian Lance Taylor <iant@google.com> wrote:
> naveen yadav <yad.naveen@gmail.com> writes:
>
>> I am running one application and it generate core dump. When I run bt .
>> (gdb) bt
>> #0  sweep (gn=0x5d5f58, ef=0x5c43000, Bytes=429496729, gcOs=0x5c3408f)
>> #1  CompactCollect (gn=0x5d5f58, ef=0x5c43000, Bytes=429496729, gcOs=0x5c3408f)
>> ...
>>
>> In above case
>> we got crash in wepp().
>> CompactCollect () is main function and wepp() is another function
>> which got called from CompactCollect ().
>>
>> When I check the assembly wepp() become inline.
>> So i got bit surprise when i check that function parameter;s for both
>> wepp() and CompactCollect () are same.
>>
>> So is it correct behaviour ? that calling and calle have same parameter
>
> Without any information about the source code, I don't see how we can
> tell whether having the same parameters is correct behaviour or not.
>
> That said, it is certainly possible that the arguments of the inlined
> function are not being displayed correctly.  Mainline gcc has gotten
> quite a bit better about debug info for inlined functions and in general
> for avoiding incorrect display of variables in optimized code.
>
> Ian
>

Re: Issue with GDB 7.0 on MIPS(gcc 4.4.1)

[Ian Lance Taylor]

naveen yadav <yad.naveen@gmail.com> writes:

> My GCC  version 4.4.1. and  here is source code.
>
> http://gingacdn.lavid.ufpb.br/projects/ginga-j/repository/revisions/7e233c1906624b0e01698415987aada3fd8c3fe4/entry/gingaj/jvm/src/share/javavm/runtime/gc/generational/gen_markcompact.c
>
> and here is backtrace.
>
> mips-gdb> bt
> sweep (gen=0x5d5f508, ee=0x5c4300d0, numBytes=4294967295,
> gcOpts=0x5c3408f8) #1
> CVMgenMarkCompactCollect (gen=0x5d5f508, ee=0x5c4300d0,
> numBytes=4294967295, gcOpts=0x5c3408f8)

Looking at the code, it's perfectly obvious that gdb is reporting the
arguments to sweep incorrectly.  The sweep function takes three
arugments: thisGen, base, and top.  It is called only from
CVMgenMarkCompactCollect, and that function takes four arguments, gen,
ee, numBytes, and gcOpts.

Clearly the parameters to sweep are being reported incorrectly.  I don't
think you really needed me to tell you that.  I don't know where the bug
is, but my guess would be that gcc 4.4.1 is not generating correct debug
info for inlined functions.

Ian


>
>  ......
>
> If you need more detail pls let me know..
> Thanks.
>
> On Fri, Nov 11, 2011 at 10:01 PM, Ian Lance Taylor <iant@google.com> wrote:
>> naveen yadav <yad.naveen@gmail.com> writes:
>>
>>> I am running one application and it generate core dump. When I run bt .
>>> (gdb) bt
>>> #0  sweep (gn=0x5d5f58, ef=0x5c43000, Bytes=429496729, gcOs=0x5c3408f)
>>> #1  CompactCollect (gn=0x5d5f58, ef=0x5c43000, Bytes=429496729, gcOs=0x5c3408f)
>>> ...
>>>
>>> In above case
>>> we got crash in wepp().
>>> CompactCollect () is main function and wepp() is another function
>>> which got called from CompactCollect ().
>>>
>>> When I check the assembly wepp() become inline.
>>> So i got bit surprise when i check that function parameter;s for both
>>> wepp() and CompactCollect () are same.
>>>
>>> So is it correct behaviour ? that calling and calle have same parameter
>>
>> Without any information about the source code, I don't see how we can
>> tell whether having the same parameters is correct behaviour or not.
>>
>> That said, it is certainly possible that the arguments of the inlined
>> function are not being displayed correctly.  Mainline gcc has gotten
>> quite a bit better about debug info for inlined functions and in general
>> for avoiding incorrect display of variables in optimized code.
>>
>> Ian
>>

Re: Issue with GDB 7.0 on MIPS(gcc 4.4.1)

[naveen yadav]

Thanks Ian,

Yes  problem that sweep ()  function shows the argument of
CVMgenMarkCompactCollect () function. sweep() function got inlined.


So I just request is there any patch available to fix this problem ?

Thanks



On Mon, Nov 14, 2011 at 12:20 PM, Ian Lance Taylor <iant@google.com> wrote:
> naveen yadav <yad.naveen@gmail.com> writes:
>
>> My GCC  version 4.4.1. and  here is source code.
>>
>> http://gingacdn.lavid.ufpb.br/projects/ginga-j/repository/revisions/7e233c1906624b0e01698415987aada3fd8c3fe4/entry/gingaj/jvm/src/share/javavm/runtime/gc/generational/gen_markcompact.c
>>
>> and here is backtrace.
>>
>> mips-gdb> bt
>> sweep (gen=0x5d5f508, ee=0x5c4300d0, numBytes=4294967295,
>> gcOpts=0x5c3408f8) #1
>> CVMgenMarkCompactCollect (gen=0x5d5f508, ee=0x5c4300d0,
>> numBytes=4294967295, gcOpts=0x5c3408f8)
>
> Looking at the code, it's perfectly obvious that gdb is reporting the
> arguments to sweep incorrectly.  The sweep function takes three
> arugments: thisGen, base, and top.  It is called only from
> CVMgenMarkCompactCollect, and that function takes four arguments, gen,
> ee, numBytes, and gcOpts.
>
> Clearly the parameters to sweep are being reported incorrectly.  I don't
> think you really needed me to tell you that.  I don't know where the bug
> is, but my guess would be that gcc 4.4.1 is not generating correct debug
> info for inlined functions.
>
> Ian
>
>
>>
>>  ......
>>
>> If you need more detail pls let me know..
>> Thanks.
>>
>> On Fri, Nov 11, 2011 at 10:01 PM, Ian Lance Taylor <iant@google.com> wrote:
>>> naveen yadav <yad.naveen@gmail.com> writes:
>>>
>>>> I am running one application and it generate core dump. When I run bt .
>>>> (gdb) bt
>>>> #0  sweep (gn=0x5d5f58, ef=0x5c43000, Bytes=429496729, gcOs=0x5c3408f)
>>>> #1  CompactCollect (gn=0x5d5f58, ef=0x5c43000, Bytes=429496729, gcOs=0x5c3408f)
>>>> ...
>>>>
>>>> In above case
>>>> we got crash in wepp().
>>>> CompactCollect () is main function and wepp() is another function
>>>> which got called from CompactCollect ().
>>>>
>>>> When I check the assembly wepp() become inline.
>>>> So i got bit surprise when i check that function parameter;s for both
>>>> wepp() and CompactCollect () are same.
>>>>
>>>> So is it correct behaviour ? that calling and calle have same parameter
>>>
>>> Without any information about the source code, I don't see how we can
>>> tell whether having the same parameters is correct behaviour or not.
>>>
>>> That said, it is certainly possible that the arguments of the inlined
>>> function are not being displayed correctly.  Mainline gcc has gotten
>>> quite a bit better about debug info for inlined functions and in general
>>> for avoiding incorrect display of variables in optimized code.
>>>
>>> Ian
>>>
>

Re: Issue with GDB 7.0 on MIPS(gcc 4.4.1)

[Ian Lance Taylor]

naveen yadav <yad.naveen@gmail.com> writes:

> So I just request is there any patch available to fix this problem ?

I don't know.  As I said earlier, current versions of gcc are much
better at debugging info for inlined functions, and are much better at
not incorrectly reporting variable values for optimized code.  However,
I have no idea whether that will help with this specific problem.

Ian

> On Mon, Nov 14, 2011 at 12:20 PM, Ian Lance Taylor <iant@google.com> wrote:
>> naveen yadav <yad.naveen@gmail.com> writes:
>>
>>> My GCC  version 4.4.1. and  here is source code.
>>>
>>> http://gingacdn.lavid.ufpb.br/projects/ginga-j/repository/revisions/7e233c1906624b0e01698415987aada3fd8c3fe4/entry/gingaj/jvm/src/share/javavm/runtime/gc/generational/gen_markcompact.c
>>>
>>> and here is backtrace.
>>>
>>> mips-gdb> bt
>>> sweep (gen=0x5d5f508, ee=0x5c4300d0, numBytes=4294967295,
>>> gcOpts=0x5c3408f8) #1
>>> CVMgenMarkCompactCollect (gen=0x5d5f508, ee=0x5c4300d0,
>>> numBytes=4294967295, gcOpts=0x5c3408f8)
>>
>> Looking at the code, it's perfectly obvious that gdb is reporting the
>> arguments to sweep incorrectly.  The sweep function takes three
>> arugments: thisGen, base, and top.  It is called only from
>> CVMgenMarkCompactCollect, and that function takes four arguments, gen,
>> ee, numBytes, and gcOpts.
>>
>> Clearly the parameters to sweep are being reported incorrectly.  I don't
>> think you really needed me to tell you that.  I don't know where the bug
>> is, but my guess would be that gcc 4.4.1 is not generating correct debug
>> info for inlined functions.
>>
>> Ian
>>
>>
>>>
>>>  ......
>>>
>>> If you need more detail pls let me know..
>>> Thanks.
>>>
>>> On Fri, Nov 11, 2011 at 10:01 PM, Ian Lance Taylor <iant@google.com> wrote:
>>>> naveen yadav <yad.naveen@gmail.com> writes:
>>>>
>>>>> I am running one application and it generate core dump. When I run bt .
>>>>> (gdb) bt
>>>>> #0  sweep (gn=0x5d5f58, ef=0x5c43000, Bytes=429496729, gcOs=0x5c3408f)
>>>>> #1  CompactCollect (gn=0x5d5f58, ef=0x5c43000, Bytes=429496729, gcOs=0x5c3408f)
>>>>> ...
>>>>>
>>>>> In above case
>>>>> we got crash in wepp().
>>>>> CompactCollect () is main function and wepp() is another function
>>>>> which got called from CompactCollect ().
>>>>>
>>>>> When I check the assembly wepp() become inline.
>>>>> So i got bit surprise when i check that function parameter;s for both
>>>>> wepp() and CompactCollect () are same.
>>>>>
>>>>> So is it correct behaviour ? that calling and calle have same parameter
>>>>
>>>> Without any information about the source code, I don't see how we can
>>>> tell whether having the same parameters is correct behaviour or not.
>>>>
>>>> That said, it is certainly possible that the arguments of the inlined
>>>> function are not being displayed correctly.  Mainline gcc has gotten
>>>> quite a bit better about debug info for inlined functions and in general
>>>> for avoiding incorrect display of variables in optimized code.
>>>>
>>>> Ian
>>>>
>>