From patchwork Thu Jul 28 11:50:48 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Pitchumani Sivanupandi X-Patchwork-Id: 653684 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 3s0VWx4QYsz9sdn for ; Thu, 28 Jul 2016 21:49:33 +1000 (AEST) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b=ygKxhJRU; dkim-atps=neutral DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :subject:to:references:cc:from:message-id:date:mime-version :in-reply-to:content-type; q=dns; s=default; b=QeYAuVdOwI9ZzOROc ZU+exjkNb+xN7zwUpzGnLmy2Fm5nb33bjLIOLvESiOoMW5g86EJMsMio4aZI6hty pZbqIReBr6EuyTzM7YXimAj86tJpoWtwkaMIT7KWFLwcUR3ILH6K/gDQIiBNU8zV JA0KEG1jiDjjAJo/Sfabc0O5JM= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :subject:to:references:cc:from:message-id:date:mime-version :in-reply-to:content-type; s=default; bh=2Ych6a15h8AO/GOjEmbwqMz 5kLk=; b=ygKxhJRUwRkrzmdARmPifB1NzmlmsPZXZHUs5gGSrQN38lLCcysWA1T +To62Ra0rLLNB0cjCIXIdrjJ6orS68feThdVP57wOumnjUSmNZrSgcGOPGkZyWhZ KQjGr4RJouuBMXdZuSqLx4mWyfjejxImTa4oGjo35ToRHQ5XVYZU= Received: (qmail 118130 invoked by alias); 28 Jul 2016 11:49:18 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 118114 invoked by uid 89); 28 Jul 2016 11:49:17 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: =?ISO-8859-1?Q?No, score=-3.2 required=5.0 tests=BAYES_00, RP_MATCHES_RCVD, SPF_PASS autolearn=ham version=3.3.2 spammy=8:=b4, 8:-f, D*atmel.com, inflated?= X-HELO: email.microchip.com Received: from smtpout.microchip.com (HELO email.microchip.com) (198.175.253.82) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Thu, 28 Jul 2016 11:49:05 +0000 Received: from [10.40.233.140] (10.10.76.4) by chn-sv-exch05.mchp-main.com (10.10.76.106) with Microsoft SMTP Server id 14.3.181.6; Thu, 28 Jul 2016 04:49:02 -0700 Subject: Re: [patch, avr] Fix mmcu to specs issues To: Georg-Johann Lay References: <555739bc-32cc-8cf1-5bd7-5b4f53682c6b@microchip.com> <0feb1d90-62cc-5359-57d3-31b4166ed93e@gjlay.de> CC: GCC Patches , Denis Chertykov From: Pitchumani Sivanupandi Message-ID: <286bfa2f-84ba-beb2-1b5a-b92873a3ed91@microchip.com> Date: Thu, 28 Jul 2016 17:20:48 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <0feb1d90-62cc-5359-57d3-31b4166ed93e@gjlay.de> 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 >> 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-%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= 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? Regards, Pitchumani gcc/ChangeLog 2016-07-28 Pitchumani Sivanupandi * 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. diff --git a/gcc/config/avr/driver-avr.c b/gcc/config/avr/driver-avr.c index 83ca373..647f91b 100644 --- a/gcc/config/avr/driver-avr.c +++ b/gcc/config/avr/driver-avr.c @@ -29,41 +29,18 @@ along with GCC; see the file COPYING3. If not see static const char dir_separator_str[] = { DIR_SEPARATOR, 0 }; -static const char specfiles_doc_url[] = - "http://gcc.gnu.org/onlinedocs/gcc/Spec-Files.html"; - - -static const char* -avr_diagnose_devicespecs_error (const char *mcu, const char *filename) -{ - error ("cannot access device-specs for %qs expected at %qs", - mcu, filename); - - // Inform about natively supported devices and cores. - - if (strncmp (mcu, "avr", strlen ("avr"))) - avr_inform_devices (); - - avr_inform_core_architectures (); - - inform (input_location, "you can provide your own specs files, " - "see <%s> for details", specfiles_doc_url); - - return X_NODEVLIB; -} - /* Implement spec function `device-specs-file´. - Compose -specs=%s. If everything went well then argv[0] - is the inflated (absolute) specs directory and argv[1] is a device or - core name as supplied by -mmcu=*. When building GCC the path might - be relative. */ + Validate mcu name given with -mmcu option. Compose + -specs=%s. If everything went well then argv[0] is the + inflated (absolute) first device-specs directory and argv[1] is a device + or core name as supplied by -mmcu=*. When building GCC the path might be + relative. */ 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 // Filter out silly -mmcu= arguments like "foo bar". @@ -131,26 +106,12 @@ avr_devicespecs_file (int argc, const char **argv) return X_NODEVLIB; } - if (/* When building / configuring the compiler we might get a relative path - as supplied by "-B.". Assume that the specs file exists and MCU is - a core, not a proper device then, i.e. we have "-mmcu=avr*". */ - (0 == strncmp (mmcu, "avr", strlen ("avr")) - && specfile_name[0] == '.') - /* vanilla */ - || (IS_ABSOLUTE_PATH (specfile_name) - && !access (specfile_name, R_OK))) - { - return concat ("-specs=device-specs", dir_separator_str, "specs-", mmcu, - // Use '%s' instead of the expanded specfile_name. This - // is the easiest way to handle pathes containing spaces. - "%s", + return concat ("-specs=device-specs", dir_separator_str, "specs-", + mmcu, "%s" #if defined (WITH_AVRLIBC) - " %{mmcu=avr*:" X_NODEVLIB "} %{!mmcu=*:" X_NODEVLIB "}", + " %{mmcu=avr*:" X_NODEVLIB "} %{!mmcu=*:" X_NODEVLIB "}", #else - " " X_NODEVLIB, + " " X_NODEVLIB, #endif - NULL); - } - - return avr_diagnose_devicespecs_error (mmcu, specfile_name); + NULL); }