Re: [PATCH v3 11/12] selftests/nolibc: add new gettimeofday test cases

[Zhangjin Wu]

> On Sun, Jun 04, 2023 at 11:24:39AM +0200, Arnd Bergmann wrote:
> > On Sun, Jun 4, 2023, at 10:29, ??? wrote:
> > >
> > > Sorry for missing part of your feedbacks, I will check if -nostdlib 
> > > stops the linking of libgcc_s or my own separated test script forgot 
> > > linking the libgcc_s manually.
> > 
> > According to the gcc documentation, -nostdlib drops libgcc.a, but
> > adding -lgcc is the recommended way to bring it back.
> > 
> > > And as suggestion from Thomas' reply,
> > >
> > >>> Perhaps we really need to add the missing __divdi3 and __aeabi_ldivmod and the
> > >>> ones for the other architectures, or get one from lib/math/div64.c.
> > >
> > >>No, these ones come from the compiler via libgcc_s, we must not try to
> > > reimplement them. And we should do our best to avoid depending on them
> > > to avoid the error you got above.
> > >
> > > So, the explicit conversion is used instead in the patch.
> > 
> > I think a cast to a 32-bit type is ideal when converting the
> > clock_gettime() result into microseconds, since the kernel guarantees
> > that the timespec value is normalized, with all zeroes in the
> > upper 34 bits. Going through __aeabi_ldivmod would make the
> > conversion much slower.
> > 

Perfectly, this message is really required to be added to the coming
clock_gettime/time64 patches, I did worry about the (unsigned int)
conversion may lose the upper bits, thanks Arnd.

> > For user supplied non-normalized timeval values, it's not obvious
> > whether we need the full 64-bit division
> 
> We don't have to care about these here for the microsecond part,
> because for decades these were exclusively 32-bit. Also the only
> one consuming this field would have been settimeofday() and it's
> already documented as returning EINVAL if tv_usec is not within
> the expected 0..999999 range.
> 

And this one, thanks Willy.

> And when in doubt we should keep in mind that nolibc's purpose is not
> to become a yet-another full-blown libc alternative but just a small
> piece of software allowing to produce portable and compact binaries
> for testing or booting. Being a bit stricter than other libcs for the
> sake of code compactness is better here. Originally for example it was
> necessary to always pass the 3 arguments to open(). Over time we managed
> to make simple code compile with both glibc and nolibc, but when it
> comes at the cost of adding size and burden for the developers, such
> as forcing them to add libgcc, I prefer that we slightly limit the
> domain of application instead.

This explains why it is 'no' libc ;-)

Best regards,
Zhangjin

> 
> Thanks!
> Willy