search for: macho

...Expression/ClangExpressionParser.cpp:199:13: error: ‘DisablePrettyStackTrace’ is not a member of ‘llvm’ [ 84%] Building CXX object tools/lldb/source/Core/CMakeFiles/lldbCore.dir/Baton.cpp.o /home/sam/src/llvm/tools/lldb/source/Core/ArchSpec.cpp:157:41: error: ‘CPUTypeARM’ is not a member of ‘llvm::MachO’ /home/sam/src/llvm/tools/lldb/source/Core/ArchSpec.cpp:158:41: error: ‘CPUTypeARM’ is not a member of ‘llvm::MachO’ /home/sam/src/llvm/tools/lldb/source/Core/ArchSpec.cpp:159:41: error: ‘CPUTypeARM’ is not a member of ‘llvm::MachO’ /home/sam/src/llvm/tools/lldb/source/Core/ArchSpec.cpp:160:41: err...

...- So I start reading source-code and making notes. To my question: At which state is the disassembly for PEcoff or ELF? I read the blog (http://blog.llvm.org/2010/04/intro-to-llvm-mc-project.html): """ The MC components have been designed to be object file independent (e.g. work for MachO, ELF, PE-COFF etc) but only have an implementation for MachO (used on Mac OS/X systems). Adding support for ELF and/or PE-COFF should be reasonably straight-forward. """ I don't even see the MachO support. macho-dump only dumps Macho header information.It doesn't seem to do m...

With the correct list this time. On Wed, Sep 9, 2015 at 6:59 PM, Davide Italiano <davide at freebsd.org> wrote: > Hi, > in the last month I spent some time implementing the missing MachO > specific features in llvm-readobj, and converting all the remaining > tests that used macho-dump to the new format. > llvm-readobj should have all the functionality that macho-dump had. If > there's something missing, please open a bug and assign to me, I'll > try to do my...

...ith Seiya off the mailing list yesterday, and this was the suggestion we came up with, on the basis that GNU objcopy has support for the renaming for GDB support, but it might be confusing to people who are new to the system, so we provide a more expected output option. I'm not experienced with MachO at all, though, so we'd appreciate any feedback from any MachO users. Generally, Mach-O tools separate the segment name and the section name as different entries on the command line. The “<Segment Name>,<Section Name>” string is almost always an output format. Some examples include...

...# aka @tls_object - MCSA_ELF_TypeCommon, /// .type _foo, STT_COMMON # aka @common - MCSA_ELF_TypeNoType, /// .type _foo, STT_NOTYPE # aka @notype - MCSA_Global, /// .globl - MCSA_Hidden, /// .hidden (ELF) - MCSA_IndirectSymbol, /// .indirect_symbol (MachO) - MCSA_Internal, /// .internal (ELF) - MCSA_LazyReference, /// .lazy_reference (MachO) - MCSA_Local, /// .local (ELF) - MCSA_NoDeadStrip, /// .no_dead_strip (MachO) - MCSA_PrivateExtern, /// .private_extern (MachO) - MCSA_Protected, ///...

Nate, Right, okay. I was also planning on looking at what the assembly output generates and "emulating" its output. So I should be able to use the 'test/CodeGen/PowerPC' tests once I have augmented the MachO Writer PowerPC output. Does this seem like the right and sensible approach ? Aaron ----- Original Message ----- From: Nate Begeman To: LLVM Developers Mailing List Sent: Monday, June 01, 2009 6:40 PM Subject: Re: [LLVMdev] MachO writer test cases I doubt anyone is using it, as it...

...e assembly files will not do that (at least, it will add the 1-byte `_LLVM,__asm` section, but not the `__LLVM,__bitcode` section). Furthermore, I do need the final output to contain bitcode for all files used. So, my question is if it is possible to add the `__LLVM,__bitcode` section later to the MachO object file. I tried to archive the bitcode using `xar` and run `llvm-objcopy main.o --add-section=__LLVM,__bitcode=main.xar main2.o`, but it failed with an `unsupported load command`. This seems to be the case for all usages of `llvm-objcopy` with MachO files. Cheers and thanks -- Joseph -------...

Currently, the MachO and ELF Writers and MachineCodeEmitters are hard-coded into LLVMTargetMachine and llc. In other words, the 'object file generation' capabilities of the Common Code Generator are not generic. LLVMTargetMachine::addPassesToEmitFile explicitly checks whether the derived backend TargetMachine...

Is anyone using the MachO Writer ? If so do you have any test cases as I am moving it over to use the prototype direct object emission code and I need test cases to verify it working correctly. Many thanks in advance, Aaron -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.l...

...WRONG: objcopy --only-secton=__TEXT,__unwind_info a.out WRONG: objcopy --only-secton=.unwind_info a.out OK: objcopy --only-secton=__TEXT.__unwind_info a.out For the compatibility with GNU binutils, I propose to make this section renaming rule as default in llvm-objcopy and implement a flag named —macho-names to use conventional section names: WRONG: llvm-objcopy --only-secton=__TEXT,__text a.out WRONG: llvm-objcopy --only-secton=__TEXT.__text a.out OK: llvm-objcopy --only-secton=.text a.out a.out2 WRONG: llvm-objcopy --macho-names --only-secton=.text a.out WRONG: llvm-objcopy --macho-names --on...

...ckout 133a7e631cee97965e310f0d110739217427fd3d, compiling on Windows 10. These tests fail with Visual Studio 2019: Failing Tests (7): Clang Tools :: clang-tidy/checkers/cert-mem57-cpp-cpp17.cpp Clang Tools :: clang-tidy/checkers/performance-noexcept-move-constructor-fix.cpp LLVM :: MC/MachO/gen-dwarf-cpp.s LLVM :: MC/MachO/gen-dwarf-macro-cpp.s LLVM :: MC/MachO/gen-dwarf-producer.s LLVM :: MC/MachO/gen-dwarf.s Polly :: ScopInfo/memset_null.ll Expected Passes : 57692 Expected Failures : 283 Unsupported Tests : 1941 Unexpected Failures: 7 The clang-tidy te...

Hi, I am working on the direct object module emission, and am wondering if anyone is successfully using the MachO backend. Thanks, Aaron -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090515/b8b96813/attachment.html>

I doubt anyone is using it, as it is not complete. On Jun 1, 2009, at 9:12 AM, Aaron Gray wrote: > Is anyone using the MachO Writer ? > > If so do you have any test cases as I am moving it over to use the > prototype direct object emission code and I need test cases to > verify it working correctly. > > Many thanks in advance, > > Aaron > > _______________________________________________...

Hey everyone! Recently there has been some progress on LLVM-based tools for manipulating MachO binaries: llvm-objcopy has been gaining a lot of important bits to support MachO (it's relatively close to the point where one can implement the strip-like functionality), llvm-lipo is functional and supports most of cctools' lipo options (https://llvm.org/docs/CommandGuide/llvm-lipo.html)....

> Aaron, I mailed in the same mail twice (by mistake), you answered both > copies. Differently! > > In any case, I've re-read what exists. I'm dumping what I understand > here, so that we can discuss in detail. I'm using MachO as the example > object format, as the ELF code is totally broken and outdated. Lets > use the following as the basis for our discussion? I've never looked at the MachO code as I do not have such a platform nor do I know the file format. Could we concentrate on the ELF backend, please....

> Currently, the MachO and ELF Writers and MachineCodeEmitters are > hard-coded into LLVMTargetMachine and llc. I am also interested in working on this area and interested in writting a COFF file backend. > In other words, the 'object file generation' capabilities of the > Common Code Generator are no...

Dear ladies and gentlemen, I have recently installed the latest version of R (4.3.3) for windows. Now I have the following problems with mutated vowels like ?, ?, etc. Here is an example: If I type the command: Dir <- "C/Users/macho/Documents/_LVn/Experimentelle ?bungen" in the R console there is no problem. However, if I put the same command into a source file (e.g. Test.r) and call this file from R (via the source command), I get the following error message: > source("C:\\Users\\macho\\Documents\\_LVn\\Experime...

...I can get support from the community that this is the direction we'd all like to take... I'd rather not make triples more complicated by introducing lots of special cases. Do you know who the right folks are to ask about the SPIR triples? Tim, This patch changes behavior a little for macho_embedded targets (i.e. from OSType::Unknown to OSType::NoneOS). I see that there is existing code to transform triples from things like thumbv7-apple-darwin into thumbv7m-apple-unknown-macho. Do you have an expectation to support users who are using the latter form of triples who would be surpr...

> I've never looked at the MachO code as I do not have such a platform nor do > I know the file format. > > Could we concentrate on the ELF backend, please. I don't mind using the ELF backend as our test case, it just seems that the ELFWriter/ELFCodeEmitter don't even use the BufferBegin/BufferEnd/CurBufferPtr sy...

CCing Nick Kledzik as I posed this question on IRC and Tim Northover suggested you as a good resource for this. I came across an error due to a scattered relocation offset being larger than 2**24 and I was hoping to find more information on scattered relocations. These are MachO specific, and Ive not been able to find any documentation on them outside of source code. I have a couple of immediate questions, but any info would be appreciated. * Should a check be added to ARMMachObjectWriter::RecordARMScatteredRelocation and RecordARMScatteredHalfRelocation to ensure that F...