This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] x86: adjust relocation overflow complaint types


Andreas Schwab <schwab@suse.de> writes:

> Michael Matz <matz@suse.de> writes:
> 
> > But linking will fail:
> >
> > % ./ld/ld-new -o mm -Ttext 0 -e bios_f000 mm.o
> > mm.o: In function `bios_f000':
> > : relocation truncated to fit: R_386_PC16 against symbol `bios_f000' 
> > defined in .text section in mm.o
> >
> > This is because bfd now thinks the jump is out of range.
> 
> Which is correct, in the context of 32 bit ELF.
> 
> > I don't know how to teach bfd to make a difference between .code16 and 
> > .code32 (or .code64 for that matter) in doing the overflow checking.
> 
> The linker only knows about the 32 bit ELF format.  There is no relocation
> that can represent a pc-relative relocation that wraps around in 16 bits.

For what it's worth, I agree with Michael.  R_386_PC16 reliably wraps
around in 16-bit code.  We don't use complain_overflow_signed for
R_386_PC32 because it reliably wraps around in 32-bit code, and some
kernels rely on that.  Until and unless we can reliably determine that
we are linking 32-bit code rather than 16-bit code, I think we should
keep complain_overflow_bitfield for R_386_PC16.

I think the rule of thumb for the linker should be to diagnose code
which can never work, but to accept code which can sometimes work.  As
far as I can see, this type of error can only arise in assembler code,
and assembler programmers are generally permitted to rely on detailed
machine knowledge.

Note that we've never seen a useful case of R_386_PC8 wraparound, and
we use complain_overflow_signed for that.

Ian


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]