[Q] Accessing fs:0 on x86 Linux?

[Q] Accessing fs:0 on x86 Linux?

[Robert Baruch]

Hi all,

I'm trying to debug something in wine on an x86 Linux box. It requires 
looking at what is stored in memory starting at fs:0. I've searched all 
over for how to do this, but I've only seen one thread that seems to 
indicate that it can't be done.

Can anyone confirm or deny this?

Thanks,

--Rob

Re: [Q] Accessing fs:0 on x86 Linux?

[Pierre Muller]

At 01:51 14/12/2001 , Robert Baruch a écrit:
>Hi all,
>
>I'm trying to debug something in wine on an x86 Linux box. It requires looking at what is stored in memory starting at fs:0. I've searched all over for how to do this, but I've only seen one thread that seems to indicate that it can't be done.

Its not possible with the current GDB.

>Can anyone confirm or deny this?

  But I once announced that I had a tool that is able to do this on
the go32v2 target.
See
http://sources.redhat.com/ml/gdb/2000-q1/msg00515.html
and related thread.

  This was never really considered for insertion into GDB CVS...
Eli, there was no followup to your answer
http://sources.redhat.com/ml/gdb/2000-q1/msg00535.html
????

   On that target, its rather easy, as the debugger and debuggee share the same local descriptors.
  It should also be possible to do this on cygwin target.
We would need to use GetThreadSelectorEntry
win32 API function to get
the linear base  address of the %fs selector.
   This function is not called in current xwin32-nat.c code and this only works
because win32 kernel does give a zero linear base address to the 
ordinary code and data selector (value of %cs for code , %ds, %es and %ss for data selector).

   Regarding wine on linux, this really depends on how wine does set the %fs selector 
base and size, I have no idea how this is done...


Pierre Muller
Institut Charles Sadron
6,rue Boussingault
F 67083 STRASBOURG CEDEX (France)
mailto:muller@ics.u-strasbg.fr
Phone : (33)-3-88-41-40-07  Fax : (33)-3-88-41-40-99

Re: [Q] Accessing fs:0 on x86 Linux?

[Robert Baruch]

Hi Pierre,



>    On that target, its rather easy, as the debugger and debuggee share the same local descriptors.
>   It should also be possible to do this on cygwin target.
> We would need to use GetThreadSelectorEntry
> win32 API function to get
> the linear base  address of the %fs selector.
>    This function is not called in current xwin32-nat.c code and this only works
> because win32 kernel does give a zero linear base address to the 
> ordinary code and data selector (value of %cs for code , %ds, %es and %ss for data selector).


True, but I'm more concerned about how to do this on Linux, since it 
uses a flat memory model.


> 
>    Regarding wine on linux, this really depends on how wine does set the %fs selector 
> base and size, I have no idea how this is done...


Here's the code from Wine which gets some %fs data for an i386 platform.

#if defined(__i386__) && defined(__GNUC__)
extern inline struct _TEB WINAPI *NtCurrentTeb(void);
extern inline struct _TEB WINAPI *NtCurrentTeb(void)
{
     struct _TEB *teb;
     __asm__(".byte 0x64\n\tmovl (0x18),%0" : "=r" (teb));
     return teb;
}
#else
extern struct _TEB WINAPI *NtCurrentTeb(void);
#endif

This is the corresponding disassembly from gdb:

0x400911e2 <task_start+18>:     mov    %fs:0x18,%esi

So basically it uses inline assembly to manually get fs data.

--Rob

Re: [Q] Accessing fs:0 on x86 Linux?

[Eli Zaretskii]

> Date: Fri, 14 Dec 2001 09:36:27 +0100
> From: Pierre Muller <muller@cerbere.u-strasbg.fr>
> 
>   But I once announced that I had a tool that is able to do this on
> the go32v2 target.
> See
> http://sources.redhat.com/ml/gdb/2000-q1/msg00515.html
> and related thread.
> 
>   This was never really considered for insertion into GDB CVS...
> Eli, there was no followup to your answer
> http://sources.redhat.com/ml/gdb/2000-q1/msg00535.html
> ????

I looked into this issue when GDB 5.1 was in the last stages of
development, but eventually decided that GDB lacked some
infrastructure to add such a functionality.  You could find the
traces of that in a thread "Re: 8 bit read"; start reading here:

 http://sources.redhat.com/ml/gdb/2001-07/msg00338.html

The problem with your patches was that they only worked for a single
command, an analog of the `x' command.  What I'm looking for is a
general feature which would allow memory references using a
selector:offset pair to be used in _any_ expression you submit to GDB.
GDB cannot do that currently, and I don't think it would be right for
me to hack every GDB command out there with "#ifdef __DJGPP__" type of
code.

So I have no alternative but to reject your patches.  Sorry.

A work-around would be to write a simple function that would do the
fetching of data via a selector other than DS, and then call that
function from GDB.  Depending on your needs, you could get away with
the _farpeek* family that is already available in the DJGPP library.

Re: [Q] Accessing fs:0 on x86 Linux?

[Andrew Cagney]

> I looked into this issue when GDB 5.1 was in the last stages of
> development, but eventually decided that GDB lacked some
> infrastructure to add such a functionality.  You could find the
> traces of that in a thread "Re: 8 bit read"; start reading here:
> 
>  http://sources.redhat.com/ml/gdb/2001-07/msg00338.html


Can I suggest playing with the @<blah> prefix operator that Michael 
Snyder recently added.

It added a framework for specifying something like ``(int @code *)0''. 
This indicates a pointer in the code space.  The intent is for the 
mechanism to be extended to support more than just code and data spaces.

An initial pass at this would have:

	(@fs*)0

One possible follow-on would be to change $fs's type to ``(uint8 @fs 
*)'' so that ``x/b $fs + 5'' did the right thing.

I should note that the current implementation is restricted to just 
@code and @data so some ground work would be needed.

Andrew

Re: [Q] Accessing fs:0 on x86 Linux?

[Eli Zaretskii]

On Sat, 15 Dec 2001, Andrew Cagney wrote:

> Can I suggest playing with the @<blah> prefix operator that Michael 
> Snyder recently added.

Thanks, I will look into this when I have time.