On 27 July 2012 21:26, Martin Sucha <[email protected]> wrote: > On Friday 27 July 2012 19:38:01 Jiří Zárevúcky wrote: >> On 27 July 2012 18:46, Martin Sucha <[email protected]> wrote: >> > [...] >> > >> > Anyway, I think the proper solution is to correctly replace function >> > names in the sources that need the substitution to occur, but I can't >> > think of a way to achieve this using the C preprocessor. Maybe we could >> > use a wrapper around the C preprocessor to add the posix_ prefix where >> > necessary instead of adding it using defines? >> >> Another solution would be to provide symbol aliases instead of >> preprocessor defines. That's the cleanest way I can think of, but it >> would require libc symbols of the same names to be declared weak. That >> is not a problem if we consider libc and libposix to be developed in >> tandem. Using preprocessor for this kind of task is *really* messy (I >> never liked it). > > I have very little experience in this area, but wouldn't it mean that we > cannot link code using libc and libposix into a single binary (as libposix > symbols would override libc symbols)? Also, will this work when using dynamic > linking? >
Every function that is shadowed by something in libposix would actually have to be implemented under a different name (e.g. __libc_memcpy()). Then there would be a weak alias memcpy for this function. In libposix, there would be a strong alias memcpy for __posix_memcpy(). At link time, if used without prefix, linker would pick the __posix variant. Applications aware of this convention could explicitly use __libc variants if they need to (libraries, especially libc itself, since other non-posix libraries are not intended to work with libposix). As for dynamic linking, I'm not exactly sure how that works, so no idea about that. > According to ELF specification, an undefined weak symbol does not generate an > error message, but is instead set to zero. This could make debugging harder if > you forget about it (a run-time error instead of link-time error). > I don't know what exactly you are referring to. When resolving a reference, it doesn't matter if the symbol is weak or not (except when there are multiple definitions). GCC does issue an error if it can't create an alias you want it to create. > On the other hand, changing symbols at the object level could work even if the > code contains references to posix functions e.g. in inline assembler, not just > only in C code. What do you think about patching the compiled object files to > reference correct symbols before linking, instead of using weak symbols? > I think that would still be messy (not as much as the preprocessor stuff though), but could work if aliases don't. _______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/cgi-bin/listinfo/helenos-devel
