Movatterモバイル変換
[0]ホーム
This is the mail archive of thebinutils@sources.redhat.commailing list for thebinutils project.
Re: MIPS patch to correct the size of %neg() fixups
Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de> writes:> Richard Sandiford wrote:> > As I understand it, the relocation field should be determined> > by the outermost operator (%hi() in this case) and all three> > fixups should use that size.> > That's probably a too simple approach for the genaral case, since e.g. a> > R_MIPS_GPREL(sym)> R_MIPS_64(null)> > sequuence is supposed to produce a 64bit addend.Well, I'll probably missing your point here, but the sequence writesto a 64-bit relocation field because that's what the final relocation(R_MIPS_64) specifies. And my patch will give it a 64-bit fixup.> AFAICS the relocation field size in all relocations of a triple should> be the largest one encountered there.It sounds like you're saying that: R_MIPS_GPREL16 R_MIPS_SUB R_MIPS_HI16should be treated as having a 64-bit relocation field, but that'sexactly what I'm trying to avoid. ;)The ABI says: The implication [...] is that a relocation type consists of two components. The first component is the operation to be performed [...]. The second component is a specification of field to be relocated, which is relevant only for the first operation in the sequence (where it may specify an addend for the Elf64_Rel relocation) and the last operation in a sequence (where it specifies the field rewritten by the relocation).which certainly implies to me that the middle relocation type ina three-relocation sequence has no effect on determining the field.I read it as saying that the final relocation type (on its own)determines the field written. And I think that's what mattersin terms of the fixups.Although I haven't really looked into it yet, I suspect it mightbe better to have a single fixup for the complete relocation.But I wanted something that would be OK for 2.14.Richard
[8]ページ先頭