[PATCH] More updates to FXSR/SSE support in 2.4.0-test1

[PATCH] More updates to FXSR/SSE support in 2.4.0-test1

[Gareth Hughes]

[-- Attachment #1: Type: text/plain, Size: 1590 bytes --]

Here's a copy of my latest work, this time kernel and glibc headers
only.  I'm still working on updating GDB, as incorporating Mark's
suggestions leads to some problems with the stock 5.0 code (mainly in
the interpretation of the FPU tag word).

What are we doing now?

We use FXSAVE/FXRSTOR only to save and restore the FPU context as
before.  Nice and fast.  As always, the FPU state is only saved when the
FPU is used and restored with an #NM exception.

We (correctly) convert the FXSR-format data into the expanded signal
context, and include the original FXSR-format data like before.  This
includes doing a full conversion between tag word formats.

We (correctly) convert the FXSR-format data on the
PTRACE_[GET|SET]FPREGS requests.

We just use the 512-byte FXSR data on PTRACE_[GET|SET]XFPREGS requests. 
This requires updates to GDB, which I'm working on now.  Nothing major,
the code is the same as in the kernel.

The tag word conversion originally seen in 2.4.0-test1 was almost
correct, but this code does a more thorough job - important for GDB 5.0
correctness.

As always, please let me know if you have any grievances.  Doing the
conversion turned out to be a lot less ugly than I had imagined, and as
we only need to do it for signals, ptracing and dumping core, it doesn't
affect things too greatly.  I will add in the core dumping support when
the work in this patch gets applied (in whatever form).

The signal handler test from my previous email will still work, and I
encourage you to verify this.

-- Gareth
patch-2.4.0test1-ac12-gth2.gz
patch-glibc-2.1.3-gth2.gz


[-- Attachment #2: patch-2.4.0test1-ac12-gth2.gz --]
[-- Type: application/x-gzip, Size: 4084 bytes --]

[-- Attachment #3: patch-glibc-2.1.3-gth2.gz --]
[-- Type: application/x-gzip, Size: 1453 bytes --]

Re: [PATCH] More updates to FXSR/SSE support in 2.4.0-test1

[Gareth Hughes]

Mark Kettenis wrote:
> 
>    Date: Sun, 11 Jun 2000 18:03:41 -0600
>    From: Gareth Hughes <gareth@precisioninsight.com>
> 
>    Here's a copy of my latest work, this time kernel and glibc headers
>    only.  I'm still working on updating GDB, as incorporating Mark's
>    suggestions leads to some problems with the stock 5.0 code (mainly in
>    the interpretation of the FPU tag word).
> 
> Looks much better :-).  I didn't realize there were tag word problems
> until yesterday :-(.  If this means that stock GDB 5.0 won't work
> anymore, so be it.  A sane kernel interface is more important.

I agree.  I'm happy with this as it's correct, fast *and* backward
compatible.  Thanks again everyone for pulling me up on the third point
:-)

> What exactly happens if you try to compile stock GDB 5.0 with the new
> kernel?  Does it compile at all?  Is it seriously crippled?  Or does
> it basically work right?

It works (kind of), it's just extracting the FPU register data
incorrectly and then misinterpreting the tag word and thus
incorrectlying interpreting the incorrect data :-).  It's a pretty
trivial patch, the extraction fix is contained in my last patch and I've
just got to copy the tag word conversion code across.  Should have a
patch in a couple of hours - busy with work at the moment.

> If there are major problems, it might be wise to choose a different
> name for the PTRACE_{GET,SET}XFPREGS requests to avoid confusion.
> That way, nobody will end up with a non-functional GDB (of course the
> blame lies entirely with the GDB team for this mess).  My suggestion
> would be to call those requests PTRACE_{GET,SET}FPXREGS.  It turns out
> that Unixware uses a similar name for its FXSR support (they don't
> have ptrace(), but they have a PCSFPXREG ioctl() and a __fpxregset_t
> type[1]).  Moreover this makes the FSAVE/FPREGS vs. FXSAVE/FPXREGS
> analogy a bit more explicit.

I like this idea, makes a whole lot more sense.  This is kinda what I
was arguing for way back in our previous emails.  It also matches up
nicely with the signal handling types I've declared.  It would be good
to get a working GDB 5.0 with a patch rather than a broken one when you
haven't patched it.  The standard PTRACE_{GET|SET}FPREGS works fine as
it stands, and in many cases this will be good enough.  When is the next
release of GDB planned for?

I'd like some clarification on core dumping - will it be okay to add a
new note NT_PRFPXREG, a new elf type elf_fpxregset_t and so on?  If so,
I'll add this to the kernel and my GDB 5.0 patch and fire it off today.

-- Gareth
From ac131313@cygnus.com Mon Jun 12 02:04:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: jtc@redback.com
Cc: gdb@sourceware.cygnus.com
Subject: Re: memory regions, dcache
Date: Mon, 12 Jun 2000 02:04:00 -0000
Message-id: <3944A778.74396B73@cygnus.com>
References: <5mk8fyvfzy.fsf@jtc.redback.com>
X-SW-Source: 2000-06/msg00087.html
Content-length: 6109

"J.T. Conklin" wrote:
> 
> Setting aside symbol table performance for the moment, I'm back
> finishing up memory region attributes.
> 
> In previous messages, I've shared my changes to target_xfer_memory().
> Those have not changed significantly.  Since that time, I've added a
> 'mem_attrib *attrib' argument to the target vectors to_xfer_memory()
> function, and have fixed up all the code for all the targets.  While I
> was there, I noticed that some target's *_xfer_memory() function did
> not declare the 'struct target_ops *target' argument, so I fixed that
> up at the same time.  (Btw, Are there any *_xfer_memory() functions
> that use the 'target' argument?  I didn't see any while I was adding
> the new argument, but I wasn't looking for it either.  If nothing uses
> it, I wouldn't mind removing it as part of this change.)

I think, long term, the target will need to be a parameter to every
target method.

If GDB ever does find its self with two active target vectors then this
will become an issue.
However, in the mean time ....

> Now that the mem_attrib argument is available, target *_xfer_memory()
> functions may be able to tailor their behavior accordingly.  I say
> 'may be able' because currently most of the functions simply ignore
> the new arguement (either because the function has not been changed to
> use the attribute, or perhaps because the host/target interface/
> protocol cannot support the attribute(s) selected.  Is there anything
> I should do about this now, or is the fact that some attributes are
> not supported on all targets a given that just needs to be documented?

If a user sets (pick a random attribute) the atomic attribute (see next
paragraph) but the target doesn't support it shouldn't the user be told
that the attribute was ignored?  I think it is important to not mis-lead
the user with this.

(By atomic I mean read/write a word as a word and not as a sequence of
bytes - assuming that is a possible attribute.  On some targets a word
read (arm?) returns a different value to a byte read).

> In most of the embedded remote targets, the target vector code calls
> dcache_init() in the *_open() function to register functions used to
> read and write memory, and the *_xfer_memory() functions calls
> dcache_xfer_memory() which uses the functions registered earlier to
> perform the I/O.  The problem is that there is no way to pass the
> attribute argument through dcache to the functions.
> 
> This should be fairly easy to address --- just a lot of grunt work
> fixing up dcache_xfer_memory() and the read and write functions to
> take the new argument.  However, I wonder whether it would be better
> (cleaner, more "elegant", etc.) to move dcache up a layer and put it
> between target_xfer_memory() and the target *_xfer_memory() functions.
> 
> For example, instead of calling a target vector's *to_xfer_memory(),
> target_xfer_memory() would call dcache_xfer_memory() with a target
> vector pointer.  If dcache_xfer_memory() had to do i/o, it would call
> the target vector's *to_xfer_memory() function.

I think the elegant solution is preferable (but as you ask, is it
feasible?).

> Having the dcache at a higher level might be useful for implementing
> the verify (read and compare after writes) attribute.  As I imagine
> things, verify support would be implemented in target_xfer_memory()
> and would re-read and compare after a write.  But if the target code
> uses dcache, the read would not come from the target but the cache.
> On the other hand, target_xfer_memory() could do a cache invalidate
> before reading (and a more refined cache invalidate could easily be
> written).
> 
> All that being said, I think that going the simple route and adding
> the parameter to dcache_xfer_memory() and to the target read/write
> functions may be the right thing for now.  It won't be difficult to
> re-evaluate this decision and go for the more integrated approch if
> that turns out to be the right thing over time.

Everytime something in the target makes a call back into the guts of
GDB, the problem of implementing things like gdbserver become just that
bit harder.  The less things the target tries to do the better.

With this in mind, have you considered a more incremental approach:

	o	add a new memory read/write method
		that has the interface you desire.

	o	have the new dcache use that interface

	o	provide a simple default implementation
		of the new method that uses the old
		interface.

This should give you the freedom to ``get it working'' using the main
repository and then people can fix their target  (Or I'll get Stan to
obsolete it :-).

It would also make dcache available to native targets.

The comment:

/* NOTE: cagney/1999-10-18: This function (and its siblings in other
   remote targets) shouldn't attempt to read the entire buffer.
   Instead it should read a single packet worth of data and then
   return the byte size of that packet to the caller.  The caller (its
   caller and its callers caller ;-) already contains code for
   handling partial reads. */

is relevant here.

[There is another issue lurking here, rather then raise it I'll start a
new thread]

> One more thing before this gets too long.  There is a remotecache
> variable that globally enables the cache which is currently disabled.
> With attributes, each memory region has a cache/nocache atttribute.
> Should the remotecache variable override the attribute.  Or can we
> depricate remotecache completely?  Since when no memory attributes
> are defined the default attribute is used which disables the cache,
> there isn't much need for a global flag any more.

You mean delete the command :-)

FYI, things have changed a little - its now the static variable
dcache.c:dcache_enabled_p and wince.c sets it using
dcache.c:set_dcache_state(1).

I think the command (but not the global variable) would need to be
around for at least one more release.
Can it be converted into a recursive call to the CLI with a command that
enables/disables all memory regions?  However, is there any evidence
that people actually use it?

	Andrew
From ac131313@cygnus.com Mon Jun 12 03:13:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: GDB Discussion <gdb@sourceware.cygnus.com>, "Insight (GDB GUI)" <insight@sourceware.cygnus.com>
Subject: non-blocking reads/writes and event loops
Date: Mon, 12 Jun 2000 03:13:00 -0000
Message-id: <3944B786.A16E9A2F@cygnus.com>
X-SW-Source: 2000-06/msg00088.html
Content-length: 2596

Hello,

[this is a cross post, reply-to has been set to gdb@sourceware]

Two architectural changes introduced in 5.0 were the the event-loop and
the targets ``remote async'' and ``remote extended-async''.  J.T.'s
recent posting about memory read/write raises a second significant issue
related to the event-loops, GUI's and async but first some background.

The event-loop provides a mechanism that allows GDB to block on more
than one input (or output) source.  For instance, GDB might be blocked
waiting for both the remote target and the user input.  As events
arrive, the event-loop dispatches them.

The async/extended-async targets exploit the event-loop so that, while
the target is running, the user can still enter various commands.  For
instance:

	(gdb) target extended-async ....
	(gdb) run&
	(gdb)
	(gdb) help ...
	....
	(gdb) 
	Breakpoint #1 reached, ...
	(gdb)

In getting this working, numerous problems were identified and several
compromizes were made (look for FIXMEs, especially in remote.c).

The main compromize is to do with when the target has halted.  While the
target is running the async target code returns control to the main
event-loop.  When the target starts ending it stopped packet, or when
the target is assumed to be halted, the code revers to polling.  Memory
reads/writes and the like are blocking operations - they do not return
control to the event loop.  For instance:

	(gdb) print foo

	gdb calls target-vector to read memory (&foo, sizeof(foo))
		target-vector ``calls'' remote to read memory from &foo
		target-vector blocks
		target-vector receives data from remote
	gdb receives data from target-vector
	
	$1 = "foo"		
	(gdb)

The rationale behind the decision to block in this case was very
pragmatic - it wasn't going to be feasible to invert (as was done to
serial.c) all of GDB (so that everything was event based) in a single
hit.

The consequence is that, during these blockages, GDB is slower than
dring normal operation - for the CLI the problem isn't too noticable. 
For the GUI, however, it is very noticable.  As a result, the built in
GUI (ex insight) is forced to use other means to avoid this slugishness
- during those blocked reads a timer is set up and that is used to
process the GUI events (see ui_loop_hook() and
gdb/gdbtk/generic/gdbtk-hooks.c:x_event()).

The thing that needs to be decided is how far GDB should be pushed to
address this problem.  Should GDB continue to be pushed to the point
where everything is event based or should, the current compromise remain
where a GUI is unable to exploit GDBs event-loop.

	Andrew
From ac131313@cygnus.com Mon Jun 12 04:15:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: GDB Discussion <gdb@sourceware.cygnus.com>
Subject: That vision thing ...
Date: Mon, 12 Jun 2000 04:15:00 -0000
Message-id: <3944C636.7C8EF242@cygnus.com>
X-SW-Source: 2000-06/msg00089.html
Content-length: 1747

(If you know something about Australian politics ``The Vision Thing'' is
a backhanded slap at someone that that has no sense of vision :-)

Hello,

For the curious :-) Where next.

Firstly, there is always the ongoing and important need to improve
things like language support (namely C++), symbol-table performance,
native threads, code cleanups, bug fixes and the like.  I believe that
that there is now plenty active and ongoing development in these area. 
Me giving opinions on it would just be distracting.

I also think that these ongoing developments are going to be the
principal factors that determine the time frame for each succeeding GDB
release.  They are also the things that attract the most attention and
also get the most praise :-)

Longer term I can see two significant developments:

	o	libgdb

		The basic motivation is the desire
		to make it easier (and more robust) to
		integrate GDB into a GUI.

		Here the first step is MI (along with
		ui-out/ui-file).

	o	multi-arch et al.

		Here the objective is to remove
		the assumption that GDB has, at any
		time, just one thread/language/isa
		/abi/vm/target/....  The motivation
		being to make it possible for GDB to
		handle complex targets that contain
		multiple architectures and the like.

		Here that first step is multi-arch.

So?

I'd just like to encourage people to pursue what they are currently
working on.  Just keep in mind that there is likely to be more
significant change (especially through multi-arch) lurking in the
background.  For my part I hope to be concentrating on mult-arch et al,
however, I will most likely occasionally prod libgdb.

As with any bit of open source, there is of course, no timeframe ...

Comments, fits of laughter, ...

	Andrew
From eliz@delorie.com Mon Jun 12 05:46:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: fnasser@cygnus.com
Cc: kettenis@wins.uva.nl, gdb@sourceware.cygnus.com, nsd@cygnus.com, Peter.Schauer@regent.e-technik.tu-muenchen.de, rjl@sco.com, cgf@cygnus.com, jtc@redback.com, jimb@cygnus.com
Subject: Re: i386 debugging registers
Date: Mon, 12 Jun 2000 05:46:00 -0000
Message-id: <200006121246.IAA24337@indy.delorie.com>
References: <200006112322.e5BNM6513971@delius.kettenis.local> <3944218C.6FAAA98A@cygnus.com>
X-SW-Source: 2000-06/msg00090.html
Content-length: 704

> Date: Sun, 11 Jun 2000 23:32:28 +0000
> From: Fernando Nasser <fnasser@cygnus.com>
> 
> I can see one situation where one may want to look at or set
> debugger registers: when debugging a debugger's hardware breakpoint
> support.

Yes, definitely.  I found myself doing that a lot when I enhanced the
hardware watchpoint/breakpoint support in go32-nat.c (you will see in
the sources an #ifdef'ed away fragment which, if $GDB_SHOW_DR is set
in the environment, causes go32-nat.c to print current values of debug
registers).

> We can add a maintenance command to access that.  That is what maintenance 
> commands are for.

I agree: a maint command that prints the debug registers would be very
useful.
From qqi@world.std.com Mon Jun 12 08:00:00 2000
From: Quality Quorum <qqi@world.std.com>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: GDB Discussion <gdb@sourceware.cygnus.com>
Subject: Re: That vision thing ...
Date: Mon, 12 Jun 2000 08:00:00 -0000
Message-id: <Pine.SGI.3.95.1000612105649.19388F-100000@world.std.com>
References: <3944C636.7C8EF242@cygnus.com>
X-SW-Source: 2000-06/msg00091.html
Content-length: 1984

On Mon, 12 Jun 2000, Andrew Cagney wrote:

> (If you know something about Australian politics ``The Vision Thing'' is
> a backhanded slap at someone that that has no sense of vision :-)
> 
> Hello,
> 
> For the curious :-) Where next.
> 
> Firstly, there is always the ongoing and important need to improve
> things like language support (namely C++), symbol-table performance,
> native threads, code cleanups, bug fixes and the like.  I believe that
> that there is now plenty active and ongoing development in these area. 
> Me giving opinions on it would just be distracting.
> 
> I also think that these ongoing developments are going to be the
> principal factors that determine the time frame for each succeeding GDB
> release.  They are also the things that attract the most attention and
> also get the most praise :-)
> 
> Longer term I can see two significant developments:
> 
> 	o	libgdb
> 
> 		The basic motivation is the desire
> 		to make it easier (and more robust) to
> 		integrate GDB into a GUI.
> 
> 		Here the first step is MI (along with
> 		ui-out/ui-file).
> 
> 	o	multi-arch et al.
> 
> 		Here the objective is to remove
> 		the assumption that GDB has, at any
> 		time, just one thread/language/isa
> 		/abi/vm/target/....  The motivation
> 		being to make it possible for GDB to
> 		handle complex targets that contain
> 		multiple architectures and the like.
> 
> 		Here that first step is multi-arch.
> 
> So?
> 
> I'd just like to encourage people to pursue what they are currently
> working on.  Just keep in mind that there is likely to be more
> significant change (especially through multi-arch) lurking in the
> background.  For my part I hope to be concentrating on mult-arch et al,
> however, I will most likely occasionally prod libgdb.
> 
> As with any bit of open source, there is of course, no timeframe ...
> 
> Comments, fits of laughter, ...

Can we split target depended pieces into subdirs under gdb ?

> 
> 	Andrew
> 

Thanks,

Aleksey

Re: [PATCH] More updates to FXSR/SSE support in 2.4.0-test1

[Mark Kettenis]

   Date: Mon, 12 Jun 2000 14:56:27 -0600
   From: Gareth Hughes <gareth@precisioninsight.com>

   > What exactly happens if you try to compile stock GDB 5.0 with the new
   > kernel?  Does it compile at all?  Is it seriously crippled?  Or does
   > it basically work right?

   It works (kind of), it's just extracting the FPU register data
   incorrectly and then misinterpreting the tag word and thus
   incorrectlying interpreting the incorrect data :-).  It's a pretty
   trivial patch, the extraction fix is contained in my last patch and I've
   just got to copy the tag word conversion code across.  Should have a
   patch in a couple of hours - busy with work at the moment.

Don't put too much effort into it.  I'm going to add some routines to
GDB that do the conversion from an FXSAVE area to GDB's internal
format that can be reused for other i386 targets besides Linux.

   > If there are major problems, it might be wise to choose a different
   > name for the PTRACE_{GET,SET}XFPREGS requests to avoid confusion.
   > That way, nobody will end up with a non-functional GDB (of course the
   > blame lies entirely with the GDB team for this mess).  My suggestion
   > would be to call those requests PTRACE_{GET,SET}FPXREGS.  It turns out
   > that Unixware uses a similar name for its FXSR support (they don't
   > have ptrace(), but they have a PCSFPXREG ioctl() and a __fpxregset_t
   > type[1]).  Moreover this makes the FSAVE/FPREGS vs. FXSAVE/FPXREGS
   > analogy a bit more explicit.

   I like this idea, makes a whole lot more sense.  This is kinda what I
   was arguing for way back in our previous emails.  It also matches up
   nicely with the signal handling types I've declared.  It would be good
   to get a working GDB 5.0 with a patch rather than a broken one when you
   haven't patched it.  The standard PTRACE_{GET|SET}FPREGS works fine as
   it stands, and in many cases this will be good enough.  When is the next
   release of GDB planned for?

I believe a new release cycle will be started in July, which should
lead to GDB 5.1 somewhere in November.

   I'd like some clarification on core dumping - will it be okay to add a
   new note NT_PRFPXREG, a new elf type elf_fpxregset_t and so on?  If so,
   I'll add this to the kernel and my GDB 5.0 patch and fire it off today.

Yep, that would be fine.  You'll have to choose a name for the note
too.  The other notes have the name "CORE", which is also used by
other SVR4-derived systems.  In that case you'd have to make sure that
NT_PRFPXREG doesn't clash with types that are already in use.  It's
probably better to choose a different name.  There are no rules but
the System V ABI suggests using the name of the vendor.  The old SSE
support uses "LINUX", which isn't such a bad idea (there is no reason
to choose a different name).  You can pick any number for NT_PRFPXREG,
but choosing one that's not already used in libbfd makes life a bit
easier.

Right now we have (see include/elf/common.h in the GDB/binutils
distribution):

#define NT_PRSTATUS	1		/* Contains copy of prstatus struct */
#define NT_FPREGSET	2		/* Contains copy of fpregset struct */
#define NT_PRPSINFO	3		/* Contains copy of prpsinfo struct */
#define NT_TASKSTRUCT	4		/* Contains copy of task struct */
#define NT_PRXFPREG     0x46e62b7f	/* Contains a user_xfpregs_struct; */
					/*   note name must be "LINUX".  */

/* Note segments for core files on dir-style procfs systems. */

#define NT_PSTATUS	10		/* Has a struct pstatus */
#define NT_FPREGS	12		/* Has a struct fpregset */
#define NT_PSINFO	13		/* Has a struct psinfo */
#define NT_LWPSTATUS	16		/* Has a struct lwpstatus_t */
#define NT_LWPSINFO	17		/* Has a struct lwpsinfo_t */
#define NT_WIN32PSTATUS	18		/* Has a struct win32_pstatus */


Where obviously NT_PRXFPREG will dissapear.


Solaris has (see /usr/include/sys/elf.h):

#define NT_PRSTATUS     1       /* prstatus_t   <sys/old_procfs.h>      */
#define NT_PRFPREG      2       /* prfpregset_t <sys/old_procfs.h>      */
#define NT_PRPSINFO     3       /* prpsinfo_t   <sys/old_procfs.h>      */
#define NT_PRXREG       4       /* prxregset_t  <sys/procfs.h>          */
#define NT_PLATFORM     5       /* string from sysinfo(SI_PLATFORM)     */
#define NT_AUXV         6       /* auxv_t array <sys/auxv.h>            */
#define NT_GWINDOWS     7       /* gwindows_t   SPARC only              */
#define NT_ASRS         8       /* asrset_t     SPARC V9 only           */
#define NT_PSTATUS      10      /* pstatus_t    <sys/procfs.h>          */
#define NT_PSINFO       13      /* psinfo_t     <sys/procfs.h>          */
#define NT_PRCRED       14      /* prcred_t     <sys/procfs.h>          */
#define NT_UTSNAME      15      /* struct utsname <sys/utsname.h>       */
#define NT_LWPSTATUS    16      /* lwpstatus_t  <sys/procfs.h>          */
#define NT_LWPSINFO     17      /* lwpsinfo_t   <sys/procfs.h>          */


Pick a number, and I'll make sure the necessary support will be added
to libbfd and GDB.

Mark
From qqi@world.std.com Mon Jun 12 15:00:00 2000
From: Quality Quorum <qqi@world.std.com>
To: Fernando Nasser <fnasser@cygnus.com>
Cc: Andrew Cagney <ac131313@cygnus.com>, GDB Discussion <gdb@sourceware.cygnus.com>
Subject: Re: That vision thing ...
Date: Mon, 12 Jun 2000 15:00:00 -0000
Message-id: <Pine.SGI.3.95.1000612175947.11397A-100000@world.std.com>
References: <39450292.1B40EBB5@cygnus.com>
X-SW-Source: 2000-06/msg00095.html
Content-length: 962

On Mon, 12 Jun 2000, Fernando Nasser wrote:

> Quality Quorum wrote:
> > 
> > Can we split target depended pieces into subdirs under gdb ?
> > 
> 
> Aleksey,
> 
> For the majority of the targets we have only a single target dependent file.
> So most of these subdirectories will have a single file in it.  The exceptions
> would be few.
> 
> But a nice variant from your idea it would be a "targetdep" subdirectory for all
> these files.  This would reduce the large number of files under src/gdb and
> group together all that is related to different targets.  It still looks nice
> even with multi-arch I think.
> 
> We can continue on that line and group all those remote-* files as well...

It sounds nice.

> 
> -- 
> Fernando Nasser
> Red Hat Canada Ltd.                     E-Mail:  fnasser@cygnus.com
> 2323 Yonge Street, Suite #300           Tel:  416-482-2661 ext. 311
> Toronto, Ontario   M4P 2C9              Fax:  416-482-6299
> 

Thanks,

Aleksey