This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [rtlopt] Location list data
On Sun, Mar 09, 2003 at 09:03:43PM -0800, Geoff Keating wrote:
> Daniel Jacobowitz <drow at mvista dot com> writes:
>
> > 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; )
>
> This is not quite right. There are two uses for this data:
>
> 1. 'print j'. In that case, you could just claim that it's always in
> the global address, and that would work fine.
Except in more complex examples; if I changed j in that loop, it would
probably be modified in the register.
> 2. 'j = 3'. For that, you have to explain that the variable is in
> *both* places, because both will need to be updated. You certainly
> wouldn't want to be just changing the register, since that'll go away.
>
> I think you really want to say is (and have no idea if this is legal
> DWARF2, or for that matter if GCC can do this):
>
> 00000013 00000000 ffffffff (DW_OP_addr: 80493b8; )
> 00000013 00000027 0000002a (DW_OP_reg2; )
> 00000013 00000032 0000003a (DW_OP_reg2; )
It is legal to have overlapping ranges. GDB isn't quite ready to deal
with it but some day I imagine it will be. I think it's reasonable to
have the 00000000-ffffffff form refer to variables available even when
the program isn't running, so I'll probably make GDB aware of that if
GCC emits it.
Eventually we'll need to handle the more interesting case of a variable
which partly lives in a stack slot and partly in a register and partly
in both. When it's in a register we don't want to change the stack
slot, since GCC may be using it for something else.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer