m68k Coldfire and PC-relative addressing distances

m68k Coldfire and PC-relative addressing distances

[Florian Weimer]

How does the Coldfire m68k subtarget and sure that displacements in PIC
code are within the addressable range?

We have a source file in glibc that fails at assembly because it
contains a branch that is out of range with -fpic.  The GAS error is:

…/iso-2022-jp.s: Fatal error: Tried to convert PC relative branch to absolute jump

(Not sure if this is actually a branch, the diagnostic isn't really
helpful.)

The -fPIC option does not help, and -fpic -mpcrel ICEs at the end of
m68k.cc:sched_attr_op_type.  The op variable at this point is:

(mem/u:HI (const:SI (plus:SI (symbol_ref:SI ("__jisx0212_to_ucs_idx") [flags 0x40] <var_decl 0x7ffff761df30 __jisx0212_to_ucs_idx>)
            (const_int 2 [0x2]))) [2 MEM[(const struct jisx0212_idx *)&__jisx0212_to_ucs_idx].end

The iso-2022-jp.c source file has some large data tables, so it's
probably not surprising that -fpic doesn't work.

Thanks,
Florian

Re: m68k Coldfire and PC-relative addressing distances

[Richard Biener]

On Tue, Jul 11, 2023 at 11:36 AM Florian Weimer via Gcc <gcc@gcc.gnu.org> wrote:
>
> How does the Coldfire m68k subtarget and sure that displacements in PIC
> code are within the addressable range?

There is usually a branch shortening pass relying on correct
instruction lengths.

I suggest to file a bugreport with preprocessed sources as testcase.

Richard.

> We have a source file in glibc that fails at assembly because it
> contains a branch that is out of range with -fpic.  The GAS error is:
>
> …/iso-2022-jp.s: Fatal error: Tried to convert PC relative branch to absolute jump
>
> (Not sure if this is actually a branch, the diagnostic isn't really
> helpful.)
>
> The -fPIC option does not help, and -fpic -mpcrel ICEs at the end of
> m68k.cc:sched_attr_op_type.  The op variable at this point is:
>
> (mem/u:HI (const:SI (plus:SI (symbol_ref:SI ("__jisx0212_to_ucs_idx") [flags 0x40] <var_decl 0x7ffff761df30 __jisx0212_to_ucs_idx>)
>             (const_int 2 [0x2]))) [2 MEM[(const struct jisx0212_idx *)&__jisx0212_to_ucs_idx].end
>
> The iso-2022-jp.c source file has some large data tables, so it's
> probably not surprising that -fpic doesn't work.
>
> Thanks,
> Florian
>

Re: m68k Coldfire and PC-relative addressing distances

[Florian Weimer]

* Richard Biener:

> On Tue, Jul 11, 2023 at 11:36 AM Florian Weimer via Gcc <gcc@gcc.gnu.org> wrote:
>>
>> How does the Coldfire m68k subtarget and sure that displacements in PIC
>> code are within the addressable range?
>
> There is usually a branch shortening pass relying on correct
> instruction lengths.
>
> I suggest to file a bugreport with preprocessed sources as testcase.

Fair enough, I filed PR110627.

Thanks,
Florian

Re: m68k Coldfire and PC-relative addressing distances

[Jeff Law]

On 7/11/23 04:48, Richard Biener via Gcc wrote:
> On Tue, Jul 11, 2023 at 11:36 AM Florian Weimer via Gcc <gcc@gcc.gnu.org> wrote:
>>
>> How does the Coldfire m68k subtarget and sure that displacements in PIC
>> code are within the addressable range?
> 
> There is usually a branch shortening pass relying on correct
> instruction lengths.
Generally true, but not so on the m68k unless something significant has 
changed.

On the m68k all this stuff is handled by the assembler.

jeff

Re: m68k Coldfire and PC-relative addressing distances

[Joseph Myers]

[-- Attachment #1: Type: text/plain, Size: 867 bytes --]

On Tue, 11 Jul 2023, Florian Weimer via Gcc wrote:

> * Richard Biener:
> 
> > On Tue, Jul 11, 2023 at 11:36 AM Florian Weimer via Gcc <gcc@gcc.gnu.org> wrote:
> >>
> >> How does the Coldfire m68k subtarget and sure that displacements in PIC
> >> code are within the addressable range?
> >
> > There is usually a branch shortening pass relying on correct
> > instruction lengths.
> >
> > I suggest to file a bugreport with preprocessed sources as testcase.
> 
> Fair enough, I filed PR110627.

I think this is technically a regression that appeared around 23 May 
(although almost surely really a latent bug that simply got reintroduced 
on that code by some other changes at that time in the compiler - this 
sort of error has come and gone before).

https://sourceware.org/pipermail/libc-testresults/2023q2/011304.html

-- 
Joseph S. Myers
joseph@codesourcery.com