public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Thiemo Seufer <ths@networkno.de>
To: binutils@sourceware.org, rsandifo@nildram.co.uk
Subject: Re: Fix code alignment for mixed mips16/nomips16 files
Date: Sat, 08 Dec 2007 18:41:00 -0000	[thread overview]
Message-ID: <20071208184105.GB12436@networkno.de> (raw)
In-Reply-To: <87ir396th3.fsf@firetop.home>

Richard Sandiford wrote:
> At the moment, ".align x" always fills with 0s on MIPS.  This is a
> problem if, for example, you're writing MIPS16 assembly code in which
> a function has multiple entry points, and in which one entry point falls
> through to another.  The natural thing would be to insert ".align 2"
> before each entry point, but 0 is not a nop in MIPS16 code.
> 
> This patch adjusts mips_align's prototype so that the function can tell
> if the default fill pattern is being used.  If so, it uses code alignment
> for code segments (just like the standard .align does) otherwise it
> continues to behave as it does now.  I think all callers of mips_align
> besides s_align should be treated as wanting the default fill sequence
> rather than a zero fill sequence.  (The choice is equivalent for
> non-code segments.)
> 
> Also, mips_handle_align currently uses the final MIPS16 setting for
> all code fills.  For .aligns, we should instead use whatever mode was
> in effect at the time the .align was assembled, and for end-of-file
> aligmments, we should use whatever mode was in effect when a .align
> or instruction was last assembled in that segment.
> 
> The patch records the last .align or instruction ISA mode for
> a segment by adding a "mips16?" field to tc_segment_info_data.
> It allows a per-relaxation choice of ISA mode by defining NOP_OPCODE
> as a "mips16?" value.  mips_handle_align can then check the first
> variable byte instead of mips_opts.mips16.
> 
> Tested on mips64-linux-gnu.  OK to install?
> 
> Richard
> 
> 
> gas/
> 	* config/tc-mips.h (mips_nop_opcode): Declare.
> 	(NOP_OPCODE): Define.
> 	(mips_segment_info): New structure.
> 	(TC_SEGMENT_INFO_TYPE): Use it instead of insn_label_list.
> 	* config/tc-mips.c (label_list): Adjust for new TC_SEGMENT_INFO_TYPE.
> 	(mips_record_mips16_mode): New function.
> 	(install_insn): Call it.
> 	(mips_align): Likewise.  Turn the fill argument into an "int *".
> 	Use frag_align_code for code segments if no fill data is given.
> 	(s_align): Adjust call accordingly.
> 	(mips_nop_opcode): New function.
> 	(mips_handle_align): Use the first variable byte to decide which
> 	nop sequence is needed.  Use md_number_to_chars and mips16_nop_insn.
> 
> gas/testsuite/
> 	* gas/mips/align2.s, gas/mips/align2.d, gas/mips/align2-el.d: New
> 	tests.
> 	* gas/mips/mips.exp: Run them.

Ok.


Thiemo

      reply	other threads:[~2007-12-08 18:41 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-12-08 16:29 Richard Sandiford
2007-12-08 18:41 ` Thiemo Seufer [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=20071208184105.GB12436@networkno.de \
    --to=ths@networkno.de \
    --cc=binutils@sourceware.org \
    --cc=rsandifo@nildram.co.uk \
    /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).