[llvm-commits] Proof of concept patch for unifying the .s/ELF emission of .ARM.attributes
Rafael Espindola
espindola at google.com
Wed Oct 13 09:02:08 PDT 2010
> I hope you are kidding about that! Do you like converting between hex
> and decimal just for testing?
> I added it just for sanity checking the magic constants from the arch.
> It sucks to have to convert 0x70000003 to decimal and back again, just
> for testing purposes (and then forgetting two weeks later what the
> magic number was supposed to be!
> 0x700000003 is recognizable. The decimal form isn't (unless you are strange! :-)
No, in fact I like hex so much that I would like it always on. That is
one of the reasons why I don't like the option.
>> Is enough of the asm parser working for
>> 2010-10-08-mc-asm-header-obj-test.ll to be written in assembly and use
>> llvm-mc?
>
> I haven't tested it that way yet. I suppose I'll give it a shot.
> Regardless, I'd argue that it's beyond the scope of these two patches.
If the asm printer is already working you should probably use it for
testing, as there is a lot less code involved in running llvm-mc.
>> How much work is it to complete WriteNopData? If you write the test in
>> assembly, can the assert stay?
>
> I think I'll separate that out into 1+ new patches - My next patch in
> sequence was to fill out enough of the ARMMCEncode to handle mov r0,
> #0 and bx lr
> So might as well as add in Nop generation there as well
That would be good. Thanks.
> So I guess I'll do the following.
> 1. Fix up elf-dump
> 2. Fix up Nop generation
> 3. Reland this patch in sequence.
>
> Does this sound like a sane plan?
Yes.
>
> Thanks for feedback!
> -Jason
>
Cheers,
--
Rafael Ávila de Espíndola
More information about the llvm-commits
mailing list