search for: sizeofrawdata

...Minor comments: 1. Is it possible to allocate extra memory with coff::symbol instead of using std::string and std::vector as class members? The extra allocations can add up. 2. For the following bit: + reinterpret_cast <uint32_t &> (Section->Symbol->Aux [0]) = Section->Header.SizeOfRawData; + reinterpret_cast <uint16_t &> (Section->Symbol->Aux [4]) = Section->Header.NumberOfRelocations; + reinterpret_cast <uint16_t &> (Section->Symbol->Aux [6]) = Section->Header.PointerToLineNumbers; This isn't endian-safe; I'd suggest expanding it...

..."PECOFF" file? What is the difference? What does Win64 use? +#include <stdio.h> Do you really need this? If so, please use <cstdio> + assert (Section->Symbol->Aux.size () == 15); + write_uint32_le(Section->Symbol->Aux.data() + 0, Section->Header.SizeOfRawData); + write_uint16_le(Section->Symbol->Aux.data() + 4, Section->Header.NumberOfRelocations); + write_uint16_le(Section->Symbol->Aux.data() + 6, Section->Header.PointerToLineNumbers); ... + void add_common_symbol(MCSymbol *Symbol, uint64_t Size, unsigned ByteAlignment, bool...

Here is a full patch including Nathan's COFF support, tests that pass on Windows, and some changes to lit. Obviously the COFF support and changes to lit should be separate patches in the end. http://codereview.appspot.com/1624043/show - Michael Spencer -------------- next part -------------- A non-text attachment was scrubbed... Name: COFF-support.patch Type: application/octet-stream Size:

Hi guys, I have attached my patch to support generating win32 COFF object files. I would have posted earlier, but my system drive crashed and I had to rebuild my system; Luckily, my source code was on a secondary drive. I think this would be a good beginning for ongoing support of the COFF object file format and was hoping for some feedback as to whether it was commit worthy or what was needed to

...t does Win64 use? > > > > +#include <stdio.h> > > Do you really need this? If so, please use <cstdio> > > > > + assert (Section->Symbol->Aux.size () == 15); > + write_uint32_le(Section->Symbol->Aux.data() + 0, Section- > >Header.SizeOfRawData); > + write_uint16_le(Section->Symbol->Aux.data() + 4, Section- > >Header.NumberOfRelocations); > + write_uint16_le(Section->Symbol->Aux.data() + 6, Section- > >Header.PointerToLineNumbers); > ... > + void add_common_symbol(MCSymbol *Symbol, uint64_t S...

...g$H section already (e.g. run clang with -emit-codeview-ghash-section, and look at the properties of the .debug$H section and use the same values). The only invariant that needs to be maintained is that Section[N]->FilePointerOfRawData == Section[N-1]->FilePointerOfRawData + Section[N-1]->SizeOfRawData On Sat, Jan 20, 2018 at 11:52 AM Leonardo Santagada <santagada at gmail.com> wrote: > Thanks for the tips, I now have something that reads the obj file, finds > .debug$T sections and global hashes it (proof of concept kind of code). > What I can't find is: how does clang itself...

Hi, I finally got my first .obj file patched with .debug$H to look somewhat right. I added the new section at the end of the file so I don't have to recalculate all sections (although now I probably could position it in the middle, knowing that each section is: SizeOfRawData + (last.Header.NumberOfRelocations * (4+4+2)) and the $H needs to come right after $T in the file). That although illegal based on the coff specs doesn't seem its going to influence lld. Also we talked and we are probably going to do something similar to a bunch of windows defines and a check...

...ers? The extra > allocations can add up. > Yes, I believe ShortString & ShortVector are the appropriate alternative for these types of cases. > > 2. For the following bit: > + reinterpret_cast <uint32_t &> (Section->Symbol->Aux [0]) = > Section->Header.SizeOfRawData; > + reinterpret_cast <uint16_t &> (Section->Symbol->Aux [4]) = > Section->Header.NumberOfRelocations; > + reinterpret_cast <uint16_t &> (Section->Symbol->Aux [6]) = > Section->Header.PointerToLineNumbers; > > This isn't endian-safe;...

...that and then also look at how the CodeView part of the > code does it if I can't understand some of it. > > >> The only invariant that needs to be maintained is that >> Section[N]->FilePointerOfRawData == Section[N-1]->FilePointerOfRawData + >> Section[N-1]->SizeOfRawData >> > > Well, that and all the sections need to be on the final file... But I'm > hopeful. > > > Anyone has times on linking a big project like chrome with this so that at > least I know what kind of performance to expect? > > My numbers are something like: >...

...e: > Hi, > > I finally got my first .obj file patched with .debug$H to look somewhat > right. I added the new section at the end of the file so I don't have to > recalculate all sections (although now I probably could position it in the > middle, knowing that each section is: SizeOfRawData + > (last.Header.NumberOfRelocations * (4+4+2)) and the $H needs to come right > after $T in the file). That although illegal based on the coff specs > doesn't seem its going to influence lld. > > Also we talked and we are probably going to do something similar to a > bunch of...

...; >> I finally got my first .obj file patched with .debug$H to look somewhat >> right. I added the new section at the end of the file so I don't have to >> recalculate all sections (although now I probably could position it in the >> middle, knowing that each section is: SizeOfRawData + (last.Header.NumberOfRelocations >> * (4+4+2)) and the $H needs to come right after $T in the file). That >> although illegal based on the coff specs doesn't seem its going to >> influence lld. >> >> Also we talked and we are probably going to do something simila...

...gt;> +#include <stdio.h> >> >> Do you really need this? If so, please use <cstdio> >> >> >> >> + assert (Section->Symbol->Aux.size () == 15); >> + write_uint32_le(Section->Symbol->Aux.data() + 0, >> Section->Header.SizeOfRawData); >> + write_uint16_le(Section->Symbol->Aux.data() + 4, >> Section->Header.NumberOfRelocations); >> + write_uint16_le(Section->Symbol->Aux.data() + 6, >> Section->Header.PointerToLineNumbers); >> ... >> + void add_common_symbol(MCSymbol...

...lues). > Thanks I will do that and then also look at how the CodeView part of the code does it if I can't understand some of it. > The only invariant that needs to be maintained is that Section[N]->FilePointerOfRawData == > Section[N-1]->FilePointerOfRawData + Section[N-1]->SizeOfRawData > Well, that and all the sections need to be on the final file... But I'm hopeful. Anyone has times on linking a big project like chrome with this so that at least I know what kind of performance to expect? My numbers are something like: 1 pdb per obj file: link.exe takes ~15 minutes an...

...my first .obj file patched with .debug$H to look somewhat >>>> right. I added the new section at the end of the file so I don't have to >>>> recalculate all sections (although now I probably could position it in the >>>> middle, knowing that each section is: SizeOfRawData + (last.Header.NumberOfRelocations >>>> * (4+4+2)) and the $H needs to come right after $T in the file). That >>>> although illegal based on the coff specs doesn't seem its going to >>>> influence lld. >>>> >>>> Also we talked and we a...

...finally got my first .obj file patched with .debug$H to look somewhat >>> right. I added the new section at the end of the file so I don't have to >>> recalculate all sections (although now I probably could position it in the >>> middle, knowing that each section is: SizeOfRawData + >>> (last.Header.NumberOfRelocations * (4+4+2)) and the $H needs to come right >>> after $T in the file). That although illegal based on the coff specs >>> doesn't seem its going to influence lld. >>> >>> Also we talked and we are probably going to...

...at how the CodeView part of the >> code does it if I can't understand some of it. >> >> >>> The only invariant that needs to be maintained is that >>> Section[N]->FilePointerOfRawData == Section[N-1]->FilePointerOfRawData + >>> Section[N-1]->SizeOfRawData >>> >> >> Well, that and all the sections need to be on the final file... But I'm >> hopeful. >> >> >> Anyone has times on linking a big project like chrome with this so that >> at least I know what kind of performance to expect? >> >&...

...hed with .debug$H to look >>>>>> somewhat right. I added the new section at the end of the file so I don't >>>>>> have to recalculate all sections (although now I probably could position it >>>>>> in the middle, knowing that each section is: SizeOfRawData + >>>>>> (last.Header.NumberOfRelocations * (4+4+2)) and the $H needs to come right >>>>>> after $T in the file). That although illegal based on the coff specs >>>>>> doesn't seem its going to influence lld. >>>>>> >>...

...the CodeView part of the >>> code does it if I can't understand some of it. >>> >>> >>>> The only invariant that needs to be maintained is that Section[N]->FilePointerOfRawData == >>>> Section[N-1]->FilePointerOfRawData + Section[N-1]->SizeOfRawData >>>> >>> >>> Well, that and all the sections need to be on the final file... But I'm >>> hopeful. >>> >>> >>> Anyone has times on linking a big project like chrome with this so that >>> at least I know what kind of perfo...

...bj file patched with .debug$H to look >>>>> somewhat right. I added the new section at the end of the file so I don't >>>>> have to recalculate all sections (although now I probably could position it >>>>> in the middle, knowing that each section is: SizeOfRawData + >>>>> (last.Header.NumberOfRelocations * (4+4+2)) and the $H needs to come right >>>>> after $T in the file). That although illegal based on the coff specs >>>>> doesn't seem its going to influence lld. >>>>> >>>>> Als...

...k >>>>>>>> somewhat right. I added the new section at the end of the file so I don't >>>>>>>> have to recalculate all sections (although now I probably could position it >>>>>>>> in the middle, knowing that each section is: SizeOfRawData + >>>>>>>> (last.Header.NumberOfRelocations * (4+4+2)) and the $H needs to >>>>>>>> come right after $T in the file). That although illegal based on the coff >>>>>>>> specs doesn't seem its going to influence lld. >>&...