[llvm] r211639 - Print a=b as an assignment.

[Daniel Sanders]

Yes, I think I was fairly close to finding the real bug but I need to move on to some other work before I can dig any deeper. I believe the lurking bug is in MCAssembler::evaluateFixup() or somewhere nearby. I saw this function successfully evaluate 'SymA - SymB' but return false (meaning it could not evaluate the fixup) because Target.isAbsolute() was false. I think it should have returned true when SymA and SymB were known and in the same section.

> -----Original Message-----
> From: Rafael Avila de Espindola [mailto:rafael.espindola at gmail.com]
> Sent: 02 July 2014 17:30
> To: Daniel Sanders
> Cc: Doug Gilmore; llvm-commits
> Subject: Re: [llvm] r211639 - Print a=b as an assignment.
> 
> 
> 
> Sent from my iPhone
> 
> > On Jul 2, 2014, at 11:46, Daniel Sanders <Daniel.Sanders at imgtec.com>
> wrote:
> >
> > All the SingleSource/Regression/C++/EH tests pass on MIPS32r6 with that
> commit. They also passed the most recent integrated assembler builds on
> our buildbots.
> >
> 
> Ok. Do note that that revision just made us compute more fixups at assembly
> time. This means it is very likely hiding a bug somewhere else as the
> relocations should have been producing an equivalent result. One possibility
> is that we write bad relocation info for a valid fixup. Another is that we hit a
> bug in ld.
> 
> 
> > Thanks.
> >
> >> -----Original Message-----
> >> From: Rafael Espíndola [mailto:rafael.espindola at gmail.com]
> >> Sent: 02 July 2014 15:51
> >> To: Daniel Sanders
> >> Cc: Doug Gilmore; llvm-commits
> >> Subject: Re: [llvm] r211639 - Print a=b as an assignment.
> >>
> >> The extra relocations seem to be avoided by r212101. Can you check if
> >> that makes a difference?
> >>
> >>> On 2 July 2014 10:29, Daniel Sanders <Daniel.Sanders at imgtec.com>
> wrote:
> >>> The problem appears to the contents of .gcc_except_table after
> >>> relocations are applied in the final link. I haven't figured out why
> >>> yet, but the integrated assembler is emitting five R_MIPS_32
> >>> relocations with a value of '.text' to offsets 0x7, 0xb, 0x14, 0x1c,
> >>> and 0x21. Binutils doesn't emit any relocations. Obviously these
> >>> should either be label differences or they should be resolved by the
> >>> integrated assembler but also I believe the last four ought to be at
> >>> offsets
> >> 0xc, 0x15, 0x1d, and 0x22.
> >>>
> >>>
> >>>
> >>> From: llvm-commits-bounces at cs.uiuc.edu
> >>> [mailto:llvm-commits-bounces at cs.uiuc.edu] On Behalf Of Daniel
> >>> Sanders
> >>> Sent: 02 July 2014 12:49
> >>> To: Doug Gilmore; Rafael Espíndola
> >>>
> >>>
> >>> Cc: llvm-commits
> >>> Subject: RE: [llvm] r211639 - Print a=b as an assignment.
> >>>
> >>>
> >>>
> >>> I had a look yesterday afternoon and I have an assembly file
> >>> (attached) that when used in the link for the simple_throw test,
> >>> works with binutils and crashes with '–fintegrated-as
> >>> –via-file-asm'. There seem to be a few differences between the two
> >>> objects but the assignments seemed to be working fine. The most
> >>> suspicious looking difference was the two bytes difference in the
> .eh_frame section.
> >>> Patching the .eh_frame section to match the binutils output with a
> >>> hex editor doesn't seem to fix the problem though. That's as far as
> >>> I've got at
> >> the moment, I'll take another look when I get chance.
> >>>
> >>>
> >>>
> >>>> -----Original Message-----
> >>>
> >>>> From: llvm-commits-bounces at cs.uiuc.edu [mailto:llvm-commits-
> >>>
> >>>> bounces at cs.uiuc.edu] On Behalf Of Doug Gilmore
> >>>
> >>>> Sent: 29 June 2014 22:55
> >>>
> >>>> To: Rafael Espíndola
> >>>
> >>>> Cc: llvm-commits
> >>>
> >>>> Subject: RE: [llvm] r211639 - Print a=b as an assignment.
> >>>
> >>>
> >>>>> From: Rafael Espíndola [rafael.espindola at gmail.com]
> >>>
> >>>>> Sent: Sunday, June 29, 2014 1:25 PM
> >>>
> >>>>> To: Doug Gilmore
> >>>
> >>>>> Cc: llvm-commits
> >>>
> >>>>> Subject: Re: [llvm] r211639 - Print a=b as an assignment.
> >>>
> >>>
> >>>>>>> Is this using mips16 or micromips? ".set mips16" in particular
> >>>
> >>>>>>> doesn't seem to be implemented for example.
> >>>
> >>>>>> It is just normal mips32.
> >>>
> >>>
> >>>>> Interesting. The original message (r170279) made it look like a
> >>>>> mip16  issue.
> >>>
> >>>
> >>>>> Do you have a testcase where gas produces a working file but MC is
> >>>
> >>>> broken?
> >>>
> >>>> There doesn't appear to be.  Sorry for the lack of debugging input
> >>>> on our
> >>>
> >>>> end, we are a bit swamped at the moment.  In the next day or so we
> >>>> should
> >>>
> >>>> be in the position to put more resources on the problem so that we
> >>>> can find
> >>>
> >>>> the root cause.
> >>>
> >>>
> >>>> Thanks,
> >>>
> >>>
> >>>> Doug
> >>>
> >>>
> >>>>> Cheers,
> >>>
> >>>>> Rafael
> >>>
> >>>
> >>>> _______________________________________________
> >>>
> >>>> llvm-commits mailing list
> >>>
> >>>> llvm-commits at cs.uiuc.edu
> >>>
> >>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits