Odd Formatting in CPU Supplement

[Joel Sherrill]

On Mon, May 20, 2019 at 11:19 PM Sebastian Huber <
sebastian.huber at embedded-brains.de> wrote:

> Hello Joel,
>
> it is in line what GCC prints:
>
> riscv-rtems5-gcc -print-multi-lib
> .;
> rv32i/ilp32;@march=rv32i at mabi=ilp32
> rv32im/ilp32;@march=rv32im at mabi=ilp32
> rv32imafd/ilp32d;@march=rv32imafd at mabi=ilp32d
> rv32iac/ilp32;@march=rv32iac at mabi=ilp32
> rv32imac/ilp32;@march=rv32imac at mabi=ilp32
> rv32imafc/ilp32f;@march=rv32imafc at mabi=ilp32f
> rv64imafd/lp64d;@march=rv64imafd at mabi=lp64d
> rv64imafd/lp64d/medany;@march=rv64imafd at mabi=lp64d at mcmodel=medany
> rv64imac/lp64;@march=rv64imac at mabi=lp64
> rv64imac/lp64/medany;@march=rv64imac at mabi=lp64 at mcmodel=medany
> rv64imafdc/lp64d;@march=rv64imafdc at mabi=lp64d
> rv64imafdc/lp64d/medany;@march=rv64imafdc at mabi=lp64d at mcmodel=medany
>

Ahh .. that explains where it came from.  I realized what it was
as soon as I saw that the formatting was intentional.

>
> I don't mind to change it, but it should be consistent with ARM.
>

I assumed it was repeated somewhere else.

I understand the "." is the top of the lib directory but honestly looking
at that
output confused me. That can't be a good indication that it is going to be
meaningful for someone not familiar with multilibs. Was my suggestion
clearer?

* default (.): XXX

And this follow up discussion makes me wonder if there should be some
generic discussion of multilibs in the porting advice. Adding new CPU model
variants, optimizations, etc. can result in tinkering. Plus RTEMS tool
variants
tend to deviate a bit from the generic *-elf tools.

--joel



> --
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone   : +49 89 189 47 41-16
> Fax     : +49 89 189 47 41-09
> E-Mail  : sebastian.huber at embedded-brains.de
> PGP     : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20190521/122a700a/attachment.html>