Re: [PATCH/RFC] PR other/22313: Hot/cold sections vs. dwarf2 (take 2)

[Nicolas Setton <setton at adacore dot com>]

> I propose to apply this patch to mainline [and the 4.1 branch] in a
> few days, unless one of our debugging guru's can point out a flaw in
> my interpretation of dwarf-2 specification that seems to imply that
> advance_loc* can advance from either the previous advance_loc* or
> set_loc.  [I'm also curious whether binutils/gcc can/should perform
> advance_loc relaxation.  Currently we always emit advance_loc4, but
> for small deltas we could reduce the size of debugging information
> by using advance_loc1 and/or advance_loc2].
>
> Thoughts?  Ok for mainline and the 4.1 branch?

I guess that this patch is incomplete, in that it breaks printing in  
the debugger of variables allocated on the stack and for which the  
dwarf-2 location is calculated relatively to the frame base.

To exhibit the problem, consider the following code:

  typedef struct
  {
     int a;
  } thing;

  int main (void)
  {
    thing a;
    a.a = 7;
    return a.a;
  }

Then try to break in "main" and print variable "a", you'll get the  
following message:
  Could not find the frame base for "main".


Further analysis. When compiling the example above with the patch  
included, on x86-linux, the location expression for the frame base  
starts with this:

.LLST0:
        .long   .LFB2-.Ltext0   # Location list begin address (*.LLST0)
        .long   .LFB2-.Ltext0   # Location list end address (*.LLST0)

The first location expression is a null address range, which is a  
list terminator in dwarf-2.

I suspect that the problem comes from the current implementation of  
convert_cfa_to_loc_list, which currently expects only  
DW_CFA_advance_loc statements in the CFI instructions; it should be  
enhanced to expect and handle the DW_CFA_set_loc statements as well.  
What do the experts think about this?

(If this problem is already known and/or fixed, I apologize for the  
noise.)

Nicolas