public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Jozef Lawrynowicz <jozef.l@mittosystems.com>
To: Alan Modra <amodra@gmail.com>, Nick Clifton <nickc@redhat.com>
Cc: binutils@sourceware.org
Subject: Re: [PATCH v5] Support SHF_GNU_RETAIN ELF section flag
Date: Thu, 19 Nov 2020 14:06:31 +0000	[thread overview]
Message-ID: <20201119140631.z7s2g5ix5oqjca3j@jozef-acer-manjaro> (raw)
In-Reply-To: <20201119051346.GD12697@bubble.grove.modra.org> <60fefc2c-422e-376b-9b6e-4bd05f23c2b4@redhat.com>

On Thu, Nov 19, 2020 at 03:43:46PM +1030, Alan Modra wrote:
> Hi Jozef,
> Some fallout from your patch.
> 
> alpha-unknown-freebsd4.7  +FAIL: SHF_GNU_RETAIN sections 22
> alpha-unknown-freebsd4.7  +FAIL: SHF_GNU_RETAIN set with numeric flag value in .section
> alpha-unknown-freebsd4.7  +FAIL: Merge SHF_GNU_RETAIN for non-unique sections
> arm-netbsdelf  +FAIL: Unknown SHF_MASKOS value in section
> arm-netbsdelf  +FAIL: -t (section details) for unknown SHF_MASKOS value in section
> arm-nto  +FAIL: Unknown SHF_MASKOS value in section
> arm-nto  +FAIL: -t (section details) for unknown SHF_MASKOS value in section
> bfin-linux-uclibc  +FAIL: SHF_GNU_RETAIN 3 (keep sections referenced by retained sections)
> bfin-linux-uclibc  +FAIL: SHF_GNU_RETAIN 6a (pull section out of lib required by SHF_GNU_RETAIN section)
> bfin-linux-uclibc  +FAIL: SHF_GNU_RETAIN 6b (pull section out of lib required by SHF_GNU_RETAIN section)
> frv-linux  +FAIL: SHF_GNU_RETAIN 3 (keep sections referenced by retained sections)
> frv-linux  +FAIL: SHF_GNU_RETAIN 6a (pull section out of lib required by SHF_GNU_RETAIN section)
> frv-linux  +FAIL: SHF_GNU_RETAIN 6b (pull section out of lib required by SHF_GNU_RETAIN section)
> hppa64-hp-hpux11.23  +FAIL: -t (section details) for unknown SHF_MASKOS value in section
> lm32-linux  +FAIL: SHF_GNU_RETAIN 3 (keep sections referenced by retained sections)
> lm32-linux  +FAIL: SHF_GNU_RETAIN 6a (pull section out of lib required by SHF_GNU_RETAIN section)
> lm32-linux  +FAIL: SHF_GNU_RETAIN 6b (pull section out of lib required by SHF_GNU_RETAIN section)
> mips64el-openbsd  +FAIL: SHF_GNU_RETAIN 5 (don't pull SHF_GNU_RETAIN section out of lib)
> mips64-linux  +FAIL: SHF_GNU_RETAIN 5 (don't pull SHF_GNU_RETAIN section out of lib)
> mips64-openbsd  +FAIL: SHF_GNU_RETAIN 5 (don't pull SHF_GNU_RETAIN section out of lib)
> mipsel-linux-gnu  +FAIL: SHF_GNU_RETAIN 5 (don't pull SHF_GNU_RETAIN section out of lib)
> mipsisa32el-linux  +FAIL: SHF_GNU_RETAIN 5 (don't pull SHF_GNU_RETAIN section out of lib)
> mips-linux  +FAIL: SHF_GNU_RETAIN 5 (don't pull SHF_GNU_RETAIN section out of lib)
> mips-sgi-irix6  +FAIL: SHF_GNU_RETAIN 5 (don't pull SHF_GNU_RETAIN section out of lib)
> powerpc64-freebsd  +FAIL: SHF_GNU_RETAIN sections 22
> powerpc64-freebsd  +FAIL: SHF_GNU_RETAIN set with numeric flag value in .section
> powerpc64-freebsd  +FAIL: Merge SHF_GNU_RETAIN for non-unique sections
> powerpc-freebsd  +FAIL: SHF_GNU_RETAIN sections 22
> powerpc-freebsd  +FAIL: SHF_GNU_RETAIN set with numeric flag value in .section
> powerpc-freebsd  +FAIL: Merge SHF_GNU_RETAIN for non-unique sections
> sparc-sun-solaris2  +FAIL: Unknown SHF_MASKOS value in section
> sparc-sun-solaris2  +FAIL: -t (section details) for unknown SHF_MASKOS value in section
> x86_64-cloudabi  +FAIL: -t (section details) for unknown SHF_MASKOS value in section
> 

On Thu, Nov 19, 2020 at 10:37:29AM +0000, Nick Clifton wrote:
> 
> And a few more:
> 
> m68k-uclinux ...
>   BIN REGRESSION: Unknown SHF_MASKOS value in section
>   BIN REGRESSION: -t (section details) for unknown
> 
> x86_64-solaris2 ...
>   BIN REGRESSION: Unknown SHF_MASKOS value in section
>   BIN REGRESSION: -t (section details) for unknown
> 
> sparc64-solaris2 ...
>   BIN REGRESSION: Unknown SHF_MASKOS value in section
>   BIN REGRESSION: -t (section details) for unknown
> 
> Cheers
>   Nick
> 

Thanks, I'm taking a look.

IIUC, Solaris doesn't support the GNU OSABI so should not be part
of the supports_gnu_osabi proc.

Also we allow mapping ELFOSABI_NONE to ELFOSABI_GNU for all targets, but
this mapping should somehow be disabled for Solaris.

Jozef

  reply	other threads:[~2020-11-19 14:06 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-11 11:41 Jozef Lawrynowicz
2020-11-17 20:29 ` Alan Modra
2020-11-19  5:13   ` Alan Modra
2020-11-19 10:37     ` Nick Clifton
2020-11-19 14:06       ` Jozef Lawrynowicz [this message]
2020-11-19 21:33         ` Jozef Lawrynowicz
2020-11-20 10:40           ` Jozef Lawrynowicz

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=20201119140631.z7s2g5ix5oqjca3j@jozef-acer-manjaro \
    --to=jozef.l@mittosystems.com \
    --cc=amodra@gmail.com \
    --cc=binutils@sourceware.org \
    --cc=nickc@redhat.com \
    /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).