public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Alan Modra <amodra@gmail.com>
To: "H.J. Lu" <hjl.tools@gmail.com>
Cc: Michael Matz <matz@suse.de>, Binutils <binutils@sourceware.org>
Subject: Re: [PATCH] Use GCC LTO wrapper to get real symbols from LTO IR objects
Date: Thu, 13 Feb 2020 08:15:00 -0000	[thread overview]
Message-ID: <20200213081503.GF29647@bubble.grove.modra.org> (raw)
In-Reply-To: <CAMe9rOpAgwgk8o2gyHYsd8rh7oCzS5J9Lv8-dU52b7S3krd5qA@mail.gmail.com>

On Tue, Feb 11, 2020 at 09:03:18AM -0800, H.J. Lu wrote:
> On Tue, Feb 11, 2020 at 8:07 AM Michael Matz <matz@suse.de> wrote:
> >
> > Hi,
> >
> > On Mon, 10 Feb 2020, H.J. Lu wrote:
> >
> > > > Wow, that's a lot of work to get proper symbol type.  What happens if
> > >
> > > Very true.  I couldn't come up with a better solution without changing
> > > plugin API.
> >
> > Then, it should perhaps be changed?  The cure without that (i.e. your
> > patch) looks worse than the disease (temporary files, hardcoding path
> > layouts, dependence on gcc installed) :-/

Yes, I expect to see complaints about the paths.  You can also break
the support in more creative ways.  For example, when using
CC="${gccdir}gcc/xgcc -B${gccdir}gcc/" and a more complex CXX to build
binutils with a bleeding edge gcc.  I also have cross compilers
installed for a number of targets, and I used a trick to save building
some 32-bit targets that have a 64-bit bi-arch compiler.  Like this:

$ cat /usr/local/bin/s390-linux-gcc
#! /bin/sh
case " $@ " in
*" -m64 "*) p= ;;
" -V "*) shift; p="-V $1 -m31 "; shift;;
" -V"*) p="$1 -m31 "; shift;;
*) p="-m31 ";;
esac
exec s390x-linux-gcc ${p}"$@"
EOF

After HJ's patch I see
s390-linux  +FAIL: Build liblto-12.a
s390-linux  +FAIL: Build liblto-14.a
s390-linux  +FAIL: Build liblto-15.a
s390-linux  +FAIL: PR ld/19317 (1)
s390-linux  +FAIL: Build libpr20267a.a
s390-linux  +FAIL: Build libpr20267b.a
s390-linux  +FAIL: Build pr22751.a
s390-linux  +FAIL: pr25355.o
s390-linux  +FAIL: Build libpr15146a.a
s390-linux  +FAIL: Build libpr15146d.a
s390-linux  +FAIL: Build libpr16746b.a

Most of these are due to dejagnu not liking unexpected output, with
the newly built ar spitting out errors like the following:

Executing on host: sh -c {/home/alan/build/gas/s390-linux/ld/../binutils/ar  -rc --plugin /home/local/bin/../libexec/gcc/s390x-linux/8.1.1/liblto_plugin.so tmpdir/liblto-12.a tmpdir/lto-12c.o 2>&1}  /dev/null ld.tmp (timeout = 300)
spawn [open ...]
/home/local/bin/../lib/gcc/s390x-linux/8.1.1/../../../../s390x-linux/bin/ld: relocatable linking with relocations from format elf32-s390 (/tmp/cc32KkFydebugobjtem) to format elf64-s390 (/tmp/cc3YsYNydebugobj) is not supported
collect2: error: ld returned 1 exit status
lto-wrapper: fatal error: /home/local/bin/s390x-linux-gcc returned 1 exit status
compilation terminated.
bfd plugin: lto-wrapper failed

Oh well, time to get rid of my hacky s390-linux-gcc.

> > I know why you wrote the patch as is, but ... ugh.
> 
> I think plugin API should be extended.  In the meantime, we have a problem
> to solve.

-- 
Alan Modra
Australia Development Lab, IBM

  reply	other threads:[~2020-02-13  8:15 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-10 14:24 H.J. Lu
2020-02-10 21:31 ` H.J. Lu
2020-02-10 23:02   ` Alan Modra
2020-02-11  1:23     ` H.J. Lu
2020-02-11  2:31       ` Alan Modra
2020-02-11 12:21         ` H.J. Lu
2020-02-11 22:05           ` [PATCH] Plugin: Treat each object as independent H.J. Lu
2020-02-11 22:22             ` Alan Modra
2020-02-11 16:07       ` [PATCH] Use GCC LTO wrapper to get real symbols from LTO IR objects Michael Matz
2020-02-11 17:04         ` H.J. Lu
2020-02-13  8:15           ` Alan Modra [this message]
2020-03-10 14:55       ` Richard Biener

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200213081503.GF29647@bubble.grove.modra.org \
    --to=amodra@gmail.com \
    --cc=binutils@sourceware.org \
    --cc=hjl.tools@gmail.com \
    --cc=matz@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).