From: Jakub Jelinek <jakub@redhat.com>
To: Mark Wielaard <mark@klomp.org>
Cc: Tom de Vries <tdevries@suse.de>, dwz@sourceware.org
Subject: Re: [PATCH][testsuite] Fix pr25109.sh on riscv64
Date: Fri, 26 Feb 2021 11:35:45 +0100 [thread overview]
Message-ID: <20210226103545.GW4020736@tucnak> (raw)
In-Reply-To: <20210226102831.GD3014@wildebeest.org>
On Fri, Feb 26, 2021 at 11:28:31AM +0100, Mark Wielaard wrote:
> On Fri, Feb 26, 2021 at 11:14:23AM +0100, Tom de Vries wrote:
> > On riscv64, I run into:
> > ...
> > cc main.c no-multifile-prop-dw.S -o no-multifile-prop
> > no-multifile-prop-dw.S: Assembler messages:
> > no-multifile-prop-dw.S:25: Error: non-constant .uleb128 is not supported
> > make: *** [Makefile:99: no-multifile-prop] Error 1
> > ...
> >
> > Fix this by allowing to fail to build the test-case, and marking it as
> > unsupported.
> >
> > Any comments?
>
> If it doesn't even build then there is not much else we can do than
> skip it. So I would push this.
>
> But this is a little surprising.
> The construct seems like it is represented by a known constant at compile time:
>
> .uleb128 .Lexpr_end4 - .Lexpr_start3/* expression */
> .Lexpr_start3:
> .byte 0xf2 /* DW_OP_GNU_implicit_pointer */
> .4byte .Llabel2
> .sleb128 0
> .Lexpr_end4:
>
> There isn't anything between the two labels that can have a variable
> size. So it might be a good idea to file a bug report against
> binutils as for not allowing this on riscv64.
I believe the riscv people explain it by aggressive linker optimizations
that make those not to work, but perhaps that applies to normal sections,
but don't see how can that apply to .debug* sections...
They shouldn't be doing any kind of aggressive linker relaxations on
.debug*.
Jakub
next prev parent reply other threads:[~2021-02-26 10:35 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-26 10:14 Tom de Vries
2021-02-26 10:28 ` Mark Wielaard
2021-02-26 10:35 ` Jakub Jelinek [this message]
2021-02-26 11:59 ` Tom de Vries
2021-02-26 12:00 ` Jakub Jelinek
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=20210226103545.GW4020736@tucnak \
--to=jakub@redhat.com \
--cc=dwz@sourceware.org \
--cc=mark@klomp.org \
--cc=tdevries@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).