On Sep 14, 2010, at 6:30 PM, Darren Hart wrote:
> For what it's worth, I think the bug that Cyril found just further
> supports Gowri's patch to get rid of the asm altogether and go with
> the glibc built-ins. This keeps all these sorts of low-level details
> in one place and avoids duplication. My two cents.
>
> --
> Darren Hart
>
> On Mon, Sep 13, 2010 at 10:45 PM, Subrata Modak
> <[email protected]> wrote:
>> On Thu, 2010-09-09 at 20:20 +0530, gowrishankar wrote:
>>> Hi Cyril,
>>> Do you wish to ack my patch ?
>>
>> Cyril,
>>
>> Waiting for your endorsement/rejection !!
>>
>> Regards--
>> Subrata
>>
>>>
>>> Thanks,
>>> Gowrishankar
>>>
>>> On Thursday 09 September 2010 01:49 PM, Subrata Modak wrote:
>>>> Can both of you agree to send a single patch ?
>>>>
>>>> Regards--
>>>> Subrata
>>>>
>>>> On Mon, 2010-09-06 at 22:19 +0530, gowrishankar wrote:
>>>>
>>>>> On Monday 06 September 2010 09:46 PM, Subrata Modak wrote:
>>>>>
>>>>>> Darren/Gowri,
>>>>>>
>>>>>> Are you aware of this patch ? Can you please provide your comments ?
>>>>>>
>>>>>>
>>>>>>
>>>>> Subrata/Cyril,
>>>>> Apologies that I tagged this mail, but somehow forgot to reply
>>>>> immediately.
>>>>>
>>>>> I had already prepared a patch (before Cyril shared his part) to make
>>>>> atomic_add much more maintenance free and sharing with you guys now.
>>>>> Please find it attached.
>>>>>
>>>>> Thanks,
>>>>> Gowrishankar
>>>>>
>>>>>
>>>>>> Regards--
>>>>>> Subrata
>>>>>>
>>>>>> On Thu, 2010-09-02 at 16:47 +0200, Cyril Hrubis wrote:
>>>>>>
>>>>>>
>>>>>>> Hi!
>>>>>>> The atomic_add() assembler for x86 is missing hint for gcc that value of
>>>>>>> v->counter is being modified by xaddl instruction and as this variable
>>>>>>> is changed only from this asm runtime, some combination of gcc
>>>>>>> optimalizations allows for this value to be placed in binary .rodata
>>>>>>> section resulting in realtime tests segfaulting when trying to do
>>>>>>> atomic_add(). It's reproducible on SLES11 (gcc 4.3.2) with -O2.
>>>>>>>
>>>>>>> Patch attached.
>>>>>>>
>>>>>>> Signed-off-by: Cyril Hrubis [email protected]
Agreed. In this particular case (IMO) LTP doesn't need to reimplement
the atomic functions, because it's probably less tested and more buggy than the
glibc equivalents.
I'm [almost] always in favor of removing unnecessary duplication. This
is one of the cases that I fully support.
Thanks,
-Garrett
------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
_______________________________________________
Ltp-list mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ltp-list
