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 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
***************************************

Back to the top