similar to: [LLVMdev] Does LLVM sign ARM ELFs?

On 20 November 2012 03:22, Greg Fitzgerald <garious at gmail.com> wrote: > I read through "ELF for the ARM Architecture" and my best guess has > been to inspect .ARM.attributes in the elf-dump's section data, but > both LLVM and GCC use "aeabi" for the vendor name. "aeabi" is the "pseudo-vendor" which is normally printed to the attributes

> I wouldn't rely on that. > > I'm not sure what's your objective Agreed, thanks Renato. My objectives: 1) Add a patch to enable the integrated assembler by default when targeting ARM or Thumb with ELF. The patch is very tiny - you override a virtual method for the toolchain. But you do it in a base class so a little fragile. It deserves a test. 2) Demonstrate a

Hi Greg, > At this point, my biggest concern is the quality of the > ElfStreamer, and I haven't done anything to verify the linker. But > everything seems to "just work", so maybe time to go find bigger fish > to fry? What do you think? Should we flip the switch? I'd be in favour of it. All of the gaps I'm aware of (haphazard build attributes mainly) are

Hi Tim, Renato, Revisiting this one from about a month back, is anyone tracking what GAS assembly compatibility issues remain? If we only need to compile C and C++, things are looking very good, but when you throw handwritten assembly into the mix, not so much. The goal is GAS compatibility, right? Not UAL? Or is there a hope to make both work? Thanks, Greg On Tue, Nov 20, 2012 at 11:49

On 20 November 2012 19:49, Tim Northover <t.p.northover at gmail.com> wrote: > I'd be in favour of it. All of the gaps I'm aware of (haphazard build > attributes mainly) are equally applicable to both integrated and GAS > assembly. It's possible we mis-tag a section or a symbol somehow, but > hopefully nothing substantial. Is there any test using the integrates

Greetings, I am running a buch of wilcox tests and need to be able to rapidly export the results into a csv file. I have attached example code as well as my attempts to get what I need. I have tried unlist,cbind,rbind etc but I am obvously missing something simple. FYI I am actually running about 50 WRS tests per dataset, this is just an example. Thanks 10^6 Mike AKCCR <-

caching_thread()s do all their work under read access to extent_commit_sem. They give up on this read access only when need_resched() tells them, or when they exit. As a result, somebody that wants a WRITE access to this sem, might wait for a long time. Especially this is problematic in cache_block_group(), which can be called on critical paths like find_free_extent() and in commit path via

On Mon, Apr 06, 2020 at 02:50:32PM +0200, Arnd Bergmann wrote: > On Mon, Apr 6, 2020 at 2:12 PM Michael S. Tsirkin <mst at redhat.com> wrote: > > > > > +config VHOST_DPN > > + bool "VHOST dependencies" > > + depends on !ARM || AEABI > > + default y > > + help > > + Anything selecting VHOST or

On Mon, Apr 06, 2020 at 02:50:32PM +0200, Arnd Bergmann wrote: > On Mon, Apr 6, 2020 at 2:12 PM Michael S. Tsirkin <mst at redhat.com> wrote: > > > > > +config VHOST_DPN > > + bool "VHOST dependencies" > > + depends on !ARM || AEABI > > + default y > > + help > > + Anything selecting VHOST or

Hi everybody! I would like to export the results of a test statistic in a *.csv file, but get an error. The code is below. The data are attached as .txt with tab as separator. I tried to get a sample dataset, but for some reason it didn't work, so please excuse the length of the file. I also attached a txt with the output (copy/paste) in case that helps. ---- > library(WRS) >

> I just tried the above code in a .s file and it worked fine for me. > Can you show exactly what you’re seeing that looks wrong? Thanks Jim. I can only reproduce the issue when that code is inline assembly in a bitcode file. Attached is a bitcode file and Makefile to demonstrate. Calling 'make' will dump two object files 'c.o' and 'asm.o'. The former is created

On 11-05-16 09:21 AM, Koan-Sin Tan wrote: > splited patches and test cases > > mc-elf-thumbfunction-bit.diff: for 1 > mc-elf-arm-backend-bl-blx-sign-bit.diff: for 2. > mc-elf-thumb-bl-blx-relocation-table-entry.diff: for 3. > mc-elf-cpu-xscale-attributes.diff: for 4. > > elf-thumbfunc.s: test case for 1 > elf-thumbfunc-reloc.ll: test case for 2 and 3 >

vhost is currently broken on the default ARM config. The reason is that that uses apcs-gnu which is the ancient OABI that is been deprecated for a long time. Given that virtio support on such ancient systems is not needed in the first place, let's just add something along the lines of depends on !ARM || AEABI to the virtio Kconfig declaration, and add a comment that it has to do with

vhost is currently broken on the default ARM config. The reason is that that uses apcs-gnu which is the ancient OABI that is been deprecated for a long time. Given that virtio support on such ancient systems is not needed in the first place, let's just add something along the lines of depends on !ARM || AEABI to the virtio Kconfig declaration, and add a comment that it has to do with

Hi all, one issue found during the NetBSD/ARM tests is the following. Consider this input for EARM: int f(int a, int b) { return a % b; } unsigned int g(unsigned int a, unsigned int b) { return a % b; } At the moment, this will call __modsi3 and __umodsi3, even though those functions are not part of AAPCS. Should this be considered a lowering bug in the ARM target? Joerg

On 22 July 2012 22:03, salvatore benedetto <salvatore.benedetto at gmail.com> wrote: > While we are at it, if a new comer would like to understand where everything > takes place, where should he look? > > I did a grep in the source and eventually ended up in clang/something/driver. That's pretty much it: clang/lib/Driver

Hi Joerg, > At the moment, this will call __modsi3 and __umodsi3, even though those > functions are not part of AAPCS. Should this be considered a lowering > bug in the ARM target? LLVM actually supports both variants, depending on the target. The __aeabi_* functions are part of the ARM "runtime ABI" and largely independent of AAPCS. For whatever reason, Linux (& Darwin)

On 9 February 2017 at 17:31, Amara Emerson <amara.emerson at gmail.com> wrote: > Ping. Does anyone else have thoughts on this? Hi Amara, It seems the people who replied in this thread are mostly in sync with the proposal, why don't you push a review in phab, and let's take this to the next level? cheers, --renato

Amara, first, thank you for answering. but I found expandPsuedo instructions actually happens before post-RA, like the following code showing: your approach is a little hacky, right? : ) // Expand pseudo instructions before second scheduling pass. addPass(&ExpandPostRAPseudosID); printAndVerify("After ExpandPostRAPseudos"); // Run pre-sched2 passes. if (addPreSched2())

Hi Rafael, Sure, the expansion of at least .cpload should be done in the Target ELFStreamer but AFAICS it doesn't solve my initial problem. MCCodeGenInfo is not created in tools where CodeGen isn't needed (llvm-mc) and it's still not possible to access the Relocation Model in MCObjectFileInfo from the target streamer (private member). Am I missing something obvious ? There are many