[llvm-commits] [llvm] r136855 - in /llvm/trunk: lib/MC/ELFObjectWriter.cpp lib/Target/X86/MCTargetDesc/X86AsmBackend.cpp test/MC/ELF/x86_64-reloc-sizetest.s

[Jason Kim]

On Thu, Aug 4, 2011 at 5:18 AM, Rafael Ávila de Espíndola <
rafael.espindola at gmail.com> wrote:

> nit: remove trailing white space:
> > +
> > +    // Check that the upper bits are either all 0 or all 1's
> > +    switch (Size) {
> > +    case 1:
> > +      assert((isInt<8>(Value) || isUInt<8>(Value))&&
> > +             "Value does not fit in a 1Byte Reloc");
> > +      break;
> > +    case 2:
> > +      assert((isInt<16>(Value) || isUInt<16>(Value))&&
> > +             "Value does not fit in a 2Byte Reloc");
> > +      break;
> > +    case 4:
> > +      assert((isInt<32>(Value) || isUInt<32>(Value))&&
> > +             "Value does not fit in a 4Byte Reloc");
> > +      break;
> > +    }
> > +
>
> Note that this is asserting on the symbol value, not the addend as the
> old assert was. The assert for the addend should only depend on the ELF
> format being 32 (isInt<32>) or 64 bits (isInt<64>), since that is the
> only real constraint that the file format has.
>
> For the symbol value your asserts looks correct, but you might want to
> account for the relocation being signed or unsigned too.
>
>
Do you mean preserve the signedness of the target specific reloc tag
specification? Hmm..


> This also found a bug on the elf dumper, since it is only printing 32
> bits of the addend.
>
> I will try to take a look at adding back an assert for the addend and
>

My initial idea was to add a new virtual at ELFObjectWriter-
 CheckRelocSizeBounds(ERE)  but decided against it.
If you really want to check the addend also, perhaps its best done there.
What do you think?

-jason


> the elf dumper problem. Can you take a look at the making the symbol
> value assert more strict?
>
> Cheers,
> Rafael
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20110804/9a48c027/attachment.html>