public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: "Jan Beulich" <JBeulich@suse.com>
To: "Hans-Peter Nilsson" <hp@bitrange.com>
Cc: "Alan Modra" <amodra@gmail.com>,<augustine.sterling@gmail.com>,
	<binutils@sourceware.org>
Subject: Re: Ping: [PATCH] gas: fix bogus error on .org involving expression
Date: Tue, 22 Mar 2016 16:49:00 -0000	[thread overview]
Message-ID: <56F1859502000078000DF523@prv-mh.provo.novell.com> (raw)
In-Reply-To: <alpine.BSF.2.02.1603220821260.90382@arjuna.pair.com>

>>> On 22.03.16 at 13:26, <hp@bitrange.com> wrote:
> On Tue, 22 Mar 2016, Jan Beulich wrote:
>> Beyond those, however, this also revealed a few other failures:
> 
>> 4) MMIX'es pr12815-* tests both fail (they no longer produce the
>> expected or any other error). Since I have no idea what exactly
>> those tests test, I also have no idea how to deal with this.
> 
> You refer to *linker tests* checking for "a meaningful error
> message rather than SEGV" from the *linker*.  I suspect your
> assembler patches affects things it shouldn't, i.e. the it
> affects assembler output, not only fixing error cases.

While that's certainly true, it's entirely unclear to me why that would
be. Looking a little more closely, both generated object files have
empty .text and .data sections (yet only the .data section of the
second one was empty before). Assuming that what I see in the
sources are opcodes, I have absolutely no idea why that would
result in no code getting generated at all, but there also not being
any error. This, to me at least, quite clearly hints at a bug elsewhere
which this change uncovers. I could guess (and perhaps work out
by trial and error) whether one of the five uses of undefined_section
in gas/config/tc-mmix.c needs replacing or extending by considering
expr_section, but that's not the kind of work I'd like to do on code I
have no knowledge about at all.

Of course it's generally questionable whether the significantly
lower amount of expr_section uses in gas/config/tc-*.c compared
to undefined_section doesn't indicate further lurking issues. So
unless I can get some help here, I'm almost willing to give up on
this and leave .org broken (I've already managed to find an
acceptable replacement for the use case with which I ran into the
problem originally).

Jan

  reply	other threads:[~2016-03-22 16:49 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-02 11:29 Jan Beulich
2016-03-16 16:40 ` Ping: " Jan Beulich
2016-03-16 23:46   ` Alan Modra
2016-03-17  8:16     ` Jan Beulich
2016-03-22  9:19     ` Jan Beulich
2016-03-22 12:26       ` Hans-Peter Nilsson
2016-03-22 16:49         ` Jan Beulich [this message]
2016-03-23 18:55       ` augustine.sterling

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=56F1859502000078000DF523@prv-mh.provo.novell.com \
    --to=jbeulich@suse.com \
    --cc=amodra@gmail.com \
    --cc=augustine.sterling@gmail.com \
    --cc=binutils@sourceware.org \
    --cc=hp@bitrange.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).