Arch Linux User Repository

Greetings,

The description clearly states "Header files and linker scripts for MSP430 microcontrollers". It does not claim to be anything else. It does not claim to support TI's fork of the FSF toolchain. It does not claim to contain some magical file either. It claims to be header files and linker scripts for MSP430 microcontrollers.

If you want to create an alternate package, go for it. Not too sure how AUR administrators would feel about duplicate contents, but that is for them to sort out. I would rather you fix the msp430-elf-gcc-bin package though.

For that matter, I went ahead and checked the gcc-patches mailing list. There are patches that were submitted to the GCC mailing list back in June that want to add support for parsing the devices.csv file [1]. Those patches have not gained any attention from reviewers, it seems. I'd be interested for them to make their way into mainline as it would save me some work, even though I do not agree with the approach. TI can change the format of the csv file. The fact is they have done this in the past [2] and doing so again will mean rebuilding the parser inside the compiler. When those patches make it to a release version of GCC I will include the devices.csv file in this PKGBUILD, but not a moment sooner.

Cheers,

Orlando

[1] https://gcc.gnu.org/ml/gcc-patches/2018-06/msg01672.html

[2] https://sourceforge.net/p/mspgcc/msp430mcu/ci/367c98d4c5efe23508d80557d6ac68a37e13661c/

You should change your description to match that then, because otherwise it's failing to meet the expected behavior of containing all the files needed to support a MSP430 toolchain. Additionally you should avoid using the TI support files as a source to prevent people from assuming any compatibility with TI's compiler, or at least add a disclaimer as mentioned before to the description.

Your entire second paragraph is specious and also effectively non sequitir; it's based on speculation that TI will change their format without any evidence, and that has almost no bearing on the current state of the package. You will trivially get fewer comments about broken packaging when your package has devices.csv regardless of whether or not TI changes their format in some future version.

Since you're not going to act reasonably about this, I'll create a fixed version of this package and request the msp430-elf-gcc-bin maintainer use that as an optional dependency to work around your broken package

Greetings,

No, this package is providing support files for the FSF toolchain. Their package is broken. Not only does the packager assume things about this PKGBUILD when they add it to their optdepends array, they clearly did not bother testing that their package works properly before submitting it. The FSF toolchain, which I maintain, does NOT use the devices.csv file. I am not adding the file to this PKGBUILD because somebody else failed to do their work properly.

Furthermore, if I were to add the devices.csv file and TI decides to change its format in a future release for this package it will once again cause issues with the msp430-elf-gcc-bin package. At which point I will have people here complaining about the devices.csv file again. A change in the devices.csv format will require rebuilding the compiler from source, which is exactly what needs to be done right now when the built-in device list is changed. This is why I am choosing to generate external GCC SPEC files based on the devices.csv as it would not require a compiler rebuild were something to happen to the devices.csv file.

I said it before and I will say it again, if the official FSF tools include support for devices.csv then I will add the file to this package. Otherwise, no, I will not add it.

Cheers,

Orlando.

I believe your package is broken, not theirs. This should be providing the support files from TI for the MSP430, and it's missing one file that would normally be expected to be included. Their GCC package works fine without msp430-elf-mcu, inasmuch as msp430-elf-gcc does without msp430-elf-mcu. It just happens that the support package, ie. this package, doesn't contain the full set of files and that leads to the breakage. I don't see any reason for removing devices.csv aside from intentionally breaking functionality for closed-source users, which doesn't seem to be a particularly valid reason for doing so

Greetings,

No, I am not modifying this PKGBUILD to fix somebody else's packaging mistakes. If TI commits their changes that read from devices.csv to the FSF's repositories and those get added to mainline gcc, then I will happily add the devices.csv files to be installed with this PKGBUILD. Otherwise, no, the msp430-elf-gcc-bin package is at fault and that should be fixed.

For the record, the patch set I am making will not read from the devices.csv file, but from a GCC SPEC file generated from devices.csv, so even when I am done devices.csv will not be included as part of the package. The functionality I am going for is closer to that of the old mspgcc toolchain.

Cheers,

Orlando.

Wouldn't it be simpler just to add one file to this package instead of forcing the maintainers of msp430-elf-gcc-bin to create their own version of this exact package with one extra file in it? This breaks compatibility between msp430-elf-{gcc,binutils,gdb,newlib} and msp430-elf-gcc-bin which otherwise provide close to identical functionality

Greetings,

I am unable to replicate the issue with the latest msp430-elf-gcc toolchain (the one built from sources, not TI's binary one). The problem here is twofold:

(1) TI adds their own patches to their toolchain to read the devices.csv file. This isn't that bad, considering I have been slowly working on a patchset to do the same for the FSF one; and

(2) most importantly, the msp430-elf-gcc-bin toolchain is packaged incorrectly. That toolchain should be installed into /opt as per the Arch packaging standards [1]. Moreover, as clearly seen from the issues that cactus1 is having, the TI toolchain is inherently incompatible with the FSF-based one and the package should not be made to conflict with the latter one, nor should it be made to provide it. Installing that toolchain to /opt like it should have been to begin with will fix any file conflicts and allow both toolchains to coexist on the same system. Optionally, the packager may provide a file in /etc/profile.d to add the toolchain to ${PATH}. That toolchain should provide its own header/linker script files and the devices.csv file.

As such, sorry, but no. I am still not adding the devices.csv file because someone else made a packaging mistake. Please report this issue to the maintainer of the msp430-elf-gcc-bin package so that they can fix their. Alternatively, locally modify this PKGBUILD with dccafe's proposed change.

Cheers, Orlando.

[1] https://wiki.archlinux.org/index.php/Arch_packaging_standards

The lack of devices.csv is causing warnings when using the msp430-elf-gcc-bin toolchain (and seems to break support for newer MCUs like the MSP430FR2512 I'm working with):

msp430-elf-gcc -c -o obj/./main.o -ffunction-sections -Os -std=gnu11 -Wall -Wextra -Wno-main -Werror -mmcu=msp430fr2512 -msmall -DTARGET_IS_MSP430FR2XX_4XX -I. -I/home/kelvin/repos/TI-Captivate-MSP430FR25XX//lib -I/home/kelvin/repos/TI-Captivate-MSP430FR25XX//lib/driverlib -I/home/kelvin/repos/TI-Captivate-MSP430FR25XX//lib/driverlib/MSP430FR2xx_4xx -I/home/kelvin/repos/TI-Captivate-MSP430FR25XX//lib/mathlib -I/home/kelvin/repos/TI-Captivate-MSP430FR25XX//lib/captivate -I/home/kelvin/repos/TI-Captivate-MSP430FR25XX//lib/captivate/ADVANCED -I/home/kelvin/repos/TI-Captivate-MSP430FR25XX//lib/captivate/BASE -I/home/kelvin/repos/TI-Captivate-MSP430FR25XX//lib/captivate/COMM -I/home/kelvin/repos/TI-Captivate-MSP430FR25XX//lib/captivate_app main.c cc1: error: devices.csv not found on any include paths. Please obtain the latest version of the msp430-gcc-support-files archive from: "http://software-dl.ti.com/msp430/msp430_public_sw/mcu/msp430/MSPGCC/latest/index_FDS.html" and place the full path to the "include" directory containing devices.csv on an include path specified with -I Defaulting to the hard-coded device data... [-Werror]

I'm working around by keeping a copy of devices.csv in the project directory, but I'm guessing having it included systemwide is a better solution

Greetings dccafe:

Thank you for reporting this. As fas as I am aware, the devices.csv file is not used anywhere in the toolchain. The microcontroller list is actually hardcoded both in the compiler and the assembler [1, 2]. This is actually a rather unfortunate state of affairs since it requires rebuilding the toolchain every time the list changes. If you look at the commit log of the msp430-elf-{binutils,gcc} packages, you will find I have patched either the compiler or the assembler to keep support in sync. Peter Bigot, the maintainer of the old mspgcc toolchain before Red Hat and TI added official support for the MSP430 architecture to the GNU tools, raised issues with this design [3]. Also unfortunately, the issue remains open upstream [4,5].

Consequently, I have chosen not to include this file in the resulting package. I do not particularly see any use for it. The compiler/assembler will pick the proper ISA/feature set for the MSP430 in question based off the given -mmcu parameter using their built-in list unless overriden by another parameter. Information about the microcontroller's capabilities are also available from the datasheets TI publishes. However, if you have a strong usecase for this file, please feel free to share it and we can evaluate whether or not it merits inclusion.

Cheers,

Orlando.

[1] https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/msp430/msp430.c;h=685bdc8f7858796d193426983b09de5139ab2cfd;hb=HEAD#l98

[2] https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob;f=gas/config/tc-msp430.c;h=bebae6edfaf744ad2b446785baaebde2eee76b66;hb=HEAD#l716

[3] https://www.mail-archive.com/mspgcc-users%40lists.sourceforge.net/msg12200.html

[4] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63953

[5] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63901

Hi there,

You are missing devices.csv behind. Try adding

install -m644 devices.csv "${pkgdir}/usr/${_target}/include"

to the PKGBUILD file.