[llvm-commits] ARM ELF disassembly with integrated-as

[Greg Fitzgerald]

Hi all,

 

Attached is a new patch to add Mapping Symbols to the ARM ELF files.  By
adding these symbols we can easily compare the disassembly between LLVM's
integrated assembler versus using GCC.  Without this patch, there's so much
noise that such an analysis is difficult to say the least. 

 

Compared to the previous patch, this one is small, simple and comes with a
unit-test.  It doesn't move any files around and does its best to be a good
citizen with regard to coding style.  Could you please review?

 

Thank you for your time,

Greg Fitzgerald

 

---
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by
The Linux Foundation

 

 

From: jvoung at google.com [mailto:jvoung at google.com] On Behalf Of Jan Voung
Sent: Friday, October 19, 2012 10:55 AM
To: Greg Fitzgerald
Cc: llvm-commits at cs.uiuc.edu
Subject: Re: [llvm-commits] ARM ELF disassembly with integrated-as

 

Oops forgot to reply-all originally.  +list now.

 

On Thu, Oct 18, 2012 at 11:46 AM, Greg Fitzgerald <gregf at codeaurora.org>
wrote:

Jan,

 

Thanks so much for the review.

 

> Does this patch handle switching between ARM and thumb code?  E.g., from
the llvm test "test/MC/ARM/mode-switch.s"

 

No, afraid not.  Is there a concept of switching between ARM and Thumb
within LLVM?  As I understand, the triple forces it one way or the other.
Regarding that usage within an assembly file, LLVM currently doesn't support
ARM assembly files targeting ELF, only MachO.  If possible, I'd prefer not
to piggyback that feature on this patch, and then address it at the time we
add support for parsing ARM ELF assembly (for example, parsing the
.eabi_attribute directive).

 

 

I thought there was a concept of switching, based on what
"test/MC/ARM/mode-switch.s" does. The CHECKs in the test are the same with
both the arm and thumb triples.

 

> Do you have a specific test that the mapping symbols really do get
emitted, with the right type, binding, etc.?  Perhaps the test should also
show that it handles switching between $a, $d, and $t, and squashes
duplicates as you had checks for "AlreadySetData", etc.

 

Not yet.  That'd be a good addition.   And right, a test that also
demonstrates why AlreadySetData needs to be there would be good.  As it
turns out, only one of those is really needed, and the others are there to
claim the functions are idempotent.

 

> One suggestion: In 2010-11-30-reloc-movt.ll, where the symbols have
shifted, it might be more obvious that the change is correct if it had also
"OBJ" check for a "Symbol 12", with a "OBJ-NEXT" for foo, or bar, whatever
it was looking for, similar to what is done in "elf-reloc-01.ll".

 

Good tip, I'll do that.

 

Thanks,

Greg

 

 

From: jvoung at google.com [mailto:jvoung at google.com] On Behalf Of Jan Voung
Sent: Wednesday, October 17, 2012 10:23 PM
To: Greg Fitzgerald
Subject: Re: [llvm-commits] ARM ELF disassembly with integrated-as

 

Hi Greg,

 

Thanks for working on this!

 

 

Two questions:

(1) Does this patch handle switching between ARM and thumb code?  E.g., from
the llvm test "test/MC/ARM/mode-switch.s"

 

(2) Do you have a specific test that the mapping symbols really do get
emitted, with the right type, binding, etc.?  Perhaps the test should also
show that it handles switching between $a, $d, and $t, and squashes
duplicates as you had checks for "AlreadySetData", etc.

 

 

One suggestion: In 2010-11-30-reloc-movt.ll, where the symbols have shifted,
it might be more obvious that the change is correct if it had also "OBJ"
check for a "Symbol 12", with a "OBJ-NEXT" for foo, or bar, whatever it was
looking for, similar to what is done in "elf-reloc-01.ll".

 

- Jan

 

On Wed, Oct 17, 2012 at 8:20 PM, Greg Fitzgerald <gregf at codeaurora.org>
wrote:

> [LLVMdev] R_ARM_ABS32 disassembly with integrated-as

Please review the attached patch.

Highlights:
* LLVM now emits an ARM ELF with the same mapping symbols as GCC
* Because of that, you can now objdump ARM ELF files and not see gibberish
code where jump tables are stored
* And having those symbols alleviates concerns Tim mentioned regarding
linking.

Lowlights:
* Had the choice of either dumping ARMELFStreamer into the MC layer, or
pulling MCELFStreamer into the public include directory (for MC).  I chose
the latter.  It seems quite a bit cleaner, but at the expense of maybe
exposing an object that might not be ready to move out of its anonymous
namespace.
* Needed to update a few somewhat-unrelated unit tests.  Mostly just
updating references in the symbol table to account for the 3 mapping symbols
at the start of each file (.text=$a, .data=$d, .bss=$d).  These are probably
worth the most scrutiny.

Thanks,
Greg

---
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted
by The Linux Foundation


_______________________________________________
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/20121109/33f3c1da/attachment.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ArmElfMappingSymbols.patch.txt
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20121109/33f3c1da/attachment.txt>