Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [tcf-dev] compute_reverse_lookup_indices line state question 
Hi Samuel,

> I suppose the latter is an erroneous behavior, is it not?

I see nothing wrong with it. If compiler puts instructions from same line into two or more disconnected ranges of memory addresses, the debugger has to follow that layout. In some cases it makes perfect sense. For example, line "for(i=0;i<10;i++)" can have "i++" part at different address, and this is fine. In other cases, it can be counter-intuitive. In any case, the compiler decides code layout, debugger cannot do much about it.

Regards,
Eugene

-----Original Message-----
From: tcf-dev-bounces@xxxxxxxxxxx [mailto:tcf-dev-bounces@xxxxxxxxxxx] On Behalf Of Samuel Ghinet
Sent: Tuesday, January 05, 2016 3:39 AM
To: tcf-dev@xxxxxxxxxxx
Subject: Re: [tcf-dev] compute_reverse_lookup_indices line state question

Hi Eugene,

Sorry for coming back so late on this.

 > DWARF specs suggest redundant line info entries to be removed by
compiler. Not all compilers do that, causing confusing debugger behavior
during stepping.

The problem I had found is that this piece of code in tcf does not
remove ALL redundant line info entries.
If you have line info entries like this (I give only line numbers here):
10, 12, 12, 12, 13
The result is correct:
10, 12, 13

but if the compiler provides the line info entries like this:
12, 10, 12, 12, 13

then the result will be:
12, 10, 12, 13

I suppose the latter is an erroneous behavior, is it not?

Thanks,
Samuel


On 10/28/2015 6:00 PM, tcf-dev-request@xxxxxxxxxxx wrote:
> Message: 1
> Date: Tue, 27 Oct 2015 19:03:22 +0000
> From: Eugene Tarassov <eugene.tarassov@xxxxxxxxxx>
> To: TCF Development <tcf-dev@xxxxxxxxxxx>
> Subject: Re: [tcf-dev] compute_reverse_lookup_indices line state
>       question
> Message-ID:
>       <C6480A6E4DA645449BBE7C12AE291FC2B000E72B@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
>
> Content-Type: text/plain; charset="us-ascii"
>
> Hi Samuel,
>
> I'm not sure what your question means exactly.
>
> DWARF specs suggest redundant line info entries to be removed by compiler.
> Not all compilers do that, causing confusing debugger behavior during stepping.
> So we have this code in the agent as workaround.
>
> I see nothing wrong the code. Do you see any issues with it?
>
> Regards,
> Eugene
>
>
> -----Original Message-----
> From: tcf-dev-bounces@xxxxxxxxxxx [mailto:tcf-dev-bounces@xxxxxxxxxxx] On Behalf Of Samuel Ghinet
> Sent: Tuesday, October 27, 2015 2:18 AM
> To: tcf-dev@xxxxxxxxxxx
> Subject: [tcf-dev] compute_reverse_lookup_indices line state question
>
> Hello guys,
>
> In the function "compute_reverse_lookup_indices" of dwarfcache.c we've
> gotten this piece of code:
>
>   > for (i = 0; i < Unit->mStatesCnt; i++) {
>   >         LineNumbersState * s1 = Unit->mStates + i;
>   >         while (i + 1 < Unit->mStatesCnt) {
>   >             LineNumbersState * s2 = s1 + 1;
>   >             if (s1->mFile != s2->mFile ||
>   >                 s1->mLine != s2->mLine || s1->mColumn != s2->mColumn ||
>   >                 s1->mFlags != s2->mFlags || s1->mISA != s2->mISA ||
>   >                 s1->mOpIndex != s2->mOpIndex || s1->mDiscriminator !=
> s2->mDiscriminator) break;
>   >             memmove(s2, s2 + 1, sizeof(LineNumbersState) *
> (Unit->mStatesCnt - i - 2));
>   >             Unit->mStatesCnt--;
>   >         }
>   >         Unit->mStatesIndex[i] = s1;
>   >     }
>
> In the Dwarf4 documentation I read:
>
>   > (...) matrix (...)  We shrink it with two techniques. First, we
> delete from the matrix each row whose file, line, source
>   > column and discriminator information is identical with that of its
> predecessors. Any deleted row would never be the
>   > beginning of a source statement.
>
> I am not sure how it should be done if you've got the following sequence
> (of LineNumberState-s):
> A
> A
> B
> A
>
> The algorithm in the function practically translates it to:
> A
> B
> A
>
> Is this behavior okay? Technically, the first A is a predecessor of the
> second A, is it not?
>
> Thanks,
> Samuel
>
> _______________________________________________
> tcf-dev mailing list
> tcf-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://dev.eclipse.org/mailman/listinfo/tcf-dev
>
>
> This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.
>
>
>
> ------------------------------
>
> _______________________________________________
> tcf-dev mailing list
> tcf-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://dev.eclipse.org/mailman/listinfo/tcf-dev
>
> End of tcf-dev Digest, Vol 60, Issue 11
> ***************************************

_______________________________________________
tcf-dev mailing list
tcf-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/tcf-dev


This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.

Back to the top