search for: peview

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

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

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

...lld-link.exe /DEBUG:GHASH tout.obj LLD-LINK.EXE: error: duplicate symbol: __local_stdio_printf_options in tout.obj and in LIBCMT.lib(default_local_stdio_options.obj) LLD-LINK.EXE: error: duplicate symbol: __local_stdio_printf_options in tout.obj and in libvcruntime.lib(undname.obj) I'm using PEView from http://wjradburn.com/software/ to look at the files and can't see anything wrong, except some valid differences in the offsets being used for the data (so pointer to data is different between them). I will look into yaml2obj now to see if I see anything else weird going on. On Thu, Jan...

...K.EXE: error: duplicate symbol: __local_stdio_printf_options in >> tout.obj and in LIBCMT.lib(default_local_stdio_options.obj) >> LLD-LINK.EXE: error: duplicate symbol: __local_stdio_printf_options in >> tout.obj and in libvcruntime.lib(undname.obj) >> >> I'm using PEView from http://wjradburn.com/software/ to look at the >> files and can't see anything wrong, except some valid differences in the >> offsets being used for the data (so pointer to data is different between >> them). >> >> I will look into yaml2obj now to see if I see...

...out.obj > LLD-LINK.EXE: error: duplicate symbol: __local_stdio_printf_options in > tout.obj and in LIBCMT.lib(default_local_stdio_options.obj) > LLD-LINK.EXE: error: duplicate symbol: __local_stdio_printf_options in > tout.obj and in libvcruntime.lib(undname.obj) > > I'm using PEView from http://wjradburn.com/software/ to look at the files > and can't see anything wrong, except some valid differences in the offsets > being used for the data (so pointer to data is different between them). > > I will look into yaml2obj now to see if I see anything else weird going...

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

...stdio_printf_options in >>>> tout.obj and in LIBCMT.lib(default_local_stdio_options.obj) >>>> LLD-LINK.EXE: error: duplicate symbol: __local_stdio_printf_options in >>>> tout.obj and in libvcruntime.lib(undname.obj) >>>> >>>> I'm using PEView from http://wjradburn.com/software/ to look at the >>>> files and can't see anything wrong, except some valid differences in the >>>> offsets being used for the data (so pointer to data is different between >>>> them). >>>> >>>> I will...

...ate symbol: __local_stdio_printf_options in >>> tout.obj and in LIBCMT.lib(default_local_stdio_options.obj) >>> LLD-LINK.EXE: error: duplicate symbol: __local_stdio_printf_options in >>> tout.obj and in libvcruntime.lib(undname.obj) >>> >>> I'm using PEView from http://wjradburn.com/software/ to look at the >>> files and can't see anything wrong, except some valid differences in the >>> offsets being used for the data (so pointer to data is different between >>> them). >>> >>> I will look into yaml2obj...

...in >>>>> tout.obj and in LIBCMT.lib(default_local_stdio_options.obj) >>>>> LLD-LINK.EXE: error: duplicate symbol: __local_stdio_printf_options in >>>>> tout.obj and in libvcruntime.lib(undname.obj) >>>>> >>>>> I'm using PEView from http://wjradburn.com/software/ to look at the >>>>> files and can't see anything wrong, except some valid differences in the >>>>> offsets being used for the data (so pointer to data is different between >>>>> them). >>>>> >&gt...

...;> in tout.obj and in LIBCMT.lib(default_local_stdio_options.obj) >>>>>> LLD-LINK.EXE: error: duplicate symbol: __local_stdio_printf_options >>>>>> in tout.obj and in libvcruntime.lib(undname.obj) >>>>>> >>>>>> I'm using PEView from http://wjradburn.com/software/ to look at the >>>>>> files and can't see anything wrong, except some valid differences in the >>>>>> offsets being used for the data (so pointer to data is different between >>>>>> them). >>>>...

...j and in LIBCMT.lib(default_local_stdio_options.obj) >>>>>>> LLD-LINK.EXE: error: duplicate symbol: __local_stdio_printf_options >>>>>>> in tout.obj and in libvcruntime.lib(undname.obj) >>>>>>> >>>>>>> I'm using PEView from http://wjradburn.com/software/ to look at the >>>>>>> files and can't see anything wrong, except some valid differences in the >>>>>>> offsets being used for the data (so pointer to data is different between >>>>>>> them). >...

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

...lib(default_local_stdio_options.obj) >>>>>>>> LLD-LINK.EXE: error: duplicate symbol: __local_stdio_printf_options >>>>>>>> in tout.obj and in libvcruntime.lib(undname.obj) >>>>>>>> >>>>>>>> I'm using PEView from http://wjradburn.com/software/ to look at >>>>>>>> the files and can't see anything wrong, except some valid differences in >>>>>>>> the offsets being used for the data (so pointer to data is different >>>>>>>> between...

...>>>>> LLD-LINK.EXE: error: duplicate symbol: >>>>>>>>> __local_stdio_printf_options in tout.obj and in >>>>>>>>> libvcruntime.lib(undname.obj) >>>>>>>>> >>>>>>>>> I'm using PEView from http://wjradburn.com/software/ to look at >>>>>>>>> the files and can't see anything wrong, except some valid differences in >>>>>>>>> the offsets being used for the data (so pointer to data is different >>>>>>>>...

...> LLD-LINK.EXE: error: duplicate symbol: >>>>>>>>>> __local_stdio_printf_options in tout.obj and in >>>>>>>>>> libvcruntime.lib(undname.obj) >>>>>>>>>> >>>>>>>>>> I'm using PEView from http://wjradburn.com/software/ to look at >>>>>>>>>> the files and can't see anything wrong, except some valid differences in >>>>>>>>>> the offsets being used for the data (so pointer to data is different >>>>>>...

...E: error: duplicate symbol: >>>>>>>>>>> __local_stdio_printf_options in tout.obj and in >>>>>>>>>>> libvcruntime.lib(undname.obj) >>>>>>>>>>> >>>>>>>>>>> I'm using PEView from http://wjradburn.com/software/ to look at >>>>>>>>>>> the files and can't see anything wrong, except some valid differences in >>>>>>>>>>> the offsets being used for the data (so pointer to data is different >>>>...

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