Sorry for delay. Committed.
2016-08-08 9:17 GMT+03:00 Pitchumani Sivanupandi <pitchumani.sivanupa...@microchip.com>: > Ping! > > > On Friday 29 July 2016 05:14 PM, Pitchumani Sivanupandi wrote: >> >> On Friday 29 July 2016 02:06 PM, Georg-Johann Lay wrote: >>> >>> On 28.07.2016 13:50, Pitchumani Sivanupandi wrote: >>>> >>>> On Tuesday 26 July 2016 06:00 PM, Georg-Johann Lay wrote: >>>>> >>>>> On 26.07.2016 12:20, Pitchumani Sivanupandi wrote: >>>>>> >>>>>> avr-gcc expected to find the device specs in the search paths >>>>>> specified. But >>>>>> it doesn't work as expected when device specs in different place than >>>>>> the >>>>>> installed location. >>>>>> >>>>>> Example-1: >>>>>> avr-gcc wrongly assumes the device specs will be in first identified >>>>>> 'device-specs' folder in prefix path. avr-gcc natively supports device >>>>>> at90pwm1, but complains as it couldn't find the specs file in the >>>>>> first >>>>>> 'device-specs' directory in the search path. >>>>>> >>>>>> >>>>>> $ avr-gcc test.c -mmcu=at90pwm1 -B /home/install/dev/atxmega128a1u/ >>>>>> >>>>>> avr-gcc: error: cannot access device-specs for _at90pwm1_ expected at >>>>> >>>>> >>>>> Are the "_"s literally? Then the spec file name should be >>>>> "specs-_at90pwm1_". >>>> >>>> No, It was mangled character shown by my terminal for format specifier >>>> "%qs" in >>>> printf. >>>> Ignore it. >>>> ... >>>>>> >>>>>> Example-2: >>>>>> Similar issue happens when -flto option is enabled and device specs in >>>>>> custom >>>>>> search path. >>>>>> >>>>>> atxmega128a1u device specs in custom path and that is passed with -B >>>>>> option. >>>>>> Architecture spec files such as specs-avrxmega7 will be in installed >>>>>> location. >>>>>> >>>>>> $ avr-gcc test.c -mmcu=atxmega128a1u -flto -B >>>>>> /home/install/dev/atxmega128a1u/ >>>>>> >>>>>> avr-gcc: error: cannot access device-specs for _avrxmega7_ expected at >>>>>> _/home/install/dev/atxmega128a1u/device-specs/specs-avrxmega7_ >>>>>> avr-gcc: note: supported core architectures: avr2 avr25 avr3 avr31 >>>>>> avr35 avr4 >>>>>> avr5 avr51 avr6 avrxmega2 avrxmega4 avrxmega5 avrxmega6 avrxmega7 >>>>>> avrtiny avr1 >>>>>> avr-gcc: note: you can provide your own specs files, see >>>>>> <http://gcc.gnu.org/onlinedocs/gcc/Spec-Files.html> for details >>>>>> lto-wrapper: fatal error: avr-gcc returned 1 exit status >>>>>> compilation terminated. >>>>>> /home/avr-trunk/install/lib/gcc/avr/7.0.0/../../../../avr/bin/ld: >>>>>> error: >>>>>> lto-wrapper failed >>>>>> collect2: error: ld returned 1 exit status >>>>>> >>>>>> Attached patch to address these issues. >>>>>> >>>>>> Fix: >>>>>> Replace device-specs-file spec function with mmcu-to-device-specs. >>>>>> This will >>>>>> not assume that specs files are in first identified device-specs >>>>>> directory. >>>>>> Instead this spec function will let gcc identify the absolute path of >>>>>> specs >>>>>> file >>>>>> using spec string "device-specs-file (device-specs/specs-<mcu>%s)". >>>>> >>>>> >>>>> IIUC this leads to problems with LTO and when the install path contains >>>>> spaces which windows distros usually have. The problem is that the >>>>> spec >>>>> function cannot escape the spaces as it would need more than 1 escape >>>>> level. >>>>> >>>>> It might also be the case that -mmcu= is specified more than once (with >>>>> the >>>>> same MCU), but I don't remember exactly in which situations this >>>>> happens... >>>>> Doesn't this lead to inclusion of more than one specs-file? >>>> >>>> >>>> Yes, it lead to space problem. >>>> >>>> Modified the patch because of path with spaces problem. When LTO >>>> enabled, >>>> multiple specs-file are >>>> included as -mmcu=<arch> is fed back to gcc. It happens with/ without of >>>> this >>>> patch. >>>> e.g. For atmega164p, device's and architecture's specs file given when >>>> invoking >>>> collect2. >>>> -specs=device-specs/specs-atmega164p -specs=device-specs/specs-avr5 >>>> >>>> Attached new patch. It just removes the conditions that led to >>>> originally >>>> stated issues. >>>> (In driver-avr.c:avr_devicespecs_file) >>>> Removed first condition as -mmcu=avr* shall come when LTO enabled. >>>> Second >>>> condition to >>>> check absolute path is wrong as the specfile_name composed here will not >>>> be >>>> available >>>> if the specs file is not present in first 'device-specs' directory. >>>> >>>> With this approach, we can't issue 'descriptive' error for unavailable >>>> specs-file. >>>> But, avr-gcc will issue below error if specs file is not found. >>>> $ avr-gcc -mmcu=unknown test.c >>>> avr-gcc: error: device-specs/specs-unknown: No such file or directory >>>> >>>> Is that Ok? >>> >>> >>> Looks reasonable, just ... >>> >>> >>>> Regards, >>>> Pitchumani >>>> >>>> gcc/ChangeLog >>>> >>>> 2016-07-28 Pitchumani Sivanupandi <pitchuman...@atmel.com> >>>> >>>> * config/avr/driver-avr.c (specfiles_doc_url): Remove. >>>> (avr_diagnose_devicespecs_error): Remove. >>>> (avr_devicespecs_file): Remove conditions to check specs-file, >>>> let -specs= option handler do the validation. >>>> const char* >>>> avr_devicespecs_file (int argc, const char **argv) >>>> { >>>> - char *specfile_name; >>>> const char *mmcu = NULL; >>>> >>>> #ifdef DEBUG_SPECS >>>> @@ -111,12 +88,10 @@ avr_devicespecs_file (int argc, const char **argv) >>>> break; >>>> } >>>> >>>> - specfile_name = concat (argv[0], dir_separator_str, "specs-", mmcu, >>>> NULL); >>>> - >>>> #ifdef DEBUG_SPECS >>>> if (verbose_flag) >>>> - fnotice (stderr, "'%s': mmcu='%s'\n'%s': specfile='%s'\n\n", >>>> - __FUNCTION__, mmcu, __FUNCTION__, specfile_name); >>>> + fnotice (stderr, "'%s': mmcu='%s'\n\n", >>>> + __FUNCTION__, mmcu); >>>> #endif >>> >>> >>> ... this DEBUG_SPECS makes hardly any sense any more because it doesn't >>> print any specs-related info. >> >> >> Thanks for the review. Updated the patch. >> >> If Ok, could someone commit please? >> >> Regards, >> Pitchumani >> >> >> gcc/ChangeLog >> >> 2016-07-29 Pitchumani Sivanupandi <pitchuman...@atmel.com> >> >> * config/avr/driver-avr.c (specfiles_doc_url): Remove. >> (avr_diagnose_devicespecs_error): Remove. >> (avr_devicespecs_file): Remove composing absolute path for specfile >> and its verbose info. Remove conditions to check specs-file, >> let -specs= option handler do the validation. >> >
