* Re: [PATCH] More updates to FXSR/SSE support in 2.4.0-test1
[not found] ` <200006120002.e5C02mv14043@delius.kettenis.local>
@ 2000-06-11 21:56 ` Gareth Hughes
2000-06-12 13:59 ` Mark Kettenis
0 siblings, 1 reply; 3+ messages in thread
From: Gareth Hughes @ 2000-06-11 21:56 UTC (permalink / raw)
To: Mark Kettenis; +Cc: alan, drepper, adam, linux-kernel, bug-glibc, gdb
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
^ permalink raw reply [flat|nested] 3+ messages in thread