search for: writesections

...a8 (dynamic relocation r_addend) points to a function at .text segment (in this case frame_dummy). I am trying to made this on lld, but current step sequence is: - Write::run \_ Write::createSections \_ Write::scanRelocs \_ Write::addReloc // Dynamic Relocation creation \_ Write::writeSections \_ OutputSectionBase::writeTo \_ InputSection::writeTo \_ InputSection::relocate \_ TargetInfo::relocateOne The problem is only at TargetInfo::relocate the target (aarch64) will see that the relocation is a R_AARCH64_ABS64 one and thus will need to create a d...

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

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

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''ve run a little wired benchmark on comparing Btrfs v0.19 and XFS: There are 2000 directories and each directory contains 1000 files. The workload randomly stat a file or chmod a file for 2000000 times. And the number of stat and chmod are 50% and 50%. I monitor the number of disk read requests #Disk Write Requests, #Disk Read Requests, #Disk Write Sectors, #Disk Read

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

One remaining blocking issue for linking FreeBSD with lld is the inability to build the bootloader components. We have a patch[1] in review to address one of the problems by switching to using a linker script instead of GNU ld's -N option. Another issue is that some bootloader components are created by the linker directly as binary objects, using --oformat binary. (Other bootloader components

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: >>

(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: > > // a.cpp > static int x = 0; > void b(int); > void a(int) { > if (x) > b(x); > } > int main(int argc, char **argv) {

I haven't really dabbled in this part of the COFF format personally, so hopefully I'm not leading you astray :) But I checked the code for coff2yaml, and I see this: } else if (Symbol.isSectionDefinition()) { // This symbol represents a section definition. assert(Symbol.getNumberOfAuxSymbols() == 1 && "Expected a single aux symbol to

I'm so close I can almost smell it :) I know how bad the code looks, I don't intend to submit this, but if you want to try it out its at: https://gist.github.com/santagada/544136b1ee143bf31653b1158ac6829e I'm seeing: lld-link.exe: error: duplicate symbol: "<redacted_unmangled>" (<redacted>) in <internal> and in <redacted_filename>.obj, looking at the

I did this: // a.cpp static int x = 0; void b(int); void a(int) { if (x) b(x); } int main(int argc, char **argv) { a(argc); return x; } clang-cl /Z7 /c a.cpp /Foa.noghash.obj clang-cl /Z7 /c a.cpp -mllvm -emit-codeview-ghash-section /Foa.ghash.good.obj llvm-objcopy a.noghash.obj a.ghash.bad.obj obj2yaml a.ghash.good.obj > a.ghash.good.yaml obj2yaml a.ghash.bad.obj >

I see that there is an auxsymbol per section symbol, and also on the yaml representation there is a checksum, selection and unused all of them I have no idea how to fill in, also this aux symbol might have some important information for me to patch on the other symbols. Can you find the part in llvm that it writes those? because at least for auxsymbol the yaml part of the code threats as a binary