* Re: [remote] Make registers network byteordered?
[not found] <3A2C4305.6D9E53B3@cygnus.com>
2000-12-05 13:03 ` Frank Ch. Eigler
@ 2000-12-05 14:34 ` Jim Blandy
[not found] ` <3A2D84F3.48F372E@cygnus.com>
2000-12-07 12:53 ` J.T. Conklin
2 siblings, 1 reply; 5+ messages in thread
From: Jim Blandy @ 2000-12-05 14:34 UTC (permalink / raw)
To: Andrew Cagney; +Cc: GDB Discussion
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 8101 bytes --]
Andrew Cagney <ac131313@cygnus.com> writes:
>
> Hello,
>
> At present the target sends back registers in target byte order format
> vis:
>
> T0525:c4060280ffffffff;1d:c0ffff81ffffffff;
>
> I'd like to think about a tweek to this part of the protocol so that the
> format:
>
> T0525=ffffffff80020664;1d=ffffffff81ffffc0;
>
> is accepted. The thing I can't figure out is now to also change the
> [pP] packets so that GDB can correctly detect targets that support this
> format when writing registers.
>
> General comments?
What's the point? Simply that registers don't have an endianness?
From jtc@redback.com Tue Dec 05 15:24:00 2000
From: jtc@redback.com (J.T. Conklin)
To: Andrew Cagney <ac131313@cygnus.com>
Cc: GDB Discussion <gdb@sourceware.cygnus.com>
Subject: Re: SOFTWARE_SINGLE_STEP_P and multi-arch
Date: Tue, 05 Dec 2000 15:24:00 -0000
Message-id: <5mk89ezc2o.fsf@jtc.redback.com>
References: <3A2C4141.B3C2F486@cygnus.com>
X-SW-Source: 2000-12/msg00026.html
Content-length: 1920
>>>>> "Andrew" == Andrew Cagney <ac131313@cygnus.com> writes:
Andrew> At present there are two macros that control software stepping:
Andrew>
Andrew> SOFTWARE_SINGLE_STEP_P()
Andrew>
Andrew> and SOFTWARE_SINGLE_STEP(sig, insert_or_remove)
Andrew>
Andrew> I'd like to suggest the following:
Andrew>
Andrew> Rename SOFTWARE_SINGLE_STEP_P() to TARGET_SOFTWARE_SINGLE_STEP_P() and
Andrew> add it to the *target* vector.
You're correct that hardware single step support is target dependent.
For example, SOFTWARE_SINGLE_STEP_P is 1 on the sparc (and thus the
embedded sparc varients like the sparclite and sparclet), but single
step performance using the remote protocol would be greatly improved
if the stub managed the step internally. While not strictly a hard-
ware single step, it acts more or less the same. Perhaps the names
SOFTWARE_SINGLE_STEP_P and SOFTWARE_SINGLE_STEP() should be changed
to something more appropriate? I can't think of anything off hand.
One concern I have is that it may not be known whether a target
supports "hardware" single step until it is attempts one. Using the
above examples of the sparclite and sparclet, older stubs won't have
support for the step command packet. I can't think of a good way to
determine ahead of time whether the packet is supported. GDB won't
know whether it's OK to use it until it's too late.
Perhaps this indicates we should be taking another approach. This is
not completely thought out, feel free to shoot holes in it. The step
function would be split out of target_resume() into a new vector
function target_step(). GDB would unconditionally call target_step(),
if it fails with an error code indicating that hardware single step is
not available, it would call SOFTWARE_SINGLE_STEP() and then
target_resume().
Looking at infrun.c:resume(), it looks like this wouldn't be a trivial
exercise.
--jtc
--
J.T. Conklin
RedBack Networks
From ac131313@cygnus.com Tue Dec 05 16:18:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: "Frank Ch. Eigler" <fche@redhat.com>
Cc: GDB Discussion <gdb@sourceware.cygnus.com>
Subject: Re: [remote] Make registers network byteordered?
Date: Tue, 05 Dec 2000 16:18:00 -0000
Message-id: <3A2D8384.1D52812B@cygnus.com>
References: <3A2C4305.6D9E53B3@cygnus.com> <o566kytwbv.fsf@toenail.toronto.redhat.com>
X-SW-Source: 2000-12/msg00027.html
Content-length: 545
"Frank Ch. Eigler" wrote:
>
> Andrew Cagney <ac131313@cygnus.com> writes:
>
> : [..]
> : At present the target sends back registers in target byte order format
> : vis:
> : T0525:c4060280ffffffff;1d:c0ffff81ffffffff;
> : I'd like to think about a [tweak] to this part of the protocol so that the
> : format:
> : T0525=ffffffff80020664;1d=ffffffff81ffffc0;
> : is accepted. [...]
>
> How are gdb and the target supposed to pick the right scheme? Do you
> imagine some sort of prior negotiation?
The ``='' vs the ``:''.
Andrew
From ac131313@cygnus.com Tue Dec 05 16:24:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Jim Blandy <jimb@cygnus.com>
Cc: GDB Discussion <gdb@sourceware.cygnus.com>
Subject: Re: [remote] Make registers network byteordered?
Date: Tue, 05 Dec 2000 16:24:00 -0000
Message-id: <3A2D84F3.48F372E@cygnus.com>
References: <3A2C4305.6D9E53B3@cygnus.com> <np1yvm8plo.fsf@zwingli.cygnus.com>
X-SW-Source: 2000-12/msg00028.html
Content-length: 975
Jim Blandy wrote:
>
> Andrew Cagney <ac131313@cygnus.com> writes:
>
> >
> > Hello,
> >
> > At present the target sends back registers in target byte order format
> > vis:
> >
> > T0525:c4060280ffffffff;1d:c0ffff81ffffffff;
> >
> > I'd like to think about a tweek to this part of the protocol so that the
> > format:
> >
> > T0525=ffffffff80020664;1d=ffffffff81ffffc0;
> >
> > is accepted. The thing I can't figure out is now to also change the
> > [pP] packets so that GDB can correctly detect targets that support this
> > format when writing registers.
> >
> > General comments?
>
> What's the point? Simply that registers don't have an endianness?
Several motivations:
o there is no robust way of
communicating a change in
endianess through the protocol.
This should be trivial. Fetch
the status register and check
the endian bit. Nope.
o I've had it with trying to read
what are endian independant values
backwards.
enjoy,
Andrew
From cadamuro@lit.cpdtt.cefetpr.br Wed Dec 06 03:22:00 2000
From: João Cadamuro Junior <cadamuro@lit.cpdtt.cefetpr.br>
To: gdb <gdb@sources.redhat.com>
Subject: Re: GDB for powerpc-eabi under cygwin
Date: Wed, 06 Dec 2000 03:22:00 -0000
Message-id: <3A2E2311.16CFC078@lit.cpdtt.cefetpr.br>
References: <3A27C7CC.F75AE735@lit.cpdtt.cefetpr.br>
X-SW-Source: 2000-12/msg00029.html
Content-length: 2343
After "fighting and fighting", I fix the problem in building GDB under cygwin 1.1.6.
Firstly, the problem was cygwin, not GDB. This was discovered when I tried to build the insight-5.0
release and it fail in the same point as 2000-11-30 snapshot.
So, after a number of workarounds without success, I decide to work as a typical Windows user -
remove cygwin and install it all again.
After that, I rebuild all my tools (binutils, cross compiler, libraries and debugger) and ...
works!!! Also the second problem described with breakpoints in the SDS target disappeared (for now
I'm using SDS target for 2 days without seeing the problem again...).
After all, I think I have a corruption in some cygwin upgrade, because since version 1.1.2 I only
upgrade my cygwin installation.
Thank you for all the people who inverst their precious time in taking a look into my problem.
Special thanks to Michael Chastain for the help with the PowerPC simulator, whose problem wasn't
cygwin.
I hope this can help more cygwin users in the future...
Best Regards,
João Cadamuro Junior
LIT / CPDTT / CEFET-PR
URL.: http://www.lit.cpdtt.cefetpr.br
> I have a little questions about debugging powerpc targets and I'll be
> grateful for any help...
>
> I'm using gdb+insight to debug my PowerPC target. The debugger was built
> using option "--target=powerpc-eabi" and under cygwin (Pentium III
> machine with Windows2000 (SP 1) Operating System).
>
> The last successful built for me was 2000-08-16. After this version I
> tryied to build a certain number of snapshots without success.
>
> I have two reasons for build a newer gdb version:
>
> 1. PowerPC simulator don't work for snapshot 2000-08-16.
>
> If you compile a simple "Hello Word" for the simulator and try to debug
> it with GDB, you'll be "ejected"...
>
> 2. Sometimes when the target reports a breakpoint to GDB host with a
> Breakpoint Signal (SDS monitor target...) gdb "eject" me too. The point
> here is that target stop execution, repots the breakpoint signal, and
> GDB crashes receiving this signal. Because this problem is not
> deterministic, I cannot fix it...
>
> With this problems, my last try to build gdb+insight was 2000-11-30
> snapshot, under cygwin-1.1.6 .
>
.............
>
>
> João Cadamuro Junior
> LIT / CPDTT / CEFET-PR
> URL.: http://www.lit.cpdtt.cefetpr.br
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: [remote] Make registers network byteordered?
[not found] <3A2C4305.6D9E53B3@cygnus.com>
2000-12-05 13:03 ` Frank Ch. Eigler
2000-12-05 14:34 ` Jim Blandy
@ 2000-12-07 12:53 ` J.T. Conklin
2 siblings, 0 replies; 5+ messages in thread
From: J.T. Conklin @ 2000-12-07 12:53 UTC (permalink / raw)
To: Andrew Cagney; +Cc: GDB Discussion
>>>>> "Andrew" == Andrew Cagney <ac131313@cygnus.com> writes:
Andrew> At present the target sends back registers in target byte
Andrew> order format vis:
Andrew> [...]
Andrew> General comments?
As the proposal only goes as far as any register values returned by
the 'T' response (and perhaps those sent by the the 'P' command), I
wonder if there is enough value there to implement it?
You mentioned that with the registers being represented in network
byte order, you would be able to determine when a bi-endian target has
switched byte order. But to accomplish this, you'd need to be able to
ensure that all registers fetches/stores used network order otherwise
pure chaos would erupt.
For example, the 'p' command to fetch a single register doesn't exist,
either in the code or the spec, so there is no way to fetch the
processor's status register to know what the current endianess is. I
once experimented adding a 'p' command just to parallel the existing
'P' command, and found that performance was greatly impacted, since
many register writes were used instead of one 'g'.
I think this is yet another thing to put on the list of deficiencies
in the remote protocol's handling of registers, and that all should be
addressed with a new set of fetch/store register protocol commands.
The list as remember them:
* The spec does not nail down the offset, length, and
representation of the registers in the g/G command.
* With the g/G command you fetch/store all registers, with P
you store just one. In a lot of cases, all you care about
is a subset of registers (integers, fpu, pc+fp+sp, etc).
* fetching and storing registers is one of the most common
protocol operations, but there is no way to transfer them
in binary (as there is for memory write).
Any more?
--jtc
--
J.T. Conklin
RedBack Networks
From jtc@redback.com Thu Dec 07 14:17:00 2000
From: jtc@redback.com (J.T. Conklin)
To: gdb@sourceware.cygnus.com
Subject: additional vector function to improve register fetch performance
Date: Thu, 07 Dec 2000 14:17:00 -0000
Message-id: <5m3dfzj2qs.fsf@jtc.redback.com>
X-SW-Source: 2000-12/msg00042.html
Content-length: 2711
While we're talking about register fetch and stores, I had an idea the
outher night about improving performance by adding some new functions
to the target vector.
* target_prefetch_register()
With the register cache and targets that always fetch the entire
register set, fetch performance is as good as can be expected. But
with a target that can fetch one register at a time, GDB will issue
multiple single register fetches. Due to command/response latency,
this has a significant performance impact.
One way this could be addressed is to always fetch the entire
register set. The remote protocol is like this, while it can set a
single register, there is no command to fetch one. This approach
may lose when the register set is large and the number of registers
to be fetched is small; it may be possible to issue several single-
register fetches in the time for one for the entire register set.
Another is the proposed target_prefetch_register() vector function.
All this does is do a hint that we'll need the value of a register
sometime "soon". A sequence like:
sp = read_sp ();
fp = read_fp ();
pc = read_pc ();
r0 = read_register (R0_REGNUM);
Might be changed to:
prefetch_sp ();
prefetch_fp ();
prefetch_pc ();
prefetch_register (R0_REGNUM);
sp = read_sp ();
fp = read_fp ();
pc = read_pc ();
r0 = read_register (R0_REGNUM);
(I'm assuming the prefetch* functions are added to regcache.c to do
whatever housekeeping is required and call the target vector
function).
In a trival target, prefetch would do nothing. In one that has a
async protocol, it might start fetching those registers (a callback
would install the value in the cache when the values were received).
In one that could do single, or full register set fetches, it might
defer fetching anything until the first "real" read was received.
At that time it would decide whether what type of fetch is the most
optimum to perform.
The disadvantage of this is that there is no benefit if the prefetch
hints aren't added. The good thing is that it keeps the interface
between the target independent and target specific parts of GDB
reasonably clean. For contrast, imagine of a target vector function
that took a list of registers to read. This (IMO) would be much
more difficult to use effectively.
Thoughts? I have some partially thought ideas on how to do the same
for register stores, but I'm going to wait until they've firmed up a
bit before sharing.
--jtc
--
J.T. Conklin
RedBack Networks
From tromey@redhat.com Thu Dec 07 15:00:00 2000
From: Tom Tromey <tromey@redhat.com>
To: Gdb List <gdb@sources.redhat.com>
Subject: Renaming insight to `insight'
Date: Thu, 07 Dec 2000 15:00:00 -0000
Message-id: <873dfzddwd.fsf@creche.redhat.com>
X-SW-Source: 2000-12/msg00043.html
Content-length: 1481
I recently sent a patch to gdb-patches.
It contains one deceptively simple change to top.c:
Index: top.c
===================================================================
RCS file: /cvs/src/src/gdb/top.c,v
retrieving revision 1.22
diff -u -r1.22 top.c
--- top.c 2000/11/27 02:18:44 1.22
+++ top.c 2000/12/07 00:03:02
@@ -173,7 +173,7 @@
/* If nonzero, and GDB has been configured to be able to use windows,
attempt to open them upon startup. */
-int use_windows = 1;
+int use_windows = 0;
extern char lang_frame_mismatch_warn[]; /* language.c */
This part of change has gone without public comment so far. (And
without any apparent review by the maintainers.)
The idea here is that `gdb' should just be gdb, and if you want the
GUI you should have to use some other command (eg in this case,
"insight").
I personally like this. That is why I implemented it. When I use gdb
from the command line I always use `gdb -nw', which gets annoying
after a while.
Also, I think this patches emphasizes that insight isn't really gdb.
I think if users type "gdb" then they should get gdb -- not some GUI
that isn't an official part of the gdb distribution. I think this
should happen regardless of how system integrators choose to build gdb
(for instance, Debian or Red Hat might choose to build insight, to
offer more features to their uses. But "gdb" should still be the
trusty CLI, even though that particular gdb executable happens to have
the GUI in it).
Tom
From shebs@apple.com Thu Dec 07 15:38:00 2000
From: Stan Shebs <shebs@apple.com>
To: tromey@redhat.com
Cc: Gdb List <gdb@sources.redhat.com>
Subject: Re: Renaming insight to `insight'
Date: Thu, 07 Dec 2000 15:38:00 -0000
Message-id: <3A301F35.B273D447@apple.com>
References: <873dfzddwd.fsf@creche.redhat.com>
X-SW-Source: 2000-12/msg00044.html
Content-length: 1856
Tom Tromey wrote:
>
> -int use_windows = 1;
> +int use_windows = 0;
> This part of change has gone without public comment so far. (And
> without any apparent review by the maintainers.)
Heh, I didn't notice it either.
> The idea here is that `gdb' should just be gdb, and if you want the
> GUI you should have to use some other command (eg in this case,
> "insight").
>
> I personally like this. That is why I implemented it. When I use gdb
> from the command line I always use `gdb -nw', which gets annoying
> after a while.
The original theory was that GDB's behavior in this respect ought be
similar to Emacs; if you have a window system available, open up
windows for it, but if you don't have windows, or want to use the
console version, use -nw. Curiously, although the analogy is
sensible, the behavior seems never to have really caught on for GDB.
(If I had to hazard a guess, I would say that this is because windowed
Emacs tends to be launched once and live in the background, but GDB
tends to be brought up only as needed.)
> Also, I think this patches emphasizes that insight isn't really gdb.
> I think if users type "gdb" then they should get gdb -- not some GUI
> that isn't an official part of the gdb distribution. I think this
> should happen regardless of how system integrators choose to build gdb
> (for instance, Debian or Red Hat might choose to build insight, to
> offer more features to their uses. But "gdb" should still be the
> trusty CLI, even though that particular gdb executable happens to have
> the GUI in it).
The official long-term GNU goal is still to have a Guile+Gtk interface
that would be available by default and come up by default. However,
until this interface exists, I don't see any problem with turning off
use_windows. It's only a 1-char change anyway, easy to change back if
desired.
Stan
From eliz@is.elta.co.il Thu Dec 07 22:25:00 2000
From: "Eli Zaretskii" <eliz@is.elta.co.il>
To: tromey@redhat.com
Cc: gdb@sources.redhat.com
Subject: Re: Renaming insight to `insight'
Date: Thu, 07 Dec 2000 22:25:00 -0000
Message-id: <9003-Fri08Dec2000082500+0200-eliz@is.elta.co.il>
References: <873dfzddwd.fsf@creche.redhat.com>
X-SW-Source: 2000-12/msg00045.html
Content-length: 625
> From: Tom Tromey <tromey@redhat.com>
> Date: 07 Dec 2000 16:12:34 -0700
>
> -int use_windows = 1;
> +int use_windows = 0;
>
> extern char lang_frame_mismatch_warn[]; /* language.c */
>
> This part of change has gone without public comment so far. (And
> without any apparent review by the maintainers.)
I did see it, but didn't comment because I have no objections to this
change.
> I personally like this. That is why I implemented it. When I use gdb
> from the command line I always use `gdb -nw', which gets annoying
> after a while.
If the patch is accepted, we will need a suitable change for the
manual.
From tromey@redhat.com Thu Dec 07 23:40:00 2000
From: Tom Tromey <tromey@redhat.com>
To: Eli Zaretskii <eliz@is.elta.co.il>
Cc: gdb@sources.redhat.com
Subject: Re: Renaming insight to `insight'
Date: Thu, 07 Dec 2000 23:40:00 -0000
Message-id: <87hf4f8i3t.fsf@creche.redhat.com>
References: <873dfzddwd.fsf@creche.redhat.com> <9003-Fri08Dec2000082500+0200-eliz@is.elta.co.il>
X-SW-Source: 2000-12/msg00046.html
Content-length: 555
>>>>> "Eli" == Eli Zaretskii <eliz@is.elta.co.il> writes:
>> I personally like this. That is why I implemented it. When I use
>> gdb from the command line I always use `gdb -nw', which gets
>> annoying after a while.
Eli> If the patch is accepted, we will need a suitable change for the
Eli> manual.
I looked at the manual but to me it doesn't even say that `-w' is the
default. Also, insight isn't part of gdb, so additions there aren't
necessary.
Changes might be required for the insight help files. I'm looking at
updating them tomorrow.
Tom
From eliz@is.elta.co.il Thu Dec 07 23:57:00 2000
From: "Eli Zaretskii" <eliz@is.elta.co.il>
To: tromey@redhat.com
Cc: gdb@sources.redhat.com
Subject: Re: Renaming insight to `insight'
Date: Thu, 07 Dec 2000 23:57:00 -0000
Message-id: <1438-Fri08Dec2000095645+0200-eliz@is.elta.co.il>
References: <873dfzddwd.fsf@creche.redhat.com> <9003-Fri08Dec2000082500+0200-eliz@is.elta.co.il> <87hf4f8i3t.fsf@creche.redhat.com>
X-SW-Source: 2000-12/msg00047.html
Content-length: 563
> From: Tom Tromey <tromey@redhat.com>
> Date: 08 Dec 2000 00:52:54 -0700
>
> Eli> If the patch is accepted, we will need a suitable change for the
> Eli> manual.
>
> I looked at the manual but to me it doesn't even say that `-w' is the
> default.
I consider that a bug in the current version of the manual. I think
it should say which one of -w and -nw is the default.
> Also, insight isn't part of gdb, so additions there aren't
> necessary.
The change we are talking about is for top.c in the GDB distribution,
no? So it _is_ relevant for GDB, I think.
From ciceron@sunchorus.France.Sun.COM Fri Dec 08 02:53:00 2000
From: Stephane Carrez <ciceron@sunchorus.France.Sun.COM>
To: gdb@sourceware.cygnus.com, jtc@redback.com
Subject: Re: additional vector function to improve register fetch performance
Date: Fri, 08 Dec 2000 02:53:00 -0000
Message-id: <200012081053.LAA22829@sunchorus.France.Sun.COM>
X-SW-Source: 2000-12/msg00048.html
Content-length: 4792
Hi!
> While we're talking about register fetch and stores, I had an idea the
> outher night about improving performance by adding some new functions
> to the target vector.
>
For gdb for ChorusOS (system debug), I'm doing some prefetch to
improve performance. For each processor, I've defined a list of
"gdb important registers". I retreive the complete list when gdb asks
for one of them.
For example for Sparc, I've defined the following list:
sp, pc, rp, fp
So, when gdb asks for either sp or pc, I retreive these 4 registers.
In general, I've observed this is enought. For most processors
Gdb needs the sp, pc and fp (in general after each stop). I'm using this
for sparc, x86 and ppc.
> * target_prefetch_register()
>
> With the register cache and targets that always fetch the entire
> register set, fetch performance is as good as can be expected. But
> with a target that can fetch one register at a time, GDB will issue
> multiple single register fetches. Due to command/response latency,
> this has a significant performance impact.
>
> One way this could be addressed is to always fetch the entire
> register set. The remote protocol is like this, while it can set a
> single register, there is no command to fetch one. This approach
> may lose when the register set is large and the number of registers
> to be fetched is small; it may be possible to issue several single-
> register fetches in the time for one for the entire register set.
Fetching all registers is a killer for PPC... In general, only
the pc, lr and sp are used by Gdb (ok, except for arguments/locals).
>
> Another is the proposed target_prefetch_register() vector function.
> All this does is do a hint that we'll need the value of a register
> sometime "soon". A sequence like:
>
> sp = read_sp ();
> fp = read_fp ();
> pc = read_pc ();
> r0 = read_register (R0_REGNUM);
>
> Might be changed to:
>
> prefetch_sp ();
> prefetch_fp ();
> prefetch_pc ();
> prefetch_register (R0_REGNUM);
> sp = read_sp ();
> fp = read_fp ();
> pc = read_pc ();
> r0 = read_register (R0_REGNUM);
>
> (I'm assuming the prefetch* functions are added to regcache.c to do
> whatever housekeeping is required and call the target vector
> function).
>
> In a trival target, prefetch would do nothing. In one that has a
> async protocol, it might start fetching those registers (a callback
> would install the value in the cache when the values were received).
> In one that could do single, or full register set fetches, it might
> defer fetching anything until the first "real" read was received.
> At that time it would decide whether what type of fetch is the most
> optimum to perform.
>
> The disadvantage of this is that there is no benefit if the prefetch
> hints aren't added. The good thing is that it keeps the interface
> between the target independent and target specific parts of GDB
> reasonably clean. For contrast, imagine of a target vector function
> that took a list of registers to read. This (IMO) would be much
> more difficult to use effectively.
>
> Thoughts? I have some partially thought ideas on how to do the same
> for register stores, but I'm going to wait until they've firmed up a
> bit before sharing.
>
> --jtc
>
> --
> J.T. Conklin
> RedBack Networks
I like the idea of pre-fetching but I wouldn't introduce a new target
vector for that. The 'prefetch_reg' is somewhat generic. We just have
to keep a list of registers that will, soon, be required.
Then, when we really need a register, the target_fetch_register() can
look at the prefetch list that was built. It can then retrieve all of
them depending on the remote protocol.
Adding prefetch hints might be difficult and sometimes you will win nothing.
This is because when you are in the Gdb-generic code, you don't know
in advance which registers you will need. For example, when the frame is
computed, the processor specific code is called. Since this is processor
specific, you don't know which register to prefetch. Adding the pre-fetch
in the *-tdep.c files will not help you because in general you need the
register rigth now (ex: sparc_saved_pc_after_call, rs6000_saved_pc_after_call).
The "gdb important registers" approach is interesting in that it gives
good performance win and does not need to add the pre-fetch hints.
Stephane
- - - - - - - - - -
Stephane |Sun Microsystems |
Carrez |Network Service Provider Division | http://www.sun.com
|6 avenue Gustave Eiffel |
|F-78182, St-Quentin-en-Yvelines-Cedex |
email: Stephane.Carrez@France.Sun.COM
^ permalink raw reply [flat|nested] 5+ messages in thread