[rtlopt] Location list data

[Daniel Jacobowitz <drow at mvista dot com>]

I'm looking at the current location lists emitted by the rtlopt branch for a
couple of simple testcases.  I've got GDB successfully using them, and it
wasn't too painful to do; but there are some loose ends.  Here's one of
them.  Consider this testcase:

int j = 2;

extern void baz (int *);
void baz(int *bar)
{ 
  ;
}

int main()
{ 
  int i = 1, k;
  for (k = 0; k < 10; k++)
    i = i * j;
  baz (&i);
  return i;
}


We've got a global variable 'j'.  On i386 with -O2, it gets loaded into a
register.  The location list looks like this:

    00000013 00000021 00000027 (DW_OP_addr: 80493b8; )
    00000013 00000027 0000002a (DW_OP_reg2; )
    00000013 0000002a 00000032 (DW_OP_addr: 80493b8; )
    00000013 00000032 0000003a (DW_OP_reg2; )
    00000013 0000003a 00000040 (DW_OP_addr: 80493b8; )

i.e. during part of main it's in one place, during two small stretches it's
in a register, then it's back in memory.  This is suboptimal for a couple of
reasons.  We don't really need to say that it moves to the register, since
it's never modified, but that's not a big deal.  What is a big deal is that
the range is limited.  The code that goes along with it:

 8048331:       8b 15 b8 93 04 08       mov    0x80493b8,%edx
 8048337:       83 e4 f0                and    $0xfffffff0,%esp
 804833a:       8d b6 00 00 00 00       lea    0x0(%esi),%esi
 8048340:       89 cb                   mov    %ecx,%ebx
 8048342:       0f af da                imul   %edx,%ebx
 8048345:       48                      dec    %eax
 8048346:       89 d9                   mov    %ebx,%ecx
 8048348:       79 f6                   jns    8048340 <main+0x20>
 804834a:       8d 45 f8                lea    0xfffffff8(%ebp),%eax
 804834d:       89 04 24                mov    %eax,(%esp,1)
 8048350:       e8 bb ff ff ff          call   8048310 <baz>

So it "comes into existence" at the beginning of that move; then it "fades
from existence" before the end of main.  The debugger has no conception of a
"normal" location for this variable (and I don't see a clear way to give it
one in the DWARF spec).  But we need to somehow convey that the variable is
always there.  Even when we're in another function or another file, we can
read j; it's a global!

How should we represent this?  Are we going to need to take it to the DWARF
committee to get a real syntax for this, or am I missing something obvious
about how it's supposed to work?  Anyone know how any other
compilers/debuggers handle this?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer