Adding support for the Xtensa architecture in crosstool-NG

[Chris Zankel]

Hi Yann,

On 10/2/13 2:05 PM, Yann E. MORIN wrote:
> Chris, All,
>
> Sorry for the delay. Here are my comments:
No worries, and thanks for the feedback.

>> +}
>> +
>> +# This function updates the specified component (binutils, gcc, gdb, etc.)
>> +# with the processor specific configuration.
> Ouch! This one is a no-no.
>
> Doing so means the extracted sources of the components can not be
> re-used to build another toolchain (eg. another Xtensa toolchain with
> another overlay, or for another architecture).
Well, the sources can be re-used for all other architectures. They would 
only need to be updated to build for a different Xtensa configuration. 
The 'overlay' is a simple 'tar' file and only overwrites a couple of key 
xtensa-specific configuration files.

These are the files in the overlay (tar) that are overwritten:

./gdb
./gdb/bfd
./gdb/bfd/xtensa-modules.c
./gdb/gdb
./gdb/gdb/regformats
./gdb/gdb/regformats/reg-xtensa.dat
./gdb/gdb/xtensa-config.c
./gdb/gdb/gdbserver
./gdb/gdb/gdbserver/xtensa-regmap.c
./gdb/include
./gdb/include/xtensa-config.h
./gcc
./gcc/include
./gcc/include/xtensa-config.h
./binutils
./binutils/bfd
./binutils/bfd/xtensa-modules.c
./binutils/ld
./binutils/include
./binutils/include/xtensa-config.h

> We already have a mechanism in place for the user to provide
> "customised" sources, by way of the "custom location", see:
> CUSTOM_LOCATION_ROOT_DIR
Wouldn't those sources extract to the same directory names 
(binutils-2.22, for example), so re-use would be even worse? It would 
also negate the benefit of having a tool to generate a configuration 
specific toolchain.
> Basically, I do not like that an architecture has a hook to munge the
> components' sources, or that do not have (complete) support in upstream.
I certainly understand your objections, but don't really see any good 
alternative. Because only Xtensa specific files are overwritten (no file 
used by other architectures is touched), no other architectures would be 
affected.

>> +CT_ConfigureXtensa() {
>> +    local component="${1}"
>> +    local version="${2}"
>> +    local custom_overlay="${CT_ARCH_XTENSA_CUSTOM_OVERLAY_FILE}"
>> +    local custom_location="${CT_ARCH_XTENSA_CUSTOM_OVERLAY_LOCATION}"
>> +        CT_DoLog WARN "'${basename}' not found in '${CT_TARBALLS_DIR}'"
> There's no corresponding CT_GetFile. Who's responsible for downloading
> that file?
The overlay file must be provided by the vendor that generated the 
specific Xtensa configuration.

> I'm not sure where to go from there.
>
> Maybe just add "basic" Xtensa support that only requires what is already
> in upstream gcc/binutils/gdb.
>
> If the user requires a customised Xtensa configuration, then (s)he'd be
> responsible for providing the mangled sources via the "custom location"
> mechanism".
I'd certainly hope you reconsider :-)  Crosstools-NG is just such a 
great way to generate a custom toolchain for a specific Xtensa 
configuration. I also can't seem to think of any good alternative (I'm 
open for ideas), and because this only affects Xtensa and no other 
architecture, it might not be so bad?


Thanks,
-Chris


--
For unsubscribe information see http://sourceware.org/lists.html#faq