similar to: [LLVMdev] llvm-objdump disassembling jmp

On Thu, Oct 17, 2013 at 10:55 AM, Stephen Checkoway <s at pahtak.org> wrote: > In creating a test case for a bug fix in llvm-objdump, I noticed that it > differs in its output of pc-relative immediates from objdump: > > [secdev:/tmp] s$ cat a.s > main: > jmp .LBL0 > .LBL0: > ret > [secdev:/tmp] s$ llvm-mc -filetype=obj a.s > a.o >

On Nov 14, 2013, at 8:19 AM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > But gold has at most 2 objects loaded at any time. Are you sure about that? I haven't looked into it but while building Chromium with LTO, I get: ../../third_party/gold/gold64: fatal error: out of file descriptors and couldn't close any clang: error: linker command failed with exit code 1

On Nov 15, 2013, at 10:19 AM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > On 14 November 2013 18:01, Stephen Checkoway <s at pahtak.org> wrote: >> >> On Nov 14, 2013, at 8:19 AM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: >> >>> But gold has at most 2 objects loaded at any time. >> >> Are you sure about

On 14 November 2013 18:01, Stephen Checkoway <s at pahtak.org> wrote: > > On Nov 14, 2013, at 8:19 AM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > >> But gold has at most 2 objects loaded at any time. > > Are you sure about that? I haven't looked into it but while building Chromium with LTO, I get: > > ../../third_party/gold/gold64: fatal

While looking at what llvm writes for this testcase, I noticed that there is one redundant operation in resulting assembly. The second 'cmp' operation there is essentially identical to the first one, with reversed order of arguments. Therefore, it is not needed. This testcase is a simple integer comparison routine, similar to what qsort would take to sort an integer array. I think

On Jul 10, 2013, at 6:54 PM, Stephen Checkoway <s at pahtak.org> wrote: > On Jul 10, 2013, at 17:44, Jim Grosbach <grosbach at apple.com> wrote: >> The length specifier is, as I understand it, required when the instruction references memory but is optional (and inferred from the registers) for the register variants. >> >> The best reference I know of for the

On Wed, Jul 10, 2013 at 7:15 PM, Jim Grosbach <grosbach at apple.com> wrote: > > On Jul 10, 2013, at 6:54 PM, Stephen Checkoway <s at pahtak.org> wrote: > > On Jul 10, 2013, at 17:44, Jim Grosbach <grosbach at apple.com> wrote: > > The length specifier is, as I understand it, required when the instruction > references memory but is optional (and inferred from

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

Taking a really quick at the gold code it looks like it tries to keep 8176 files open. I would suggest putting a breakpoint in Descriptors::close_some_descriptor and checking why it is failing to close the files. On 15 November 2013 11:03, Stephen Checkoway <s at pahtak.org> wrote: > > On Nov 15, 2013, at 10:19 AM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: >

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

Interesting. If it is generating yaml files that can't be decoded, then definitely sounds like a bug. If you can provide a reduced test case we can try to fix it, but admittedly it can often take some effort to generate a reduced test case. The best way is to use creduce. Use cl or clang-cl and write the pre-processed output to a file, then run creduce on that file with a test that

I'm now thinking that there's a bug in either obj2yaml or yaml2obj, because if I run just those two tools on my codebase it generates yaml files that can't be decoded, will try now to not add any section to the obj file in llvm-objcopy to see if I can link with obj files that I rewrite (but without adding symbols or sections). One of the bugs that do annoy me is that the timedatestamp

dumpbin has some clues. I ran dumpbin /all on both object files and diffed the results. In the good object file, Section #2 (.data) has File Pointer to Raw Data = 208, but in the bad file Section #2 (.data) has File Pointer to Raw Data = 0. Also, Section #3 (.bss) in the good file has Size of Raw Data = 4, but in the bad file Section #3 (.bss) has Size of Raw Data = 0. On Fri, Jan 26, 2018 at

Hi, After looking at the Normalized Readers in mach-o, I feel it would be nice if the Gnu flavor to adopt this design what mach-o did in addition to using obj2yaml. Its so much easier to test in the context of lld with normalized readers, IMO. Opinions ? Thanks Shankar Easwaran -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation

Hmm, ok. In that case let me try again without my local changes. Maybe they are getting in the way :-/ On Fri, Jan 26, 2018 at 9:51 AM Leonardo Santagada <santagada at gmail.com> wrote: > it is identical to me... wierd. > > On Fri, Jan 26, 2018 at 6:49 PM, Zachary Turner <zturner at google.com> > wrote: > >> (Ignore the fact that my hashes are 8 byte in the

Let's suppose that MCLinker folks are here already - I am a committer of this project :). Maybe I did not formulate my suggestion correctly. When I offer to "install" the yaml2obj and obj2yaml utilities I mean result of the "make install" command only. I do not suggest to include this utilities into any distributed binary packages. To be clear I attached the patch with

> Letting the module own MDNodes may not be a win for gold since it is going > to create multiple copies of MDNodes that could be shared with Context > owning MDNodes. > > For example, with debug info type uniquing, the type nodes can be shared > across modules, but with module owning MDNodes, each module will create its > own copy of the type nodes. The advantage is that the

Now the yaml2obj and obj2yaml utilities used in LLVM and LLD projects tests only and not installed by the "make install" command. I think they might be also useful in third-party projects like MCLinker. I suggest to move these utilities into the "tools" category and install them together with other LLVM tools. Any objections or comments? -- Simon Atanasyan

it is identical to me... wierd. On Fri, Jan 26, 2018 at 6:49 PM, Zachary Turner <zturner at google.com> wrote: > (Ignore the fact that my hashes are 8 byte in the "good" file, this is due > to some local changes I've been experimenting with) > > On Fri, Jan 26, 2018 at 9:48 AM Zachary Turner <zturner at google.com> wrote: > >> I did this: >>

On Wed, Nov 13, 2013 at 7:58 PM, Rafael Espíndola < rafael.espindola at gmail.com> wrote: > > It sounds like the linker could call lto_module_dispose() right after > > lto_codegen_add_module() to help reduce the memory footprint. That > would be > > a simple linker change. A slightly larger linker change would be to > > immediately call lto_codegen_add_module()