Re: Processed: gdc: FTBFS: ld: final link failed: Bad value
On 3 December 2016 at 22:29, Matthias Klose wrote: > On 03.12.2016 22:13, Markus Koschany wrote: >> On 03.12.2016 22:00, Matthias Klose wrote: >>> reassign 846669 gdc-6 >>> forcemerge 845377 846669 >>> thanks >>> >>> please see #845377. >>> >>> This build is configured with --enable-default-pie. The linker is now >>> called >>> with -pie, but cc1d isn't passed either -fPIE, or -fPIC. The work around >>> is to >>> pass either -fPIC, or -no-pie. Also passing -fPIE doesn't have an effect. >> >> Hi, >> >> sorry I'm not a D expert. Do you intend to fix #845377 before the Freeze or >> are all >> reverse-dependencies supposed to work around this issue by passing either >> -fPIC or -no-pie to configure? > > Please give Iain some time to have a look at this. > I'll be spending today on this. Hopefully not all. :-) Regards
Bug#846872: gcc-7: FTBFS on m68k - fails to apply ada-m68k.diff patch
Hi Matthias! On 12/03/2016 11:56 PM, Matthias Klose wrote: > Adrian, I would appreciate if you could look at a package first before calling > for actions, and then ask a complete question. We also have the > m68k-revert-pr45144 patch in the build which apparently needs some decision. Dropping ada-m68k.diff fixes this particular issue for me. m68k-revert-pr45144.patch is currently not applied because we have disabled Ada on m68k by adding it to ada_no_cpus in debian/rules.defs because of #814221 [1]. I think it makes sense to discuss m68k-revert-pr45144.patch in #814221 and treat this particular patch as a separate issue. Adrian > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=814221 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#846872: gcc-7: FTBFS on m68k - fails to apply ada-m68k.diff patch
On 12/04/2016 01:11 PM, John Paul Adrian Glaubitz wrote: > Dropping ada-m68k.diff fixes this particular issue for me. > m68k-revert-pr45144.patch > is currently not applied because we have disabled Ada on m68k by adding it to > ada_no_cpus in debian/rules.defs because of #814221 [1]. Hmm, so I just had a look at the current gcc-7 sources as well as gcc git and it seems this particular patch which adds support for m68k-linux is not in, I see support for VXWorks only: glaubitz@ikarus:~/m68k/gcc-7-7-20161201/gcc-20161201/gcc/ada$ ls -l *m68k* -rw-r--r-- 1 glaubitz glaubitz 3533 Dec 9 2014 s-vxwork-m68k.ads -rw-r--r-- 1 glaubitz glaubitz 7829 Apr 26 2016 system-vxworks-m68k.ads glaubitz@ikarus:~/m68k/gcc-7-7-20161201/gcc-20161201/gcc/ada$ @Andreas: Are you sure the patch is no longer necessary? Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#846872: gcc-7: FTBFS on m68k - fails to apply ada-m68k.diff patch
On Dez 04 2016, John Paul Adrian Glaubitz wrote: > @Andreas: Are you sure the patch is no longer necessary? I didn't say that. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Bug#846872: gcc-7: FTBFS on m68k - fails to apply ada-m68k.diff patch
On 12/04/2016 02:38 PM, Andreas Schwab wrote: > On Dez 04 2016, John Paul Adrian Glaubitz > wrote: > >> @Andreas: Are you sure the patch is no longer necessary? > > I didn't say that. Ok, this was a misunderstanding then as you meant earlier that "this" is no longer necessary. But I assume you were talking about the single hunk in line 47 that does no longer apply and not the whole patch, correct? Removing this hunk below from the patch, makes it apply without issues: --- a/src/gcc/ada/s-memory.adb +++ b/src/gcc/ada/s-memory.adb @@ -47,6 +47,7 @@ with Ada.Exceptions; with System.Soft_Links; with System.Parameters; with System.CRTL; +with Ada.Unchecked_Conversion; package body System.Memory is However, I'm by no means an Ada expert to be able to tell whether we still need Ada.Unchecked_Conversion anymore. I have glimpsed over PR48835 and I'm not sure whether this confirms this in any way. I'm attaching the updated ada-m68k.diff in any case. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 gcc/ada/ 2011-10-12 Mikael Pettersson PR ada/48835 * gcc-interface/Makefile.in: Add support for m68k-linux. * system-linux-m68k.ads: New file based on system-linux-ppc.ads and system-vxworks-m68k.ads. * s-memory.adb (Gnat_Malloc): New wrapper around Alloc, returning the memory address as a pointer not an integer. Add Gnat_Malloc -> __gnat_malloc export. * s-memory.ads: Remove Alloc -> __gnat_malloc export. Index: b/src/gcc/ada/gcc-interface/Makefile.in === --- a/src/gcc/ada/gcc-interface/Makefile.in +++ b/src/gcc/ada/gcc-interface/Makefile.in @@ -2084,6 +2084,35 @@ ifeq ($(strip $(filter-out hppa% linux%, LIBRARY_VERSION := $(LIB_VERSION) endif +# M68K Linux +ifeq ($(strip $(filter-out m68k% linux%,$(arch) $(osys))),) + LIBGNAT_TARGET_PAIRS = \ + a-intnam.adshttp://www.gnu.org/licenses/>. -- +-- -- +-- GNAT was originally developed by the GNAT team at New York University. -- +-- Extensive contributions were provided by Ada Core Technologies Inc. -- +-- -- +-- + +package System is + pragma Pure; + -- Note that we take advantage of the implementation permission to make + -- this unit Pure instead of Preelaborable; see RM 13.7.1(15). In Ada + -- 2005, this is Pure in any case (AI-362). + + type Name is (SYSTEM_NAME_GNAT); + System_Name : constant Name := SYSTEM_NAME_GNAT; + + -- System-Dependent Named Numbers + + Min_Int : constant := Long_Long_Integer'First; + Max_Int : constant := Long_Long_Integer'Last; + + Max_Binary_Modulus: constant := 2 ** Long_Long_Integer'Size; + Max_Nonbinary_Modulus : constant := 2 ** Integer'Size - 1; + + Max_Base_Digits : constant := Long_Long_Float'Digits; + Max_Digits: constant := Long_Long_Float'Digits; + + Max_Mantissa : constant := 63; + Fine_Delta: constant := 2.0 ** (-Max_Mantissa); + + Tick : constant := 0.000_001; + + -- Storage-related Declarations + + type Address is private; + pragma Preelaborable_Initialization (Address); + Null_Address : constant Address; + + Storage_Unit : constant := 8; + Word_Size: constant := 32; + Memory_Size : constant := 2 ** 32; + + -- Address comparison + + function "<" (Left, Right : Address) return Boolean; + function "<=" (Left, Right : Address) return Boolean; + function ">" (Left, Right : Address) return Boolean; + function ">=" (Left, Right : Address) return Boolean; + function "=" (Left, Right : Address) return Boolean; + + pragma Import (Intrinsic, "<"); + pragma Import (Intrinsic, "<="); + pragma Import (Intrinsic, ">"); + pragma Import (Intrinsic, ">="); + pragma Import (Intrinsic, "="); + + -- Other System-Dependent Declarations + + type Bit_Order is (High_Order_First, Low_Order_First); + Default_Bit_Order : constant Bit_Order := High_Order_First; + pragma Warnings (Off, Default_Bit_Order); -- kill constant condition warning + + -- Priority-related Declarations (RM D.1) + + -- Is the following actually true for GNU/Linux/m68k? + -- + -- 0 .. 98 corresponds to the system priority range 1 .. 99. + -- + -- If the scheduling policy is SCHED_FIFO or SCHED_RR the runtime makes use + -- of the entire range provided by the system. + -- + -- If the scheduling policy is SCHED_OTHER the only valid system priority + -- is 1 and other values are simply ignored. + + Max_Priority : constant Positive := 97; + Max_In
Bug#846872: gcc-7: FTBFS on m68k - fails to apply ada-m68k.diff patch
On 12/04/2016 04:43 PM, John Paul Adrian Glaubitz wrote: > However, I'm by no means an Ada expert to be able to tell whether we still > need > Ada.Unchecked_Conversion anymore. I have glimpsed over PR48835 and I'm not > sure > whether this confirms this in any way. Ah, I assume you were talking about comment #58 [1], sorry, I missed that. It seems that the conversion issue no longer exists, am I correct? So I assume we can strip the patch from the changes in s-memory.adb and s-memory.ads? It seems from my elementary understanding of Ada, this was just a work-around for the the m68k-typical register separation (address and data) and they've now fixed the issue properly so the workaround is no longer required. If that's true, I assume we just need src/gcc/ada/s-memory.ads as well as the changes to src/gcc/ada/gcc-interface/Makefile.in. Adrian > [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48835#c58 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#846872: gcc-7: FTBFS on m68k - fails to apply ada-m68k.diff patch
On Dez 04 2016, John Paul Adrian Glaubitz wrote: > So I assume we can strip the patch from the changes in s-memory.adb and > s-memory.ads? Yes. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Bug#846872: gcc-7: FTBFS on m68k - fails to apply ada-m68k.diff patch
On 12/04/2016 06:26 PM, Andreas Schwab wrote: > On Dez 04 2016, John Paul Adrian Glaubitz > wrote: > >> So I assume we can strip the patch from the changes in s-memory.adb and >> s-memory.ads? > > Yes. OK, attaching the updated patch which applies cleanly. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 gcc/ada/ 2011-10-12 Mikael Pettersson PR ada/48835 * gcc-interface/Makefile.in: Add support for m68k-linux. * system-linux-m68k.ads: New file based on system-linux-ppc.ads and system-vxworks-m68k.ads. * s-memory.adb (Gnat_Malloc): New wrapper around Alloc, returning the memory address as a pointer not an integer. Add Gnat_Malloc -> __gnat_malloc export. * s-memory.ads: Remove Alloc -> __gnat_malloc export. Index: b/src/gcc/ada/gcc-interface/Makefile.in === --- a/src/gcc/ada/gcc-interface/Makefile.in +++ b/src/gcc/ada/gcc-interface/Makefile.in @@ -2084,6 +2084,35 @@ ifeq ($(strip $(filter-out hppa% linux%, LIBRARY_VERSION := $(LIB_VERSION) endif +# M68K Linux +ifeq ($(strip $(filter-out m68k% linux%,$(arch) $(osys))),) + LIBGNAT_TARGET_PAIRS = \ + a-intnam.adshttp://www.gnu.org/licenses/>. -- +-- -- +-- GNAT was originally developed by the GNAT team at New York University. -- +-- Extensive contributions were provided by Ada Core Technologies Inc. -- +-- -- +-- + +package System is + pragma Pure; + -- Note that we take advantage of the implementation permission to make + -- this unit Pure instead of Preelaborable; see RM 13.7.1(15). In Ada + -- 2005, this is Pure in any case (AI-362). + + type Name is (SYSTEM_NAME_GNAT); + System_Name : constant Name := SYSTEM_NAME_GNAT; + + -- System-Dependent Named Numbers + + Min_Int : constant := Long_Long_Integer'First; + Max_Int : constant := Long_Long_Integer'Last; + + Max_Binary_Modulus: constant := 2 ** Long_Long_Integer'Size; + Max_Nonbinary_Modulus : constant := 2 ** Integer'Size - 1; + + Max_Base_Digits : constant := Long_Long_Float'Digits; + Max_Digits: constant := Long_Long_Float'Digits; + + Max_Mantissa : constant := 63; + Fine_Delta: constant := 2.0 ** (-Max_Mantissa); + + Tick : constant := 0.000_001; + + -- Storage-related Declarations + + type Address is private; + pragma Preelaborable_Initialization (Address); + Null_Address : constant Address; + + Storage_Unit : constant := 8; + Word_Size: constant := 32; + Memory_Size : constant := 2 ** 32; + + -- Address comparison + + function "<" (Left, Right : Address) return Boolean; + function "<=" (Left, Right : Address) return Boolean; + function ">" (Left, Right : Address) return Boolean; + function ">=" (Left, Right : Address) return Boolean; + function "=" (Left, Right : Address) return Boolean; + + pragma Import (Intrinsic, "<"); + pragma Import (Intrinsic, "<="); + pragma Import (Intrinsic, ">"); + pragma Import (Intrinsic, ">="); + pragma Import (Intrinsic, "="); + + -- Other System-Dependent Declarations + + type Bit_Order is (High_Order_First, Low_Order_First); + Default_Bit_Order : constant Bit_Order := High_Order_First; + pragma Warnings (Off, Default_Bit_Order); -- kill constant condition warning + + -- Priority-related Declarations (RM D.1) + + -- Is the following actually true for GNU/Linux/m68k? + -- + -- 0 .. 98 corresponds to the system priority range 1 .. 99. + -- + -- If the scheduling policy is SCHED_FIFO or SCHED_RR the runtime makes use + -- of the entire range provided by the system. + -- + -- If the scheduling policy is SCHED_OTHER the only valid system priority + -- is 1 and other values are simply ignored. + + Max_Priority : constant Positive := 97; + Max_Interrupt_Priority : constant Positive := 98; + + subtype Any_Priority is Integer range 0 .. 98; + subtype Priority is Any_Priority range 0 .. 97; + subtype Interrupt_Priority is Any_Priority range 98 .. 98; + + Default_Priority : constant Priority := 48; + +private + + type Address is mod Memory_Size; + Null_Address : constant Address := 0; + + -- + -- System Implementation Parameters -- + -- + + -- These parameters provide information about the target that is used + -- by the compiler. They are in the private part of System, where they + -- can be accessed using the special
Re: Processed: gdc: FTBFS: ld: final link failed: Bad value
On 4 December 2016 at 10:15, Iain Buclaw wrote: > On 3 December 2016 at 22:29, Matthias Klose wrote: >> On 03.12.2016 22:13, Markus Koschany wrote: >>> On 03.12.2016 22:00, Matthias Klose wrote: reassign 846669 gdc-6 forcemerge 845377 846669 thanks please see #845377. This build is configured with --enable-default-pie. The linker is now called with -pie, but cc1d isn't passed either -fPIE, or -fPIC. The work around is to pass either -fPIC, or -no-pie. Also passing -fPIE doesn't have an effect. >>> >>> Hi, >>> >>> sorry I'm not a D expert. Do you intend to fix #845377 before the Freeze or >>> are all >>> reverse-dependencies supposed to work around this issue by passing either >>> -fPIC or -no-pie to configure? >> >> Please give Iain some time to have a look at this. >> > > I'll be spending today on this. Hopefully not all. :-) > > Regards It looks like the pre-emptive check for "is this symbol external?" is not right. The codegen pass thinks it should be static, but it is infact not, and so it emits the call without @PLT. This only affects D templates. Incidentally, I recently cleaned up the area where this is done, making it a small fix in upstream. Will have a look at debian's source package to prepare the relevant patch. Regards Iain
