A thread has-a selected/current frame

A thread has-a selected/current frame

[Andrew Cagney]

Hello,

At present the selected and current frame are maintained as single 
globals, and independant of the selected and current thread.  As a 
consequence, each time GDB switches between threads, all global frame 
state is flushed.

I'm intending to add a "current frame" and "selected frame" to 
"thread_info" so that, instead this can be maintained on a per-thread basis.

The tricky one is the sentinel-frame.  It needs to be able to perform an 
arbitrary projection of the virtual thread's register onto the target 
below's physical threads and memory.   I think this suggests a 
sentinel-frame parameterized by target, and not just the current regcache.

Thoughts?
Andrew

Dwarf information about a symbol

[ankit thukral]

hi all,  
    this is regarding the dwarf information regarding
a variable (which is in struct symbol in the following
field : symbol.aux_value.loc.baton.data  ).can this
information change over different stages in the
process? for instance,if a variable ,which is in a
register during early stages of the program,ceases to
be in the register (due to less usage) and is stored
in memory,then the symbol Dwarf information should
change from DW_OP_regx to
DW_OP_fbreg.
     i am not very sure whether my knowledge about the
compilation process (gcc , of course) is correct to
this end.

thanks in advance,
ankit.

__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com

Re: Dwarf information about a symbol

[Keith Walker]

At 01:26 15/10/2003 -0700, ankit thukral wrote:

>for instance,if a variable ,which is in a
>register during early stages of the program,ceases to
>be in the register (due to less usage) and is stored
>in memory,then the symbol Dwarf information should
>change from DW_OP_regx to
>DW_OP_fbreg.

Yes this can be described in DWARF-2 (and DWARF-3)

The actual location (ie. the register, memory address, etc) is described by 
a Location Expression.     This is sufficient to describe an item if it's 
location does not vary.

The ability to vary the location of an item is then described by a Location 
List.    A Location List is a list of <PC address range and associated 
Location Expression>.     Using a Location List therefore allows the 
actual  location to vary depending on the current PC value.

Support for Location Lists has only recently been implemented and made 
available in gdb 6.0

Obviously this does rely on the compiler generating the relevant Location 
List information in the first place for the debugger to use.

Keith


Keith Walker           Tel:+44 (1628) 427732
ARM Ltd, Liberty House, Moorbridge Road, Maidenhead, SL6 8LT UK

This e-mail message is intended for the addressee(s) only and may contain 
information that is the property of, and/or subject to a confidentiality 
agreement between the intended recipient(s), their organisation and/or the 
ARM Group of Companies. If you are not an intended recipient of this e-mail 
message, you should not read, copy, forward or otherwise distribute or 
further disclose the information in it; misuse of the contents of this 
e-mail message may violate various laws in your state, country or 
jurisdiction. If you have received this e-mail message in error, please 
contact the originator of this e-mail message via e-mail and delete all 
copies of this message from your computer or network, thank you.

Re: Dwarf information about a symbol

[Daniel Jacobowitz]

On Wed, Oct 15, 2003 at 01:26:57AM -0700, ankit thukral wrote:
> hi all,  
>     this is regarding the dwarf information regarding
> a variable (which is in struct symbol in the following
> field : symbol.aux_value.loc.baton.data  ).can this
> information change over different stages in the
> process? for instance,if a variable ,which is in a
> register during early stages of the program,ceases to
> be in the register (due to less usage) and is stored
> in memory,then the symbol Dwarf information should
> change from DW_OP_regx to
> DW_OP_fbreg.
>      i am not very sure whether my knowledge about the
> compilation process (gcc , of course) is correct to
> this end.

To add to Keith's answer:
  - loc.baton.data will _not_ change.  loc.baton.data may point to a
list of different locations, however.

  - current gcc only occasionally generates location lists.  It may be
3.5 before they're really available.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer