bug-binutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug gas/26143] gas generates invalid line table entry


From: vries at gcc dot gnu.org
Subject: [Bug gas/26143] gas generates invalid line table entry
Date: Tue, 07 Jul 2020 16:47:42 +0000

https://sourceware.org/bugzilla/show_bug.cgi?id=26143

Tom de Vries <vries at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |aoliva at sourceware dot org

--- Comment #2 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Nick Clifton from comment #1)
> (In reply to Tom de Vries from comment #0)
> Hi Tom,
> 
> >   [0x00000080]  Special opcode 75: advance Address by 5 to 0x1c and Line by
> > 0 to 12
> >   [0x00000081]  Extended opcode 1: End of Sequence
> 
> > Every line number program sequence must end with a DW_LNE_end_sequence
> > instruction which creates a row whose address is that of the byte after the
> > last target machine instruction of the sequence.
> 
> > One the one hand, the end-of-sequence declares that address 0x1c is one past
> > the byte of the last target machine instruction of the sequence.
> > 
> > On the other hand, the special opcode declares a target instruction starting
> > at address 0x1c, that is part of that same sequence.
> 
> Ah - but special opcodes do not necessarily assert that there is a target
> instruction starting at the address they reference.  

Hi Nick,

As indicated in dwarf4 standard 6.2.5.1 point 3, each special opcode adds a row
to the matrix.

Each row represents a machine instruction, as implied here in 6.2:
...
If space were not a consideration, the information provided in the .debug_line
section could be represented as a large matrix, with one row for each
instruction in the emitted object code.
...
The exception is a row with end_sequence set to true, but that's not the case
for the row generated by:
...
  [0x00000080]  Special opcode 75: advance Address by 5 to 0x1c and Line by 0
to 12
...

So, I don't agree with this assessment.

If you still think my interpretation is wrong, you should state an alternative
one.  What does the generated row mean according to you, in terms of the DWARF
standard?

> 
> 
> >     This option causes a row to be added to .debug_line in reference to the
> > current address (which might not be the same as that of the following
> > assembly instruction),  
> 
> > I cannot tell from the formulation "in reference to the current address
> > (which might not be the same as that of the following assembly instruction)"
> > whether this particular instance of .loc usage is valid.
> 
> My take on this is that the "view" directive specifies a property for an
> address, but it does not require that there be an instruction at that
> address.  Hence the generated line number table is correct...
> 

I'm not sure the semantics of the view directive are relevant to the
correctness of the generated line number table.

It's my understanding that the implementation for views intends to emit pure
dwarf with no extensions, and that the view info can be interpreted by
consumers with support, and ignored by consumers without support.

After watching Alexandre Oliva's 2017 GNU Cauldron presentation, I get the
impression that the "which might not be the same as that of the following
assembly instruction" formulation refers to a situation like this:
...
.loc
.balign 32 
.loc
      insn1
...
where the first loc may or may not refer to insn1.

...

-- 
You are receiving this mail because:
You are on the CC list for the bug.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]