[Bug threads/11580] scheduler-locking breaks re-runs

[Bug threads/11580] scheduler-locking breaks re-runs

[tromey at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=11580

Tom Tromey <tromey at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tromey at sourceware dot org

--- Comment #8 from Tom Tromey <tromey at sourceware dot org> ---
Users can implement things like "tstep" now using a combination
of 'alias' and 'with'.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug threads/11580] scheduler-locking breaks re-runs

[pedro at codesourcery dot com]

------- Additional Comments From pedro at codesourcery dot com  2010-05-13 17:21 -------
(I missed the "continue -t" which is fine as well)

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=11580

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug threads/11580] scheduler-locking breaks re-runs

[pedro at codesourcery dot com]

------- Additional Comments From pedro at codesourcery dot com  2010-05-13 17:17 -------
Yes, though command proliferation whenever we need a new flag, is probably
not that great, and is limited, e.g., expression evaluation (infcalls) may
need locking as well (for p, x, and others).  HPD's (and TotalView's) ptsets 
handle that nicely, IMO, with syntax that allows scoping a command to a
thread process, or thread group.  We have some work in that direction  
implemented in the old multiprocess branch in cvs, in the form of
itsets (inferior thread sets).  Unfortunately, that never made it to
completion.


-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=11580

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug threads/11580] scheduler-locking breaks re-runs

[pedro at codesourcery dot com]

------- Additional Comments From pedro at codesourcery dot com  2010-05-13 17:12 -------
Note that if gdb was more permissive with allowing disabling schedlock when
the target is exec (you can't _disable_ it currently, that's dumb),
you could just add this to .gdbinit:

define hook-run
 set scheduler-locking off
end

and so every "run" would disable schedlock.

(do the same for "attach" and "start")


-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=11580

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug threads/11580] scheduler-locking breaks re-runs

[dje at google dot com]

------- Additional Comments From dje at google dot com  2010-05-13 16:46 -------
I think one needs to separate the handling of scheduler-locking when the current 
target can't handle it from the handling of scheduler-locking on a re-run.

In the re-run case, having scheduler-locking on at the start of program 
execution can cause confusion / headaches.

scheduler-locking is a session variable, when often what one wants is to just 
enable scheduler-locking temporarily - it's an attribute of the next command, 
not the entire session.  i.e. maybe instead of scheduler-locking=on we had 
tstep, tnext, tcontinue (or continue -t or whatever) that just 
step'd/next'd/continue'd/etc. the current thread only.


-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=11580

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug threads/11580] scheduler-locking breaks re-runs

[pedro at codesourcery dot com]

------- Additional Comments From pedro at codesourcery dot com  2010-05-12 18:04 -------
Please no special casing like that.

IMO, auto disabling the setting behind the user, or frontend's back
is a bad idea.  Better would be to optimistically enable setting
scheduler locking when the target is exec, and instead complain/error
later if the target being resumed doesn't support it.

That is, have the "set scheduler-lock..." command implementation
confirm is it is possible to enable schedlocking on the spot iff
there's execution (target_has_execution), and, have infcmd.c, `proceed', or
`resume' complain is scheduler locking is on, but the current target
doesn't support it.


-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=11580

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug threads/11580] scheduler-locking breaks re-runs

[k04jg02 at gmail dot com]

------- Additional Comments From k04jg02 at gmail dot com  2010-05-12 17:52 -------
Hmm. My core problem is the constant need to type "set scheduler-locking on"
after a crash and then "set scheduler-locking off" each time I want to rerun to
see if the crash is fixed. Maybe it could reset only if the app crashed from
SIGABRT or SIGSEGV, as opposed to being at the gdb console because of a
breakpoint or SIGINT?

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=11580

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug threads/11580] scheduler-locking breaks re-runs

[msnyder at sonic dot net]

------- Additional Comments From msnyder at sonic dot net  2010-05-12 17:36 -------
Hmm, I can see where this is a problem.

However, if you were using scheduler-mode "step", instead of "on", 
I don't think you would necessarily want to have it cleared automatically.

So maybe it should be cleared only if it is "on"?



-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=11580

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.