search for: peviewer

Hi, thanks for the answers, i tried to use LINK.EXE to produce a pdb, but unfortunately, it produces an empty pdb (i have debug symbols in the dumped .obj because I can see them with PEViewer). It is probably because i have undefined symbols, which is logical because i'm dumping machine code which points to running native code. I still dont understand why LINK.EXE is not able to produce a valid pdb for my valid symbols even if all symbols referenced are not resolved. Do you think LL...

...has a bug. On Wed, Mar 14, 2018 at 3:07 PM Vivien Millet <vivien.millet at gmail.com> wrote: > Hi, thanks for the answers, i tried to use LINK.EXE to produce a pdb, but > unfortunately, it produces an empty pdb (i have debug symbols in the dumped > .obj because I can see them with PEViewer). > It is probably because i have undefined symbols, which is logical because > i'm dumping machine code which points to running native code. I still dont > understand why LINK.EXE is not able to produce a valid pdb for my valid > symbols even if all symbols referenced are not resol...

On Fri, Mar 9, 2018 at 7:00 PM Lang Hames <lhames at gmail.com> wrote: > Hi Vivien, > > I'm not familiar with Windows development, but I believe you could dump > the object file to disk then run LINK.EXE to produce the PDB. > Alternatively, I think LLD can also produce PDB files (Rui -- is that > right?), in which case you may be able to use that. > Yes, lld can

I did reorder my sections, so that .debug$H is in the correct place, but now I get some errors on dubplicate symbols, I created a folder with examples: https://www.dropbox.com/sh/nmvzi44pi0boe76/AAA0f47O5PCJ9JiUc6wVuwBra?dl=0 t.obj is generated by vs 2015 and it links fine with lld-link.exe, but tout.obj gives this errors: lld-link.exe /DEBUG:GHASH tout.obj LLD-LINK.EXE: error: duplicate

Actually I already have a theory that even though you are adding the section to the section table, you might not be adding a *symbol* for the section to the symbol table. So the existing symbols (which reference sections by index) will all be wrong because you've inserted a new section. Still though, obj2yaml would expose that. On Thu, Jan 25, 2018 at 9:50 AM Zachary Turner <zturner at

Yea as long as you compare clang-cl object file with automatically generated .debug$H section against clang-cl object file without .debug$H but added after the fact with llvm-objcopy, that should expose the problem I think when you run obj2yaml on them. On Thu, Jan 25, 2018 at 9:49 AM Leonardo Santagada <santagada at gmail.com> wrote: > I did reorder my sections, so that .debug$H is in

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

Any idea on how to create this new symbol there? I saw that there is a symbol pointing to each section, but didn't understand the format, and yaml2obj doesn't check it or do anything with the list. On Thu, Jan 25, 2018 at 6:56 PM, Leonardo Santagada <santagada at gmail.com> wrote: > YES, THANK YOU... I WAS THINKING THIS BUT COMPLETELY FORGOT. > > sorry for the caps... long

YES, THANK YOU... I WAS THINKING THIS BUT COMPLETELY FORGOT. sorry for the caps... long day of working on this, and using vs 2017, which adds a new section type .chks64 that I couldn't find documentation anywhere was difficult. I highly recommend everyone to just not using vs 2017 until 15.8 or something, our internal bug list is gigantic. On Thu, Jan 25, 2018 at 6:52 PM, Zachary Turner

If you run obj2yaml against a very simple object file, you'll see something like this at the end: ``` symbols: - Name: '@comp.id' Value: 17130443 SectionNumber: -1 SimpleType: IMAGE_SYM_TYPE_NULL ComplexType: IMAGE_SYM_DTYPE_NULL StorageClass: IMAGE_SYM_CLASS_STATIC - Name: '@feat.00' Value:

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

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

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 >

(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) {

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

I'm pretty confident that cl is not putting anything strange in the .debug$T sections. We've done a lot of testing and never seen anything except CodeView type records in a .debug$T. My hunch is that your objcopy patch is probably not doing the right thing in one or more of the section headers, and this is confusing the linker. One idea might be to build a simple object file with

Don't worry, I definetly want to perfect this to generate legal obj files, this is just to speed up testing. Now after patching all the obj files I get this errors when linking a small part of our code base (msvc 2017 15.5.3, lld and llvm-objcopy 7.0.0): lld-link.exe : error : relocation against symbol in discarded section: $LN8 lld-link.exe : error : relocation against symbol in discarded