search for: binaryformats

I'm looking at fixing some layering violations in LLVM & came across a few in the CodeView handling, specifically: lib/MC/MCCodeView includes several llvm/DebugInfo/CodeView headers I guess MC could be made dependent on DebugInfoCodeView? But probably these things should be sunk into BinaryFormat as is the case for DWARF features used by MC? include/llvm/Object/COFF.h includes

...include/llvm/DebugInfo/CodeView/CVDebugRecord.h >> Also seems like this could/should/needs to be sunk into BinaryFormat? >> > > These things are really more PE/PDB related than CodeView. They are in the > wrong place. I'd ask Saleem to help find a new home. Object or > BinaryFormats seem OK to me. > Moved it to libObject (r328593) for now which is at least correct - if someone thinks it'd be more suited to BinaryFormat, I'm happy to move it or they can. > > >> I'm open to ideas & happy to do the work, or help in any way that might >> be...

...>>>> Also seems like this could/should/needs to be sunk into BinaryFormat? >>>> >>> >>> These things are really more PE/PDB related than CodeView. They are in >>> the wrong place. I'd ask Saleem to help find a new home. Object or >>> BinaryFormats seem OK to me. >>> >> >> Moved it to libObject (r328593) for now which is at least correct - if >> someone thinks it'd be more suited to BinaryFormat, I'm happy to move it or >> they can. >> >> >>> >>> >>>> I'm o...

...odeView/CVDebugRecord.h >>> Also seems like this could/should/needs to be sunk into BinaryFormat? >>> >> >> These things are really more PE/PDB related than CodeView. They are in >> the wrong place. I'd ask Saleem to help find a new home. Object or >> BinaryFormats seem OK to me. >> > > Moved it to libObject (r328593) for now which is at least correct - if > someone thinks it'd be more suited to BinaryFormat, I'm happy to move it or > they can. > > >> >> >>> I'm open to ideas & happy to do the work,...

...lso seems like this could/should/needs to be sunk into BinaryFormat? >>>>> >>>> >>>> These things are really more PE/PDB related than CodeView. They are in >>>> the wrong place. I'd ask Saleem to help find a new home. Object or >>>> BinaryFormats seem OK to me. >>>> >>> >>> Moved it to libObject (r328593) for now which is at least correct - if >>> someone thinks it'd be more suited to BinaryFormat, I'm happy to move it or >>> they can. >>> >>> >>>> >&gt...

...bject/COFF.h includes > include/llvm/DebugInfo/CodeView/CVDebugRecord.h > Also seems like this could/should/needs to be sunk into BinaryFormat? > These things are really more PE/PDB related than CodeView. They are in the wrong place. I'd ask Saleem to help find a new home. Object or BinaryFormats seem OK to me. > I'm open to ideas & happy to do the work, or help in any way that might be > useful. > > Thanks, > - Dave > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180322/...

Yes, some of the headers and stuff that are just raw structure definitions and enums could probably be sunk into BinaryFormat.. How'd you find this? Curious why it hasn't been breaking in modules builds for a long time. On Wed, Mar 21, 2018 at 11:31 AM David Blaikie <dblaikie at gmail.com> wrote: > I'm looking at fixing some layering violations in LLVM & came across a

Someone internally's been dabbling with turning on some of Google's build system's stricter header checking modes - and they caught these (you can check the internal code review 184305506 for the original where I'm pulling things out from). & yeah, fair question about the modules builds - I don't fully understand what they catch and don't catch. I suspect it's a

...sunk into >>>>>> BinaryFormat? >>>>>> >>>>> >>>>> These things are really more PE/PDB related than CodeView. They are in >>>>> the wrong place. I'd ask Saleem to help find a new home. Object or >>>>> BinaryFormats seem OK to me. >>>>> >>>> >>>> Moved it to libObject (r328593) for now which is at least correct - if >>>> someone thinks it'd be more suited to BinaryFormat, I'm happy to move it or >>>> they can. >>>> >>>&...

Intuitively I'd think MC and DebugInfo should be independent. MC is a producer, DebugInfo is a consumer. What's common is the definition of the structures they operate on, which doesn't properly belong to either one. --paulr From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of David Blaikie via llvm-dev Sent: Wednesday, March 21, 2018 11:52 AM To: Zachary Turner

DebugInfoCodeView is nto strictly a consumer, it is also a producer. On Wed, Mar 21, 2018 at 1:29 PM <paul.robinson at sony.com> wrote: > Intuitively I'd think MC and DebugInfo should be independent. MC is a > producer, DebugInfo is a consumer. What's common is the definition of the > structures they operate on, which doesn't properly belong to either one. > >

James, Thanks for the detailed response. Please see my thoughts inline. On Thu, Sep 17, 2020 at 12:33 AM James Henderson < jh7370.2008 at my.bristol.ac.uk> wrote: > Hi Rahman, > > Traditionally, the ability to read sections is a feature added to > llvm-readobj/llvm-readelf. For some sections, it delegates to methods in > places like the Object library and BinaryFormat, but

Hi, I'm working on an LLVM Pass plugin and I'm running into a problem when loading it into opt. I want to have a custom option for my pass and added an llvm::cl::opt #include'ing "llvm/Support/CommandLine.h" linking the dependant libs causes the following error when loading it with opt: opt: CommandLine Error: Option 'debug-pass' registered more than once! I

Hi all, I am experimenting with extending ELF. I want to add a custom ELF section, something similar to a 'SyntheticSection'. However, I'm not able to find documentation / doxygen for LLD code. Are there any existing examples of adding custom ELF sections at link time in LLVM framework? Is it possible? Any pointers? Thanks in advance!Cheers! -------------- next part -------------- An

On Fri, Aug 04, 2017 at 01:54:33PM -0600, Jonathan Roelofs wrote: > > > On 8/4/17 1:14 PM, Goran Mekić via llvm-dev wrote: > > On Thu, Aug 03, 2017 at 08:22:24AM -0600, Jonathan Roelofs wrote: > > > IIUC, you don't want to cross compile llvm itself (which is what those > > > instructions are for), but instead you want to *use* llvm to cross compile > >

Hi All, Following up on https://lists.llvm.org/pipermail/llvm-dev/2020-July/143512.html, and https://reviews.llvm.org/D85408, we would like to consider a design which allows external tools to read the structured contents of the .bb_addr_map section with library calls into an LLVM library. At the same time, we need to have tools/obj2yaml tests in place for bb_addr_map. So it sounds like the

Hi Philip, thanks for the quick answer. That makes sense, but when leaving the set LLVM_LINK_COMPONENTS out I get an undefined symbol when loading the plugin: _ZTVN4llvm2cl3optINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEELb0ENS0_6parserIS7_EEEE which boils down to llvm::cl::opt<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char>>,

On Fri, Aug 04, 2017 at 04:03:35PM -0600, Jonathan Roelofs wrote: > > > 1) Pick a directory as your sysroot > > ~/arm-sysroot > > > > > 2) Install the libc headers there (without having built it) > > What I did was mv musl-*/include ~/arm-sysroot/usr/include. > > I think you need to copy them, not move them. On a new directories and fresh untar of musl, I

Hi, I was interested in trying out LLVM BOLT and generated profile data using Linux perf using the following: perf record -e cycles:u -o perf.data <command> This is without the use of LBR so I understand the performance improvements may not be much but this was more for becoming familiar with BOLT's commands. I then run: perf2bolt -nl -p perf.data -o perf.fdata <binary> and I

On Tue, May 22, 2018 at 6:06 PM Peter Collingbourne via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi all, > > Context: ld.gold has an --icf=safe flag which is intended to apply ICF > only to sections which can be safely merged according to the guarantees > provided by the language. It works using a set of heuristics (symbol name > matching and relocation scanning).