public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
From: Max Filippov <jcmvbkbc@gmail.com>
To: daniel@wegemer.com
Cc: gcc-help@gcc.gnu.org
Subject: Re: Modify Xtensa instruction relaxation
Date: Thu, 3 Aug 2023 12:21:54 -0700	[thread overview]
Message-ID: <CAMo8BfLnHpL=chu-Gu3ZGnwd2HTfokzQAxaunJ_cix2G0jmdfw@mail.gmail.com> (raw)
In-Reply-To: <1a7a6c21e8e9cbc061af7ff96ab5eb99@wegemer.com>

On Thu, Aug 3, 2023 at 6:04 AM <daniel@wegemer.com> wrote:
> But now I'm hitting an assertion in write.c: "Internal error in
> cvt_frag_to_fill"
>
> I checked, its this part of the code:
>      gas_assert (fragP->fr_next == NULL || (fragP->fr_next->fr_address -
> fragP->fr_address == fragP->fr_fix));
>
> fr_next seems to be ok, but the difference between fr_address seems to
> be off by 3, fr_fix seems to be 3 higher then the difference of
> fr_address in the current and the next fragP.
>
> Any idea how that can be the case?

If you change the frags too late in the process their addresses
may have been used by that time to make decisions like where
to put a literal so it's reachable or whether a trampoline is needed
for a jump.

> Strangely, if I leave the check for is_last_fragment away, it works.

It may fail later in opcode conversion to binary form if new offsets
won't fit, or it may generate code that references wrong addresses.
E.g. try to have a jump around the code that is modified by your
change and see whether the disassembly still looks correct.

-- 
Thanks.
-- Max

      reply	other threads:[~2023-08-03 19:22 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-31 19:20 daniel
2023-07-31 19:41 ` Max Filippov
2023-07-31 19:57   ` daniel
2023-07-31 20:20     ` Max Filippov
2023-08-03 13:04       ` daniel
2023-08-03 19:21         ` Max Filippov [this message]

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='CAMo8BfLnHpL=chu-Gu3ZGnwd2HTfokzQAxaunJ_cix2G0jmdfw@mail.gmail.com' \
    --to=jcmvbkbc@gmail.com \
    --cc=daniel@wegemer.com \
    --cc=gcc-help@gcc.gnu.org \
    /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).