Time going backwards with clock_gettime(CLOCK_MONOTONIC, ...)

[Chris Johns]

On 13/11/2014 11:57 am, Joel Sherrill wrote:
>
>
> On November 12, 2014 6:54:31 PM CST, Nick Withers <nick.withers at anu.edu.au> wrote:
>> On Wed, 2014-11-12 at 07:19 +0100, Sebastian Huber wrote:
>>> On 12/11/14 02:41, Nick Withers wrote:
>>>> On Tue, 2014-11-11 at 07:53 +0100, Sebastian Huber wrote:
>>>>>> Hello Nick,
>>>>>>
>>>>>> what is the output of the spnsext01 test for this BSP/board?
>>>> Hrmm, doesn't look good:
>>>> ____
>>>>
>>>> *** BEGIN OF TEST SPNSEXT 1 ***
>>>>
>> ../../../../../../../../rtems/c/src/../../testsuites/sptests/spnsext01/init.c:
>> 66 !_Timespec_Less_than(&new_uptime, &uptime)
>>>> ____
>>>>
>>>> ...followed by a reset.
>>>
>>> This shows that the nanoseconds extensions of the clock driver is
>> broken.  This
>>> explains also your time going backwards problem.
>>
>> So I should look at the routine installed by
>> rtems_clock_set_nanoseconds_extension() for my BSP?
>>
>> In the case of the MVME3100, that seems to be
>> Clock_driver_nanoseconds_since_last_tick() in
>> c/src/lib/libcpu/powerpc/mpc6xx/clock/c_clock.c
>>
>> (I'm not totally sure if it's meant to be, since the BSP's Makefile.am
>> seems to refer to e500/clock.rel rather than e.g., the MVME5500's
>> mpc6xx/clock.rel, but I know nothing 'bout autotools!).
> That sounds like the file I tracked it down to when looking for the source.
>
> Yes. Those are hard references to track down. There needs to be a better way.
>

Does the debug info embed the file name in the object file ?

Chris