Fwd: Single stepping through atomic ops

[Grzegorz Bernacki]

The fix was merged into gdb source about two years ago (2007-04-12).
I can find it in gdb version 6.8.
According to gdb release schedule version 6.7 release date is 2007-10-10,
so probably this fix is also in version 6.7, but I haven't checked it.

regards,
Grzesiek
 
> 
>> From: Marcel Moolenaar <xcllnt at mac.com>
>> Date: 1 maja 2009 03:09:59 GMT+02:00
>> To: Rafal Jaworowski <raj at semihalf.com>
>> Cc: "freebsd-ppc at freebsd.org" <freebsd-ppc at freebsd.org>
>> Subject: Re: Single stepping through atomic ops
>>
>> Sorry for the delay...
>> There's an effort to import GDB 6.4 I think. What's the version of GDB
>> that is fixed?
>>
>>
>> --Marcel
>>
>> On Apr 30, 2009, at 2:01 AM, Rafal Jaworowski <raj at semihalf.com> wrote:
>>
>>>
>>> On 2009-04-21, at 19:57, Rafal Jaworowski wrote:
>>>
>>>> Hi Marcel,
>>>> I'm writing to you primarily as the gdb maintainer :-) There's a
>>>> problem with current gdb in base when single stepping through atomic
>>>> sequences on PowerPC (and presumably other archs with the load +
>>>> conditional store approach for atomic ops). The effect is a hang
>>>> because we endlessly loop due to the [always] lost reservation at
>>>> the time of a closing stwcx.
>>>>
>>>> This is a known problem with gdb and it's fixed with newer versions,
>>>> but the patches are not applicable to our gdb due to some
>>>> infrastructure changes. The quick fix for 6.1.1 is here:
>>>> http://people.freebsd.org/~raj/patches/powerpc/gdb-ppc-single-step.diff
>>>>
>>>> It's mainly a transplant of two fixes from the gdb repository
>>>> (1.275, 1.276, deal_with_atomic_sequence) adjusted to our older gdb
>>>> code, but it's ugly #ifdef'ed __ppc__. In order to do it cleanly we
>>>> would need to change the signature of the SOFTWARE_SINGLE_STEP
>>>> method so it returns a value (this is how newer gdb works), but it
>>>> would affect gdb for all architectures. Do you see any objections
>>>> for growing a return value here?
>>>>
>>>> Another direction would be importing a newer gdb code base, and be
>>>> able to apply the fixes directly and cleanly (if at all required),
>>>> but am not sure if there are any plans to upgrade gdb in base? Let
>>>> me know your comments.
>>>
>>> Have you got any comments to this? Should I move on and commit this
>>> as ugly as is, or would reworking SOFTWARE_SINGLE_STEP be more
>>> desired? Any thoughts about newer gdb versions coming to the tree?
>>>
>>> Rafal
>>>
>