[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cdt-debug-dev] Assignement and side effects (PR 31484)
|
Hi!
Does not matter to me if it goes into 101 since 101 is not changing much.
We are off in our own little world now. I only sent it out because it seems
like a core problem that others might actually care about and I didn't know
that you folks were already planning fixes to the more generic problem. I
do look forward to the real change since you are quite right, a lot more
really needs to be updated on changes.
My understanding, perhaps wrong, is that 5.3 has "cooked" registers instead
of pseudo registers. I think that they finally formalized the concept of
what was happening in the portability layers. We are on 5.2.1 at the
moment. Certainly what I sent to the list works for me.
As you consider the real fix perhaps consider a lazy component to the
solution. You may well cut down a lot of the performance hit if you don't
refresh view data until the view is actually visible to the user. I've
noticed that if the memory view is hidden behind something else there is
still lots of traffic with the debugger. Waiting to query until the user
brings that panel to the front may eliminate some unnecessary work while
still allowing the user to keep sophisticated debugging state in the UI.
Certainly once you starting talking about debugging over a JTAG connection
it's going to make a big difference.
Thanks!
-Chris
At 07:19 PM 2/10/2003 -0500, Alain Magloire wrote:
>
> I look forward to seeing the more general fix. I'm sure there are more
> things out there.
It is up to you, I can put the patch in the 1.0.1 branch, to make life
easier for you, if you want, but will push for the general solution
since we want to provide something like that for the VariableManager,
MemoryManager etc ... where if you do not mind the penality of updating
for every assignement(preference page toggle).
Note, what version of gdb are you using, since gdb introduces
the pseudo-registers in gdb-5.3(minus bug, see Note 2: below)?
>
> Thanks!
> -Chris
>
> At 04:04 PM 2/10/2003 -0500, you wrote:
>
> >I'll move this discussion here.
> >
> >Note 1: I had already raised a PR on this on gdb, keith/elena and all
have in
> >the current gdb head branch, a new OOB that will notify for assignements
> >and when side effects, in the GDB/MI 2 protocol it looks like this:
> >
> >(gdb)
> >&"set *(int*)&argc = 32\n"
> >=target-changed
> >^done
> >(gdb)
> >
> >Base on this, I would advocate for a more general approach for
> >the PR 31484 (see below):
> >
> >An assignement, whether a register, memoryblock or variable, should
trigger
> >an ChangedEvent event, then it will be up to the framework to call
update()
> >on all the managers to check for any side effect of the assigment.
> >And in the future, it may not be necessary to do it manually in the
cdt/gdb
> >implementation because of the new OOB "=target-changed"
> >
> >
> >something like this in pseudo-code:
> >
> >void handleChangeEvent() {
> > IManagers[] mgrs = session.getManagers();
> > if (updateOnAssignement) {
> > for (int i = 0; i < mgrs.length; i++) {
> > mgrs.update();
> > }
> > }
> >}
> >
> >
> >
> >Note 2:
> >The other point is particular to gdb-5.3 and pseudo-registers even
> >calling update() on the RegisterManager may not work since the GDB/MI
> >command "-data-list-changed-register" and "-data-list-register-values"
> >do not track the pseudo-register. A PR was created in the GDB database
> >for this.
> >
> >
> >==========================================================
> >http://bugs.eclipse.org/bugs/show_bug.cgi?id=31484
> >
> > Summary: Register setting does not correctly update display.
> > Product: CDT
> > Version: 1.0
> > Platform: All
> > OS/Version: Windows 2000
> > Status: NEW
> > Severity: minor
> > Priority: P3
> > Component: Debug
> > AssignedTo: Mikhailk@xxxxxxx
> > ReportedBy: songer@xxxxxxxxxxxxx
> >
> >
> >GDB pseudo registers are registers that do not really exist in the
> >architecture
> >but are convenient values that are often based on actual architectural
> >state. A
> >user initiated change with the Register Manager to either a pseudo
> >register or
> >register on which a psuedo register depends did not update the displayed
> >values
> >for all the affected registers.
> >
> >Consider the following example of this happening in a normal run with the
> >Xtensa debugger. Note in particular that changing the value of $a6 also
> >changes
> >the value for $ar10.
> >
> >(xt-gdb) run
> >Starting program: /cygdrive/c/JavaDev/eclipseclean/runtime-
> >workspace/HelloWorld/bin/SimpleSystem.soc/simple_build/proces
> >sor_s1/Debug/HelloWorld
> >Switching to remote protocol
> >Remote debugging using localhost:56679
> >Found ISS3
> >0x40000020 in _ResetVector ()
> >
> >Breakpoint 1, main (argc=1, argv=0x600fff40) at main.c:6
> >6 printf( "hello world\n");
> >(xt-gdb) print $wb
> >$1 = 1
> >(xt-gdb) print $a6
> >$2 = 0
> >(xt-gdb) print $ar10
> >$3 = 0
> >(xt-gdb) set $a6 = 0x10
> >(xt-gdb) print $ar10
> >$4 = 16
> >(xt-gdb)
> >
> >(Note, I've fixed this already and will submit a patch for it, but wanted
> >a bug
> >tracking number to go with it.)
> >
> >_______________________________________________
> >cdt-debug-dev mailing list
> >cdt-debug-dev@xxxxxxxxxxx
> >http://dev.eclipse.org/mailman/listinfo/cdt-debug-dev
>
> _______________________________________________
> cdt-debug-dev mailing list
> cdt-debug-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/cdt-debug-dev
>
--
au revoir, alain
----
Aussi haut que l'on soit assis, on est toujours assis que sur son cul !!!
_______________________________________________
cdt-debug-dev mailing list
cdt-debug-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/cdt-debug-dev
