[RFA:] unconstify md_short_jump_size, md_long_jump_size (was: Re: Gas: making md_long_jump_size mutable)

[Hans-Peter Nilsson]

> From: Ian Lance Taylor <ian@wasabisystems.com>
> Date: 03 Nov 2004 20:53:10 -0500

> Hans-Peter Nilsson <hans-peter.nilsson@axis.com> writes:
> 
> > BTW, beware of the length of asm:s
> > when using CASE_VECTOR_SHORTEN_MODE; they *really* should be set
> > to max (can be done through define_asm_attributes it seems), so
> > that a branch across them can never be "shortened", not set to
> > some max length of a normal insn.
> 
> I'm working with Thumb code, which already completely breaks if the
> code includes asms with the wrong length.  The Thumb compiler depends
> upon knowing the length of every instruction in order to correctly
> pick which branch instruction to use, and in order to place the
> constant pools.

By your description it still sounds as if it's just a safe upper
limit, similar to most other attribute-length ports.  I just
mean that asms can break this safe-upper-limits handled by the
port, and they shouldn't be allowed to do that.

Hmm, this could be solved by allowing the programmer to specify
__attribute__ ((__length__)) on an asm.  That seems natural and
maybe it Just Works, but it isn't mentioned in extend.texi in
@subsection Size of an @code{asm}.  Getting off-topic here, so
moving the thread to gcc@.

> In practice I doubt many people use asms with Thumb code, as there
> isn't much the Thumb can do which gcc can not do easily enough.
> Interesting stuff would probably always be done in ARM mode.

Directives and section tricks such as used in Linux in the
get_user and put_user macros (include/asm/uaccess.h) comes to
mind.  FWIW, some people would appreciate the kernel compilable
in thumb mode; this doesn't work currently AFAIK.  Right, those
macros are unlikely to give asm length problems, they're just an
example of Creative Use of Asms.

brgds, H-P