[flang-dev] Question WRT to debug info in flang.

Sourabh Singh Tomar via flang-dev flang-dev at lists.llvm.org
Sat Apr 11 11:44:06 PDT 2020


Hello Everyone,

As I was investigating this removal of redundant entry(just after
subprogram) Lexical Block, that's being created by flang. I need to know
your(debug info folks) thoughts on this.
I mean are there any existing effort going on this direction? Or anyone
interested in discussing about this?

flang behavior  as of now--
-----------------------
$cat test.f90
program main
integer alpha
alpha = 2
end program
-----------------------
dwarf generated by flang --
0x0000002f:   DW_TAG_subprogram
                DW_AT_name      ("main")
                ....
*0x0000004b:     DW_TAG_lexical_block   --- Redundant Block. Creating
un-necessary scope for debugger to process and hence forth.*
                  DW_AT_low_pc  (0x00000000002018a8)
                  DW_AT_high_pc (0x00000000002018c9)
0x0000005c:       DW_TAG_variable
                    DW_AT_location      (DW_OP_fbreg -4)
                    DW_AT_name  ("alpha")
                    DW_AT_type  (0x0000006a "integer")

gfortran dwarf for same test case --
0x00000086:   DW_TAG_subprogram
                DW_AT_name      ("MAIN__")
                .....
0x000000a0:     DW_TAG_variable
                  DW_AT_name    ("alpha")
                  DW_AT_type    (0x0000006d "integer(kind=4)")
                  DW_AT_location        (DW_OP_fbreg -20)

As of now no existing front-ends including trunk gfortran does not emits
this redundant Lexical Block, here's a link(patch) when GCC suite removed
it --
https://patchwork.ozlabs.org/patch/436971/

Thank You!
Sourabh Singh Tomar.


On Thu, Mar 26, 2020 at 12:43 AM Sourabh Singh Tomar <sourav0311 at gmail.com>
wrote:

> Hi Gary,
>
> Thank you for quick response!
> Since I was working/investigating this, so before filing this bug could
> you please help me clarify a couple of things? WRT to flang.
>
> Are their Blocks(Lexical Blocks) even present at ILM or ILI level, because
> consider the case of *value* removed(pass by reference) flang also emit
> *DW_TAG_lexical_block* in this case also.
>
> And these lexical blocks have nearly ranges as the parent subroutine. To
> be exact high_pc are same, but low_pc of lexical block corresponds to
> prologue end of the subroutine.
>
> 0x0000002f:   DW_TAG_subprogram
>                 DW_AT_low_pc    (0x0000000000201ae0)
>                 DW_AT_high_pc   (0x0000000000201b75)
> 0x000000**:   DW_TAG_lexical_block
>                 DW_AT_low_pc    (0x0000000000201a**) -- marking prologue
> end of subroutine
>                 DW_AT_high_pc   (0x0000000000201b75)
>
> Correct me if I'm wrong here, Fortran Doesn't have lexical scoping? If it
> doesn't have we may have to strip out the *Lexical Block* creation part, in
> debug info.
>
> Regarding bug filing should we create a specific bug WRT to *Lexical
> block* or a something more generic *unable to retrieve formal parameter in
> case of pass  by value arguments* or third option will be to keep both of
> these issues orthogonal to each other.
>
> Please share your thoughts on this.
>
> Thank You,
> Sourabh Singh Tomar.
>
>
>
>
> On Wed, Mar 25, 2020 at 3:47 AM Gary Klimowicz <gklimowicz at nvidia.com>
> wrote:
>
>> Hi, Sourabh.
>>
>>
>>
>> We've confirmed the bug. It can be worked around by removing the VALUE
>> attribute.
>>
>>
>>
>> Can you file an issue for us on the (current) Flang GitHub site?
>>
>> https://github.com/flang-compiler/flang/issues
>>
>>
>>
>> Thank you.
>>
>>
>>
>>
>>
>> On 3/24/20, 12:52 PM, "flang-dev on behalf of Sourabh Singh Tomar via
>> flang-dev" <flang-dev-bounces at lists.llvm.org on behalf of
>> flang-dev at lists.llvm.org> wrote:
>>
>>
>>
>> *External email: Use caution opening links or attachments*
>>
>>
>>
>> Hello Everyone,
>>
>>
>>
>> For a typical Fortran program compiled with flang with -g(debuginfo
>> enabled), I'm noticing *DW_TAG_lexical_block* is getting created as child
>> of the *DW_TAG_subprogram*.
>>
>> As a consequence of this debuggers like GDB  is not able to show the
>> arguments of the subprogram.
>>
>> Program snippet -
>>
>> subroutine sub(foo)
>>         integer, value :: foo
>>         print*,foo
>>       end subroutine
>> program main
>>       interface
>>         subroutine sub(a)
>>               integer, value :: a
>>          end subroutine
>>       end interface
>>              call sub(11)
>>  end program
>>
>> --------------------------------
>>
>> Snippet from GDB --
>>
>> Breakpoint 1, sub () at test.f90:1
>> 1             subroutine sub(foo)
>> (gdb) info args
>> No arguments.
>>
>> -----------------------------------
>>
>> Furthermore, *DW_TAG_formal_parameter* is created as a child of this
>> *DW_TAG_lexical_scope*. Hence GDB is showing arguments of the subprogram as
>> locals variables.
>>
>> Snippet DWARF--
>>
>> 0x0000002f:   DW_TAG_subprogram
>>
>> DW_AT_name      ("sub")
>>
>>  DW_AT_low_pc    (0x00000000004011b0)
>>  DW_AT_high_pc   (0x0000000000401245
>> .....
>> 0x00000049:     DW_TAG_lexical_block
>>
>>  DW_AT_low_pc    (0x00000000004011b0)
>>  DW_AT_high_pc   (0x0000000000401245
>>  ....
>> 0x0000005a:       DW_TAG_formal_parameter
>>
>>   DW_AT_name      ("foo")
>>
>> 0x0000005a:       DW_TAG_variable
>>
>>   DW_AT_name      ("foo")
>>
>> ...
>>
>> ---------------------------------------
>>
>> Is this behavior intended ?
>>
>>
>>
>> Anyone working on this area, Please share your understanding on this!
>>
>>
>>
>> *Please note here that same hierarchy of debug info is also present at
>> LLVM IR level, hence the final DWARF is shared here.
>>
>>
>>
>> Thank You,
>>
>> Sourabh.
>> ------------------------------
>> This email message is for the sole use of the intended recipient(s) and
>> may contain confidential information.  Any unauthorized review, use,
>> disclosure or distribution is prohibited.  If you are not the intended
>> recipient, please contact the sender by reply email and destroy all copies
>> of the original message.
>> ------------------------------
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/flang-dev/attachments/20200412/bb47683a/attachment-0001.html>


More information about the flang-dev mailing list