* [RS6000] Don't pass --oformat to ld
@ 2015-09-02 1:35 Alan Modra
2015-09-02 3:29 ` David Edelsohn
2015-09-24 6:24 ` Michael Ellerman
0 siblings, 2 replies; 5+ messages in thread
From: Alan Modra @ 2015-09-02 1:35 UTC (permalink / raw)
To: gcc-patches; +Cc: David Edelsohn, Michael Meissner
bugzilla.redhat.com/show_bug_cgi?id=1255946 shows that gcc built with
both powerpc64-linux and powerpc64le-linux support passes wrong linker
options when trying to link in the non-default endian. A --oformat
option coming from LINK_TARGET_SPEC is only correct for 32-bit.
It turns out that GNU ld -m options select a particular ld emulation
(e*.c file in ld build dir) which provides compiled-in scripts or
selects a script from ldscripts/. Each of these has an OUTPUT_FORMAT
statement, which does the same thing as --oformat. --oformat is
therefore redundant when using GNU ld built this century, except
possibly when a user overrides the default ld script with -Wl,-T and
their script neglects OUTPUT_FORMAT, and it isn't the default output.
I don't think it's worth fixing this possible use case.
Bootstrap and testing in progress. OK for mainline assuming all is
OK?
* config/rs6000/sysv4le.h (LINK_TARGET_SPEC): Don't define.
* config/rs6000/sysv4.h (LINK_TARGET_SPEC): Likewise.
(LINK_SPEC, SUBTARGET_EXTRA_SPECS): Delete link_target.
diff --git a/gcc/config/rs6000/sysv4.h b/gcc/config/rs6000/sysv4.h
index 24618e3..f48af43 100644
--- a/gcc/config/rs6000/sysv4.h
+++ b/gcc/config/rs6000/sysv4.h
@@ -574,7 +574,6 @@ ENDIAN_SELECT(" -mbig", " -mlittle", DEFAULT_ASM_ENDIAN)
%{R*} \
%(link_shlib) \
%{!T*: %(link_start) } \
-%(link_target) \
%(link_os)"
/* Shared libraries are not default. */
@@ -584,10 +583,6 @@ ENDIAN_SELECT(" -mbig", " -mlittle", DEFAULT_ASM_ENDIAN)
%{shared:-G -dy -z text } \
%{symbolic:-Bsymbolic -G -dy -z text }"
-/* Override the default target of the linker. */
-#define LINK_TARGET_SPEC \
- ENDIAN_SELECT("", " --oformat elf32-powerpcle", "")
-
/* Any specific OS flags. */
#define LINK_OS_SPEC "\
%{mads : %(link_os_ads) ; \
@@ -873,7 +868,6 @@ ncrtn.o%s"
{ "endfile_openbsd", ENDFILE_OPENBSD_SPEC }, \
{ "endfile_default", ENDFILE_DEFAULT_SPEC }, \
{ "link_shlib", LINK_SHLIB_SPEC }, \
- { "link_target", LINK_TARGET_SPEC }, \
{ "link_start", LINK_START_SPEC }, \
{ "link_start_ads", LINK_START_ADS_SPEC }, \
{ "link_start_yellowknife", LINK_START_YELLOWKNIFE_SPEC }, \
diff --git a/gcc/config/rs6000/sysv4le.h b/gcc/config/rs6000/sysv4le.h
index 7b1d6a1..66ee7ca 100644
--- a/gcc/config/rs6000/sysv4le.h
+++ b/gcc/config/rs6000/sysv4le.h
@@ -25,10 +25,6 @@
#undef DEFAULT_ASM_ENDIAN
#define DEFAULT_ASM_ENDIAN " -mlittle"
-#undef LINK_TARGET_SPEC
-#define LINK_TARGET_SPEC \
- ENDIAN_SELECT(" --oformat elf32-powerpc", "", "")
-
#undef MULTILIB_DEFAULTS
#define MULTILIB_DEFAULTS { "mlittle", "mcall-sysv" }
--
Alan Modra
Australia Development Lab, IBM
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [RS6000] Don't pass --oformat to ld
2015-09-02 1:35 [RS6000] Don't pass --oformat to ld Alan Modra
@ 2015-09-02 3:29 ` David Edelsohn
2015-09-24 6:24 ` Michael Ellerman
1 sibling, 0 replies; 5+ messages in thread
From: David Edelsohn @ 2015-09-02 3:29 UTC (permalink / raw)
To: Alan Modra; +Cc: GCC Patches, Michael Meissner
On Tue, Sep 1, 2015 at 9:35 PM, Alan Modra <amodra@gmail.com> wrote:
> bugzilla.redhat.com/show_bug_cgi?id=1255946 shows that gcc built with
> both powerpc64-linux and powerpc64le-linux support passes wrong linker
> options when trying to link in the non-default endian. A --oformat
> option coming from LINK_TARGET_SPEC is only correct for 32-bit.
>
> It turns out that GNU ld -m options select a particular ld emulation
> (e*.c file in ld build dir) which provides compiled-in scripts or
> selects a script from ldscripts/. Each of these has an OUTPUT_FORMAT
> statement, which does the same thing as --oformat. --oformat is
> therefore redundant when using GNU ld built this century, except
> possibly when a user overrides the default ld script with -Wl,-T and
> their script neglects OUTPUT_FORMAT, and it isn't the default output.
> I don't think it's worth fixing this possible use case.
>
> Bootstrap and testing in progress. OK for mainline assuming all is
> OK?
>
> * config/rs6000/sysv4le.h (LINK_TARGET_SPEC): Don't define.
> * config/rs6000/sysv4.h (LINK_TARGET_SPEC): Likewise.
> (LINK_SPEC, SUBTARGET_EXTRA_SPECS): Delete link_target.
Okay.
Thanks, David
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [RS6000] Don't pass --oformat to ld
2015-09-02 1:35 [RS6000] Don't pass --oformat to ld Alan Modra
2015-09-02 3:29 ` David Edelsohn
@ 2015-09-24 6:24 ` Michael Ellerman
2015-09-24 13:19 ` Alan Modra
1 sibling, 1 reply; 5+ messages in thread
From: Michael Ellerman @ 2015-09-24 6:24 UTC (permalink / raw)
To: Alan Modra; +Cc: gcc-patches, David Edelsohn, Michael Meissner
On Wed, 2015-09-02 at 11:05 +0930, Alan Modra wrote:
> bugzilla.redhat.com/show_bug_cgi?id=1255946 shows that gcc built with
> both powerpc64-linux and powerpc64le-linux support passes wrong linker
> options when trying to link in the non-default endian. A --oformat
> option coming from LINK_TARGET_SPEC is only correct for 32-bit.
>
> It turns out that GNU ld -m options select a particular ld emulation
> (e*.c file in ld build dir) which provides compiled-in scripts or
> selects a script from ldscripts/. Each of these has an OUTPUT_FORMAT
> statement, which does the same thing as --oformat. --oformat is
> therefore redundant when using GNU ld built this century, except
> possibly when a user overrides the default ld script with -Wl,-T and
> their script neglects OUTPUT_FORMAT, and it isn't the default output.
> I don't think it's worth fixing this possible use case.
>
> Bootstrap and testing in progress. OK for mainline assuming all is
> OK?
>
> * config/rs6000/sysv4le.h (LINK_TARGET_SPEC): Don't define.
> * config/rs6000/sysv4.h (LINK_TARGET_SPEC): Likewise.
> (LINK_SPEC, SUBTARGET_EXTRA_SPECS): Delete link_target.
Hi Alan,
If you could please backport this to the gcc-5-branch, that would helpful for
us (kernel folks).
That way we can use the same toolchain for building big or little endian
kernels.
cheers
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [RS6000] Don't pass --oformat to ld
2015-09-24 6:24 ` Michael Ellerman
@ 2015-09-24 13:19 ` Alan Modra
2015-09-24 13:38 ` David Edelsohn
0 siblings, 1 reply; 5+ messages in thread
From: Alan Modra @ 2015-09-24 13:19 UTC (permalink / raw)
To: Michael Ellerman; +Cc: gcc-patches, David Edelsohn, Michael Meissner
On Thu, Sep 24, 2015 at 02:24:25PM +1000, Michael Ellerman wrote:
> On Wed, 2015-09-02 at 11:05 +0930, Alan Modra wrote:
> > bugzilla.redhat.com/show_bug_cgi?id=1255946 shows that gcc built with
> > both powerpc64-linux and powerpc64le-linux support passes wrong linker
> > options when trying to link in the non-default endian. A --oformat
> > option coming from LINK_TARGET_SPEC is only correct for 32-bit.
> >
> > It turns out that GNU ld -m options select a particular ld emulation
> > (e*.c file in ld build dir) which provides compiled-in scripts or
> > selects a script from ldscripts/. Each of these has an OUTPUT_FORMAT
> > statement, which does the same thing as --oformat. --oformat is
> > therefore redundant when using GNU ld built this century, except
> > possibly when a user overrides the default ld script with -Wl,-T and
> > their script neglects OUTPUT_FORMAT, and it isn't the default output.
> > I don't think it's worth fixing this possible use case.
> >
> > Bootstrap and testing in progress. OK for mainline assuming all is
> > OK?
> >
> > * config/rs6000/sysv4le.h (LINK_TARGET_SPEC): Don't define.
> > * config/rs6000/sysv4.h (LINK_TARGET_SPEC): Likewise.
> > (LINK_SPEC, SUBTARGET_EXTRA_SPECS): Delete link_target.
>
> Hi Alan,
>
> If you could please backport this to the gcc-5-branch, that would helpful for
> us (kernel folks).
Bootstrapped and regression tested powerpc64le-linux. Is this OK for
the branch too, David?
--
Alan Modra
Australia Development Lab, IBM
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [RS6000] Don't pass --oformat to ld
2015-09-24 13:19 ` Alan Modra
@ 2015-09-24 13:38 ` David Edelsohn
0 siblings, 0 replies; 5+ messages in thread
From: David Edelsohn @ 2015-09-24 13:38 UTC (permalink / raw)
To: Alan Modra; +Cc: Michael Ellerman, GCC Patches, Michael Meissner
On Thu, Sep 24, 2015 at 8:54 AM, Alan Modra <amodra@gmail.com> wrote:
> On Thu, Sep 24, 2015 at 02:24:25PM +1000, Michael Ellerman wrote:
>> On Wed, 2015-09-02 at 11:05 +0930, Alan Modra wrote:
>> > bugzilla.redhat.com/show_bug_cgi?id=1255946 shows that gcc built with
>> > both powerpc64-linux and powerpc64le-linux support passes wrong linker
>> > options when trying to link in the non-default endian. A --oformat
>> > option coming from LINK_TARGET_SPEC is only correct for 32-bit.
>> >
>> > It turns out that GNU ld -m options select a particular ld emulation
>> > (e*.c file in ld build dir) which provides compiled-in scripts or
>> > selects a script from ldscripts/. Each of these has an OUTPUT_FORMAT
>> > statement, which does the same thing as --oformat. --oformat is
>> > therefore redundant when using GNU ld built this century, except
>> > possibly when a user overrides the default ld script with -Wl,-T and
>> > their script neglects OUTPUT_FORMAT, and it isn't the default output.
>> > I don't think it's worth fixing this possible use case.
>> >
>> > Bootstrap and testing in progress. OK for mainline assuming all is
>> > OK?
>> >
>> > * config/rs6000/sysv4le.h (LINK_TARGET_SPEC): Don't define.
>> > * config/rs6000/sysv4.h (LINK_TARGET_SPEC): Likewise.
>> > (LINK_SPEC, SUBTARGET_EXTRA_SPECS): Delete link_target.
>>
>> Hi Alan,
>>
>> If you could please backport this to the gcc-5-branch, that would helpful for
>> us (kernel folks).
>
> Bootstrapped and regression tested powerpc64le-linux. Is this OK for
> the branch too, David?
Backporting this bug fix is fine with me.
Thanks!
David
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2015-09-24 13:32 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-09-02 1:35 [RS6000] Don't pass --oformat to ld Alan Modra
2015-09-02 3:29 ` David Edelsohn
2015-09-24 6:24 ` Michael Ellerman
2015-09-24 13:19 ` Alan Modra
2015-09-24 13:38 ` David Edelsohn
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).