This is the mail archive of the gdb-testers@sourceware.org mailing list for the GDB 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]

[binutils-gdb] MIPS/BFD: Enable local R_MIPS_26 overflow detection


*** TEST RESULTS FOR COMMIT 7743482350c9c97484a429070db7d994a643a9eb ***

Author: Maciej W. Rozycki <macro@imgtec.com>
Branch: master
Commit: 7743482350c9c97484a429070db7d994a643a9eb

MIPS/BFD: Enable local R_MIPS_26 overflow detection

The original MIPS SVR4 psABI defines the calculation for the R_MIPS_26
relocation in a complex way, as follows[1]:

Name        Value Field    Symbol   Calculation
R_MIPS_26     4   T-targ26 local    (((A << 2) | \
                                      (P & 0xf0000000)) + S) >> 2
              4   T-targ26 external (sign-extend(A << 2) + S) >> 2

This is further clarified, by correcting typos (already applied in the
excerpt above) in the 64-bit psABI extension[2].  A note is included in
both documents to specify that for the purpose of relocation processing
a local symbol is one with binding STB_LOCAL and type STT_SECTION, and
otherwise, a symbol is external.

We have both calculations implemented for the R_MIPS_26 relocation, and
by extension also for the R_MIPS16_26 and R_MICROMIPS_26_S1 relocations,
from now on collectively called jump relocations.  However our code uses
a different condition to tell local and external symbols apart, that is
it only checks for the STB_LOCAL binding and ignores the symbol type,
however for REL relocations only.  The external calculation is used for
all RELA jump relocations.

In reality the difference matters for jump relocations referring local
MIPS16 and, as from recent commit 44d3da233815 ("MIPS/GAS: Treat local
jump relocs the same no matter if REL or RELA"), also local microMIPS
symbols.  Such relocations are not converted to refer to corresponding
section symbols instead and retain the original local symbol reference.

It can be inferred from the relocation calculation definitions that the
addend is effectively unsigned for the local case and explicitly signed
for the external case.  With the REL relocation format it makes sense
given the limited range provided for by the field being relocated: the
use of an unsigned addend expands the range by one bit for the local
case, because a negative offset from a section symbol makes no sense,
and any usable negative offset from the original local symbol will have
worked out positive if converted to a section-relative reference.  In
the external case a signed addend gives more flexibility as offsets both
negative and positive can be used with a symbol.  Any such offsets will
typically have a small value.

The inclusion of the (P & 0xf0000000) component, ORed in the calculation
in the local case, seems questionable as bits 31:28 are not included in
the relocatable field and are masked out as the relocation is applied.
Their value is therefore irrelevant for output processing, the relocated
field ends up the same regardless of their value.  They could be used
for overflow detection, however this is precluded by adding them to bits
31:28 of the symbol referred, as the sum will not correspond to the
value calculated by the processor at run time whenever bits 31:28 of the
symbol referred are not all zeros, even though it is valid as long they
are the same as bits 31:28 of P.

We deal with this problem by ignoring any overflow resulting from the
local calculation.  This however makes us miss genuine overflow cases,
where 31:28 of the symbol referred are different from bits 31:28 of P,
and non-functional code is produced.

Given the situation, for the purpose of overflow detection we can change
our code to follow the original psABI and only treat the in-place addend
as unsigned in the section symbol case, permitting jumps to offsets
128MiB and above into section.  Sections so large may be uncommon, but
still a reasonable use case.  On the other hand such large offsets from
regular local symbols are not expected and it makes sense to support
(possibly small) negative offsets instead, also in consistency with what
we do for global symbols.

Drop the (P & 0xf0000000) component then, treat the addend as signed
with local non-section symbols and also detect an overflow in the result
of such calculation with local symbols.  NB it does not affect the value
computed for the relocatable field, it only affects overflow detection.

References:

[1] "SYSTEM V APPLICATION BINARY INTERFACE, MIPS RISC Processor
    Supplement, 3rd Edition", Figure 4-11: "Relocation Types", p. 4-19
    <http://www.linux-mips.org/pub/linux/mips/doc/ABI/mipsabi.pdf>

[2] "64-bit ELF Object File Specification, Draft Version 2.5", Table 32
    "Relocation Types", p. 45
    <http://techpubs.sgi.com/library/manuals/4000/007-4658-001/pdf/007-4658-001.pdf>

	bfd/
	* elfxx-mips.c (mips_elf_calculate_relocation): <R_MIPS16_26>
	<R_MIPS_26, R_MICROMIPS_26_S1>: Drop the region bits of the
	reloc location from calculation, treat the addend as signed with
	local non-section symbols and enable overflow detection.

	ld/
	* testsuite/ld-mips-elf/jal-global-overflow-0.d: New test.
	* testsuite/ld-mips-elf/jal-global-overflow-1.d: New test.
	* testsuite/ld-mips-elf/jal-local-overflow-0.d: New test.
	* testsuite/ld-mips-elf/jal-local-overflow-1.d: New test.
	* testsuite/ld-mips-elf/jal-global-overflow.s: New test source.
	* testsuite/ld-mips-elf/jal-local-overflow.s: New test source.
	* testsuite/ld-mips-elf/mips-elf.exp: Run the new tests.


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