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

[Jim Grosbach]

> On Jul 3, 2014, at 1:51 PM, Robinson, Paul <Paul_Robinson at playstation.sony.com> wrote:
> 
>> -----Original Message-----
>> From: llvm-commits-bounces at cs.uiuc.edu [mailto:llvm-commits-
>> bounces at cs.uiuc.edu] On Behalf Of Jim Grosbach
>> 
>> The symbols need to be in the same atom, not just in the same section.
>> When there’s no subsections-via-symbols being done, the two are roughly
>> synonymous, but not in the general case.
>> 
>> -Jim
> 
> Hmm, what if SymA and SymB are labels identifying adjacent atoms (in
> the assembly source) then 'SymA - SymB' is the natural way to compute
> the size of the atom bounded by those labels.  Even if technically
> they aren't "in the same atom."  Or would you insist on having an
> end-of-atom symbol to use instead?
> —paulr

Yes, you need an assembler local end-of-atom symbol. The linker can, and will, move the atoms relative to one another, so the distance between those symbols a) isn’t known until link time and b) is not actually what you want for determining the size of anything.

-Jim

> 
>> 
>>> On Jul 2, 2014, at 12:58 PM, Daniel Sanders <Daniel.Sanders at imgtec.com>
>> wrote:
>>> 
>>> 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
>>> 
>>> _______________________________________________
>>> llvm-commits mailing list
>>> llvm-commits at cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>> 
>> 
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits