[avr-libc-dev] Approaching #49567: Use meta-info from --print-multi-lib

[Georg-Johann Lay]

Hi.

This thread is about https://savannah.nongnu.org/bugs/?49567 and how
it can be solved.

The current implementation is agnostic of gcc's multilib layout and
uses much of hard-coded knowledge.

This makes it hard to extend avr-gcc and add new multilib variants
because avr-libc must always be adjusted in sync.

Information about multilib layout can be retrieved from the compiler
by --print-multi-lib.  This exposes the available multilib directories
together with the options needed to select that multilib variant.

Moreover, for each set of options, in particular -mmcu=<device>, the
compiler can report the respective multilib directory by means of
--print-multi-directory.

These are old features available "since ever" and nothing new.

The current problem with avr-libc is that it abuses autotools in
some weird way:  The "bootstrap" script generates a tree of .am
automake templates be using input templates with special <<fixme>>
entries, replaces the <<fixme>>s to get automake input, them runs
automake, then runs autoconf.

The major problem here is that "bootstrap" is completely agnostic
of the compiler in use, and hence no information can be retrieved
from the compiler.

The first question is: Would work on #49567 be welcome?

Provided I'll come up with something that works, whatever that
will be it will be a big delta.  And as I am not an autotools
expert and not very familiar with avr-libc internals, the outcome
us not unlikely to produce some hickups.

The second question is which approach to take?

Try to extend on the current "bootstrap" script, or try to switch
to a solution with less home-brew and less automake template generation?

Moreover, information is duplicated is several places:

* Devices are listed in configure.ac

* Devices are listed in devtools/gen-avr-lib-tree.sh (sub of bootstrap)

* Devices are listed in devtools/generate_iosym.sh

My current approach is this:  Devices and relevant info (currently only
the old-style crt) is listed in configure.ac:

ADDIF_DEVICE_GCC(at90s4414,   x)
ADDIF_DEVICE_GCC(attiny26,    tn26)
ADDIF_DEVICE_GCC(attiny261,   tn261)

This is used to probe whether the compiler supports that device, and if,
the information is appended to some AC_SUBST.  A script to build the
multilib tree is

AC_CONFIG_FILES([gen-multilib.sh], [chmod +x gen-multilib.sh])

and gets replacement of needed vars:

gen-multilib.sh:

MULTILIB_LAYOUT=".; avr25;@mmcu=avr25 ..."
MULTILIB_TOP="avr/lib"

ALL_DEVICES=" at90s4414 attiny26 attiny261 ..."
ALL_DEVICES_INFO=" at90s4414:.:@mmcu=avr2:x 
attiny26:tiny-stack:@msp8:tn26 
attiny261:avr25/tiny-stack:@address@hidden:tn261 ..."

the intended purpose of this script is to generate

$(MULTILIB_TOP)/avr25/Makefile and friends.

The Makefile is triggered by looping over the multilibs, which
requires GNU make to work, in particular := assignments and
patsubst.  Given libgcc is using a similar approach to
implement loops, this appears to be not a too big restriction,
cf.

https://gcc.gnu.org/viewcvs/gcc/trunk/libgcc/config/avr/lib2-object.mk?revision=195878&view=markup#l1

https://gcc.gnu.org/viewcvs/gcc/trunk/libgcc/config/avr/t-avr?revision=216525&view=markup#l139

Notice how lib2-object.mk is used to implement the loop.

The problem with this approach will be that no automake or
autoconf will run on the generated Makefiles, whereas the
current approach uses a heavy degree of copying the templates
together, amongst them:

Architecture.am, Avr.am, Device.am, Lib.am from devtools.

Ideas?


Johann