sysd-rules generation doesn't allow non-invasive addition of addon rules

["Ryan S. Arnold" <rsa at us dot ibm dot com>]

Roland, et al,

The method used by libc/Makerules for generating the ordered list of
implicit rules which find the source files in each sysdep directory when
$$(compile-command) is executed is deficient.

The rule for $(common-objpfx)sysd-rules, which creates the sysd-rules
file, requires that an add-on which needs some symbols added to libc (or
any other library for that matter) be required to have tendrils into the
base glibc Makerules file, e.g.

We have an add-on:

libc/addon
libc/addon/add_me.c
libc/addon/sysdeps/powerpc/add_me.c
libc/addon/sysdeps/unix/sysv/linux/Implies: powerpc

In libc/addon/Makefile we have a variable:

libaddon-shared = add_me

Which has symbols which need to go into libaddon.so and libc.so

In order to provide actual targets for the files added to routines from
$(addon-shared) we have to find the c files associated with them and
rebuild them as .so files prefaced with "libc-" so that they're not
built with NOT_IN_libc.  This is so that the hidden_proto checks work
properly.  This doesn't create a new .c file.  It simply builds again
and creates libc-<addon-shared>.so.

routines = $(libaddon-shared:%=libc-%)

define o-iterator-doit
$(objpfx)libc-%$o: %.c $(before-compile); $$(compile-command.c)
endef
object-suffixes-left := $(all-object-suffixes)
include $(o-iterator)

By precedent this is how nptl (with the ptw- prefix) and rtld (with the
rtld- prefix) do it.

The problem is that this doesn't result in the libc/addon/sysdeps
directory being searched for the add_me.c file because the sysd-rules
file generated by libc/Makerules doesn't have an implicit rule for
processing libc-<stem>.so targets.

So in the case of an addon that's not part of glibc proper the add-on's
sysdep directories are never searched and 'make' finally processes the
rule which generates libc-add_me.so from add_me.c.

Unfortunately it simply picks up the first version of add_me.c
(libc/addon/add_me.c) it finds, which on powerpc doesn't happen to be
the correct one.

The converse doesn't work either (using libaddon- as a prefix) because,
once again, it won't match any sysd-rules without adding one for
libaddon-.

Each prefix has to be hard-coded into the sysd-rules generation file.

We've verified that this works if we simply use the "rtld-" prefix for
those functions added to 'routines' but for the sake of correctness,
this isn't.

Simply adding a libc_ prefix would allows add-ons to have
sysdep-overridden functions in libc because the libc- prefix rules would
match the functions for libc:
    echo "\$$(objpfx)libc-%$$o: $$dir/%.c \$$(before-compile); \
          \$$(compile-command.c)";

and the sysd-rules generic rule would match the functions for
libaddon.so (and others):

             echo "\$$(objpfx)%$$o: $$dir/%.c \$$(before-compile); \
                  \$$(compile-command.c)";

A method whereby the sysd-rules could have prefix-<stem> targets added
via an add-on dynamically would be the best solution.

Any comments?

Ryan S. Arnold
IBM Linux Technology Center
Linux Toolchain Development