On 03/31/2013 06:04 PM, Zbigniew Halas wrote: > I guess the first thing we should do is to investigate the mechanism of the > problem. And then if it's us misusing gcc we should fix it, otherwise we > should file a bug.
Looks like Martin has already spent some time on it during the past two weeks. Could be that gcc with -ffreestanding assumes that it will not be compiling memcpy and memset because those are expected to be already available in the freestanding mode. It almost looks as if those functions were expected to be implemented in asm. We can have a similar issue with eg. memmove(). > I don't think it's an urgent issue, so we shouldn't make > any rapid moves to workaround it. I haven't had time to look at it, as I want > to use my spare time now to finish Python port (or at least bring it to some > publishable state, which hopefully will happen tomorrow), but when I'm done > with it, I'm volunteering to investigate the issue in detail. It's a little bit urgent issue because currently half of the architectures are broken (the other was already fixed by providing asm implementations). Providing all the implementations in asm won't hurt, but is not the most convenient way of implementing memset and memcpy on earth. > Also is it about userland memcpy? If so I don't see it being defined in terms > of __builtin_memcpy (just a quick grep, so I may be wrong). It's about boot, kernel and uspace memset and memcpy. The problem stays even when we keep -fno-builtin and remove the macros that define memcpy as __builitin_memcpy (and analogously for memset). Jakub _______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/cgi-bin/listinfo/helenos-devel
