Approaching #49567: Use meta-info from --print-multi-lib

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Approaching #49567: Use meta-info from --print-multi-lib

Georg-Johann Lay-2
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:@mmcu=avr25@msp8: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









_______________________________________________
AVR-libc-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Approaching #49567: Use meta-info from --print-multi-lib

Georg-Johann Lay-2
On 29.05.2017 15:40, Georg-Johann Lay wrote:

> 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 by 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 following approach is more conservative and builds on the present
bootstrap scheme:

"bootstrap" gets the compiler from the command line so it can be
used in the poor man's configure-like queries for avr-gcc features
and multilib layout by devtools.

The specified compiler, "avr-gcc" per default, is written to a file,
and configure picks it up and will use it as CC.

That way, "configure" and "bootstrap" are basing on the same avr-gcc
and features.  Specifying CC on the configure command line is
explicitly forbidden.

The patch below shows how it would look like.  The devtools and
how multilib tree is build has not been changed, it's still all
about how to teach "bootstrap" about the compiler and keeping
consistency between "bootstrap" and "configure".


Johann

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




_______________________________________________
AVR-libc-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avr-libc-dev

x.diff (2K) Download Attachment
Loading...