On Friday 27 July 2012 22:08:02 Jiří Zárevúcky wrote: > 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). Thanks for explanation.
> > 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. I'm referring to [1], page 24: > When the link editor searches archive libraries, it extracts archive members > that contain definitions of undefined global symbols. The member’s definition > may be either a global or a weak symbol. The link editor does not extract > archive members to resolve undefined weak symbols. Unresolved weak symbols > have a zero value. and [2]: > An _undefined_ weak symbol will not cause the linker to error out if a > definition is not found. Instead, the symbol will be filled in with a default > value of 0. [1] http://www.skyfree.org/linux/references/ELF_Format.pdf [2] http://blog.omega-prime.co.uk/?p=121#linux But this may not affect the result if the object files are structured in a way you described above, I just pointed this out as I found it when looking up some info about weak symbols. Regards, Martin Sucha _______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/cgi-bin/listinfo/helenos-devel
