Implements the missing relocation types for AVR target.
The results have been cross-checked with binutils.
Original patch by LemonBoy. Some changes by me.
aykevl on Apr 23 2020, 11:57 AM.Authored by
Yes - there is no document I have been able to find either. As you note, the best we can do is compile and dump the sources under AVR-GCC and see that the expectations match up.
This patch is really good, the test coverage is nice too (TIL --defsym=).
I will have a deeper review of the specific relocation bitwise expressions for correctness this week.
I've checked over all of the relocation logic, cross referenced with both the AVR ISA manual and the AVR LLVM fixture implementations in AVRAsmBackend.cpp - everything looks consistent to me.
I think there are a few missing check[U]Int calls (I've left couple comments comments) but other than that, everything looks good from an AVR perspective.
I actually wrote a patch very similar to this one (but not implementing as many relocations). It's here: https://gist.github.com/aykevl/ce3c04e1175d9602c9dfaf0cf91298ba
It's heavily documented. Feel free to use it however you wish. I have an inline comment for what I suspect is a bug in this patch.
I have attached a patch that addresses review comments:
With these changes, I can successfully link at least some TinyGo compiled programs.
@LemonBoy from your previous comment it looks like you don't intend to work on this further, is that correct? If so, are you okay with me taking over this patch, thus uploading this new patch for example?
@MaskRay thanks! I wasn't aware of that option.
Changes I made:
I've confirmed that # is not a valid comment char in the original AVR assembler. See: http://ww1.microchip.com/downloads/en/devicedoc/40001917a.pdf#page=12 (section 4.3). I don't know why # at the start of a line works as a comment, perhaps these lines are removed by llvm-lit?
Thanks for the update. All look good to me now.
MCParser supports # in the line beginning.
6.12 of the document you linked says "Unsurprisingly, this directive does exactly nothing. The only reason it exists is that it is required by the ANSI C standard" but I think that is not true. GCC/clang will report error: invalid preprocessing directive