This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: [RFC] Add windows Thread Information Block



> -----Message d'origine-----
> De?: gdb-patches-owner@sourceware.org [mailto:gdb-patches-
> owner@sourceware.org] De la part de Daniel Jacobowitz
> Envoyé?: Friday, June 26, 2009 5:53 PM
> À?: Pierre Muller
> Cc?: gdb-patches@sourceware.org
> Objet?: Re: [RFC] Add windows Thread Information Block
> 
> On Fri, Jun 26, 2009 at 01:47:31AM +0200, Pierre Muller wrote:
> >  - Current limits of stack
> >   The last could be particularly interesting when we try to
> >  to figure out an optimized stack frame.
> >
> >   When we hit a frameless function without debug information,
> > we could try to find up the stack a valid pair of stored (EBP,EIP)
> > of the outer frame having a frame pointer.
> >   Testing for EBP to bee within the limits given by
> >   current_top_of_stack andcurrent_bottom_of_stack
> > would help to find correct pairs.
> 
> Does Windows allow separate stacks, a la sigaltstack?  Or is the stack
> always guaranteed to be within this range?

  Each thread has its own stack with limits that are
given in these two fields (the lower limit can be
extended as needed by the OS).
 
> >   But here I need advice on how to move the display_tib function
> > to windows-tdep.c file, as it is currently using internal information
> > of windows-nat.c thread_info struct.
> >   Also how should I handle the remote case?
> > Should I add a new query, something like 'qTlb'?
> > How should I call this from windows-tdep code?
> 
> You'd probably want a new 'target object' for this, and a qXfer packet
> to read it.  Take a look at "info auxv", which is very similar.

  Is it OK, to add a target method that is only supported by one
specific target?
 
> You might also want to consider treating this like $_siginfo.  It's
> fine to also have an info command to display it, but I bet folks'll
> want to examine memory at some of these addresses or write scripts
> using them, so having it as a normal "struct value" would help.
> _siginfo is implemented using a target object, too.


  Would you mean something like $_tib
to be able to use it in scripts?
  Sounds like a good idea.

Pierre


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]