> 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
