[PATCH] Refactor debug info lexical block generation

Aboud, Amjad amjad.aboud at intel.com
Wed May 27 07:34:54 PDT 2015


Lexical Blocks are collected only during function process, once we finish processing the function, all final lexical block DIEs are created but there is no map between the LLVM lexical block and the DIE lexical block.
This works just fine for nested lexical blocks and local variables.
However, it does not work with function static variables and types, such as typedef and records.

Function static variables are treated as global variables and are processed before processing the module functions.
While types are processed at the end after processing all the functions, at end-module.

So, to solve the bug we need to do several steps:
1. Keep a map between LLVM lexical block and DIE lexical block.
2. Defer the decision of collapsing lexical blocks to the point where the lexical block DIE have all its children (including function static variables, typedef and records).
3. Process function static variables at end-module, i.e. after all lexical basic block are processed.

And this is what the patches do.

Regards,
Amjad

-----Original Message-----
From: Frederic Riss [mailto:friss at apple.com] 
Sent: Wednesday, May 27, 2015 08:13
To: Aboud, Amjad; echristo at gmail.com; benny.kra at gmail.com; dblaikie at gmail.com
Cc: friss at apple.com; llvm-commits at cs.uiuc.edu; Paul_Robinson at playstation.sony.com
Subject: Re: [PATCH] Refactor debug info lexical block generation

In http://reviews.llvm.org/D9960#179217, @probinson wrote:

> In http://reviews.llvm.org/D9960#179153, @friss wrote:
>
> > It would be nice to have a description of how exactly the patch fixes the issue. It seems easy to understand what the patch does, but I don't see where we were losing the information in the first place (ie. how does premature coalescing lose the inner variable?)
>
>
> This patch by itself isn't enough; this one is just deferring the time when pointless lexical blocks get collapsed.  It's a refactoring that I asked to have done separately.
>  The real problem is that a local static variable wasn't being attached to the proper lexical block, partly because the proper block no longer existed.  This patch should let the lexical block live long enough to get the static variable attached (by a different patch), at which point the lexical block won't be considered pointless and won't be eliminated.
>  I hope that makes sense...


Kinda. Does that mean that we never kept nested scopes or are there more intricate conditions that makes us discard that particular nested scope? (I suppose the latter because otherwise we'd never generate any lexical scope)


REPOSITORY
  rL LLVM

http://reviews.llvm.org/D9960

EMAIL PREFERENCES
  http://reviews.llvm.org/settings/panel/emailpreferences/


---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.




More information about the llvm-commits mailing list