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

[Nicolas Setton]

> 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