[PATCH] D32991: [ELF] Initial migration of AVR target

Leslie Zhai via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Jun 13 21:55:43 PDT 2017


xiangzhai updated this revision to Diff 102474.
xiangzhai added a comment.

Dear Rui,

Thanks for your kind teaching!

> This patch is work-in-progress for more than a month, and looks like it needs some more time. That is understandable -- it is probably not that easy to land a first patch for a new architecture.

Thanks for your comfort, but that is not understandable, as Chinese old saying:

> 难者不会,会者不难

To me, a newbie without direction, it cost me more than a month; but to you, full stack expertise ranges from HTML/JavaScript to hard-core systems programming, might more than a hour.

> So I decided to take a little time to help you.

I feel guilty that you are so busy but still help me, nobody (can) help me in my surrounding:

> 朝の8時半から試験っていうのは慌ただしい。

and lack of sleep:

> 昼の会社のソファーでちょっと寝てしまった。やや寝不足。

I would like to sincerely thank you, if I traveled to 大阪, and when you were visiting relatives.

>   I installed avr-{gcc,objdump,as,ld} using apt-get and read the Wikipedia page of the AVR instruction set (I should have read the official instruction manual, but what's on the Wikipedia page seems correct.)

Yes, there is the same story for elf32-mips about R_MIPS_PC16 <https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob;f=bfd/elf32-mips.c;h=8c1a68eba0104315aeeb871a6233e3aef04c89fd;hb=HEAD#l260> and MIPS GOT <https://reviews.llvm.org/D31528#715906> you mentioned.

> - `.text` segments in AVR ELF outputs should be linked against absolute address zero because AVR is a Harvard-architecture microcontroller on which programs usually reside at address zero. Your output is on the other hand linked against address 0x11000. That's too high for AVR. You want to pass `-Ttext=0` to the linker so that .text sections are linked against 0.

Thanks for your hint, I also used GNU avr-ld as:

  $ avr-ld -o avr-gcc-basic-avr avr-gcc-basic-avr.o -Ttext=0



> - The AVR ELF seems to use RELA as opposed to REL. That means relocation addends are in relocation tables and not in relocated segments. So you don't need to write `getImplicitAddend()`.

bookmarked.

> - The relocation is not applied correctly. Operands of JMP or CALL instructions are 22-bit long, and it can only jump to even-numbered addresses (as all instructions are 2 byte long). So, the least significant bit is implicit and always 0. JMP or CALL instructions are in the following form in binary in an object file
> 
>   1001 0100 0000 11x0  0000 0000 0000 0000
> 
>   and after applying a `R_AVR_CALL` relocation with a 22-bit address `aa aaab cccc cccc cccc cccc` (in binary), the result should look like
> 
>   1001 010a aaaa 11xb  cccc cccc cccc cccc
> 
>   You can see the instruction encoding here: https://en.wikipedia.org/wiki/Atmel_AVR_instruction_set#Instruction_encoding
> 
>   I fixed these problems based on your patch. See it here: https://github.com/rui314/llvm-project/commit/880cd5c1c262169dc8bc6b36b5824dd2acfa2132. I confirmed that the output matches with the avr-ld.bfd's output.

I am stupid to wrongly translate elf32-avr about R_AVR_CALL <https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob;f=bfd/elf32-avr.c;h=f140aa7ed4829f8188dfdb9b98e241ae0ed4c641;hb=HEAD#l393> to NewLLD, I need to read more source code and doc.

  $ /home/zhaixiang/project/llvm/build/bin/llvm-objdump -d /tmp/basic-avr
  
  /tmp/basic-avr: file format ELF32-avr
  
  Disassembly of section .text:
  main:
         0:       0e 94 02 00  <unknown>
  
  foo:
         4:       0c 94 02 00  <unknown>

As David and Dylan suggested, I will try to implement the decode part by other patch.

> Can you update your patch based on mine?

It is my pleasure :) and I updated the patch, please review it, if LGTU, may I commit it?

Regards,
Leslie Zhai


Repository:
  rL LLVM

https://reviews.llvm.org/D32991

Files:
  ELF/InputFiles.cpp
  ELF/Target.cpp
  test/ELF/basic-avr.s
  test/lit.cfg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D32991.102474.patch
Type: text/x-patch
Size: 3009 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20170614/f11d9c55/attachment.bin>


More information about the llvm-commits mailing list