similar to: Compile with both arm and thumb mode

Hello everyone, this is most likely Arm specific, but could affect other targets where there is a somewhat complex relationship between the triple and mcpu option. At present when clang is used as a linker driver for the gold-plugin and when using and an explicit -mcpu is not given to clang, then clang will always generate a -Wl,-plugin-opt=mcpu=<default CPU> where the default CPU is based

On 3/15/2018 9:43 AM, Peter Smith via llvm-dev wrote: > Hello everyone, this is most likely Arm specific, but could affect > other targets where there is a somewhat complex relationship between > the triple and mcpu option. > > At present when clang is used as a linker driver for the gold-plugin > and when using and an explicit -mcpu is not given to clang, then clang > will

Hi Nowadays I am using LLVM to do ARM binary analysis. I was wondering is llvm available to provide some debugging information on the mode of ARM. For example, llvm-dwarfdump could dump some instructions information for debugging. Is it able to know the mode for each instruction? Or we may write some llvm pass to help us to know the instruction mode? Any suggestions are welcomed. Many Thanks

Tim, How about the below option ? 1. Specify an existing generic armv7 CPU or the CPU which is close my custom variant. My custom variant can be treated as "cortex-a9" + hwdiv. So my CPU here is "cortex-a9" 2. Specify the ".arch_extension idiv" which is available as an extension for my custom variant. 3. Teach LLVM & Clang about your CPU's

Hi, I wanted to know if it was possible to force ARM backend to compile a function in ARM while the rest is in Thumb mode. I tried the attributes which is used in GCC but it doesn't work. Here is what I tried: https://pastebin.com/jCr5LPUY Thanks in advance, Uvekilledkenny -------------- next part -------------- An HTML attachment was scrubbed... URL:

Hello Leslie, The errors coming from the gnu assembler are due to the file being assembled in Arm state, to get rid of the errors you'll either need to put a .thumb directive in the file, or pass -mthumb to the assembler via arm-linux-gnu-gcc -Wa,-mthumb (I think). I'm not able to explain what you are seeing in your print out as it doesn't quite match the map file. Looking at your

Hi Divacky, I have an armv7 variant that supports hardware division (extension). For my variant, I use ".cpu cortex-a9" and division attribute(.eabi_attribute 44, 2 @ Tag_DIV_use) to let the assembler do the right thing if it encounters a division instruction. With your path, the .cpu directive is used to fetch the available features of a CPU and ignores the eabi attributes. What

Thanks for the example, that is very useful in working out the overall scope of the problem, which is now wider than I thought it was. I've put some comments inline. On 15 March 2018 at 19:12, Friedman, Eli <efriedma at codeaurora.org> wrote: > On 3/15/2018 9:43 AM, Peter Smith via llvm-dev wrote: >> >> Hello everyone, this is most likely Arm specific, but could affect

Yes, exactly this: > Sure, none of the cortex-m cores support ARM mode. Try cortex-a{5,7,8,9,15,53} etc and you'll see it works. Sorry for being a bit vague and unclear here: yes, I should have said cortex-a{5,7,8,9,15,53}. I was just having a play with this native compiler: gcc-5 (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.10) 5.4.0 20160609 when I noticed that -Os gives me Thumb on

My understanding is that whether a gcc toolchain defaults to ARM or Thumb is a configuration time decision by whomever builds the toolchain. The linaro arm-linux-gnueabihf toolchain I have defaults to -mthumb and that doesn't vary for -mcpu or any other command line option. I haven't got a gcc to hand that defaults to -marm so that I can test whether -mcpu=cortex-m3 will change that to

On Thu, 15 Nov 2018 at 14:18, Sjoerd Meijer <Sjoerd.Meijer at arm.com> wrote: > > Ahhh, typo in my previous mail: > > > > when I noticed that -Os gives me Thumb on Cortex-A{8,9,17} > > > I wanted to say: > > > when I noticed that "GCC -Os" gives me Thumb on Cortex-A{8,9,17} > > Yes. Just to clarify my response. That particular linaro

Hi My goal is that given a binary and the corresponding input. I want to know what IR level basic blocks are covered. I need the detail information, which is the set of all the covered BBs rather than just a number. I want to know whether there are some tools that can support this requirements. If not, I think maybe instrumentation can helps. However, I do not know too much about this. Any

Dear ML, Anton, Thank you for your answer and your help. I had a look at ARM.td of LLVM 2.6 (in lib/Target/ARM..) where I found following definitions: // V4T Processors. def : ProcNoItin<"arm7tdmi", [ArchV4T]>; def : ProcNoItin<"arm7tdmi-s", [ArchV4T]>; def : ProcNoItin<"arm710t", [ArchV4T]>; def :

There should be a line-table entry for the end of the function, which appears to be missing from the dump you provided. llvm-dwarfdump should report this address with 'end_sequence' in the Flags. Are you using a different dumper? I am not sure but my guess would be that inline data is not represented in the line table. The line table's primary purpose is to inform the debugger

Hi paulr Thanks for your reply. Though DWARF info give me the code address ranges, there might be inline data. If so, how to handle this case? As for the dwarf line table. Sometimes, the source line might be zero. Do you know why? If all instructions should be describe in the line table, I think analyzing Dwarf line table is enough to get all the instructions addresses. Do you agree? I would

I'm not familiar with the target instruction set, but if "MOV PC, R0" is not a return instruction, I'm guessing that the sequence starting at A39C is a dispatch through a jump table. The jump table would be considered part of the instruction stream and included in the scope of the line table. This is not a case where you would see end_sequence; my mistake. The line table does

Hello, I would like to address an issue/inconsistency related to command line options and compiling for minimum code size, and wanted to check if there would be any problems or objections to my change. The problem is that compiling for minimum code size like this: -Oz --target=arm-arm--eabi -mcpu=cortex-xyz does not really give minimum code size because -mthumb is not enabled. This

Hi I know that LLVM provide some debug API for us to know the source code information. For example, every IR instruction's source line number and column number. However, are there any method to get a mapping from IR instruction to binary address directly. I don't want to use dwarf line mapping table as a bridge. I think the binary is generated by clang and llvm. I think there definitely

Hi Paul Thanks for your comments. Suppose I can generate the control flow graph via LLVM Pass or the default option like '-dot-cfg' with opt. However, the control flow graph is based on llvm IR level. I would like to have a control flow graph based on binary level. Thus, I want to map the IR to binary address. As far as I know, we used to use the debug information to map the IR to source

Hi However, frontend may also do various operations on the source code and one line number and column number could map to more than one binary address. Why LLVM IR cannot? Regrads Muhui 2018-06-12 23:18 GMT+08:00 mayuyu.io <admin at mayuyu.io>: > In theory that’s not exactly possible/accurate. Due to various operations > in the Backend like Instruction Legalization, one IR