search for: ulittle32_t

...s) << ") " << "0x" << format("%08x", symbol->Value) << " " << name << "\n"; Are trying to call the format function with struct coff_symbol { struct StringTableOffset { support::ulittle32_t Zeroes; support::ulittle32_t Offset; }; union { char ShortName[8]; StringTableOffset Offset; } Name; support::ulittle32_t Value; support::little16_t SectionNumber; struct { support::ulittle8_t BaseType; support::ulittle8_t ComplexType; } Type; support::ulittl...

...gt;              << "0x" << format("%08x", symbol->Value) << " " >              << name << "\n"; > Are trying to call the format function with > struct coff_symbol { >   struct StringTableOffset { >     support::ulittle32_t Zeroes; >     support::ulittle32_t Offset; >   }; >   union { >     char ShortName[8]; >     StringTableOffset Offset; >   } Name; >   support::ulittle32_t Value; >   support::little16_t SectionNumber; >   struct { >     support::ulittle8_t BaseType; >     support::...

...ream.StreamData); > if (auto EC = SubsectionsReader.readArray(Subsections, > > SubsectionsReader.bytesRemaining())) > return EC; > > So it looks like there should be one of these just after the C13Lines > substream: > > struct DebugSubsectionHeader { > support::ulittle32_t Kind; // codeview::DebugSubsectionKind enum > support::ulittle32_t Length; // number of bytes occupied by this record. > }; > > But when I look there with my own code I only see zeroes: > > read C13 line info 142964 bytes > DebugSubsectionHeader{ .Kind = DebugSubsectionKind...

Zachary, Thanks for the help on IRC earlier. I've got code that can capture a stack trace and then discover for each address, its module, function, source index, line, and column. I still have a couple of loose ends though. Do you know what's going on here? 1. There appears to be 8 bytes before every LineFragmentHeader. Here's some of my own debug output, which matches

Rafael Avila de Espindola <rafael.espindola at gmail.com> writes: >> On Mar 22, 2014, at 1:31, Justin Bogner <mail at justinbogner.com> wrote: >> Also, the header includes a "clang::io" namespace with some operations >> for reading and writing little endian files. Should these be directly >> renamed to "llvm::io", or would something like

...clearly in favour of being efficient to read, because accessing it is in the critical path of a consumer (i.e. a linker), and the part that needs to be efficient to read is a relatively small part of the data in the bitcode file. The same logic applies to the symbol table (note that we use support::ulittle32_t instead of a bit encoding). That said we already paid this with the metadata table in the recent past > for example. > > The format of MODULE_CODE_{FUNCTION,GLOBALVAR,ALIAS,IFUNC,COMDAT} > records would change so that their first operand would specify their names > with a byte offs...

...being efficient to read, because accessing > it is in the critical path of a consumer (i.e. a linker), and the part that > needs to be efficient to read is a relatively small part of the data in the > bitcode file. The same logic applies to the symbol table (note that we use > support::ulittle32_t instead of a bit encoding). > > That said we already paid this with the metadata table in the recent past >> for example. >> > >> The format of MODULE_CODE_{FUNCTION,GLOBALVAR,ALIAS,IFUNC,COMDAT} >> records would change so that their first operand would specify thei...

...ed by the stuff in Endian.h, >> but the write to an ostream and reading unaligned aren't addressed very >> well at present. > > ulittle32 is actually unaligned: > > typedef detail::packed_endian_specific_integral > <uint32_t, little, unaligned> ulittle32_t > > But yes, I don't think we have anything for writing and I it is > probably not trivial to extend it. We can probably add the existing > write functions to Endian.h itself. A bit more detail on this. For reading, simply changing the existing clients to use Endian.h is a bit of...

Hi, As part of PR27551 I want to add a string table to the bitcode format to allow global value and comdat names to be shared with the proposed symbol table (and, as side effects, allow comdat names to be shared with value names, make bitcode files more compressible and make bitcode easier to parse). The format of the string table would be a top-level block containing a blob containing

...being efficient to read, because accessing > it is in the critical path of a consumer (i.e. a linker), and the part that > needs to be efficient to read is a relatively small part of the data in the > bitcode file. The same logic applies to the symbol table (note that we use > support::ulittle32_t instead of a bit encoding). > > > The same logic might suggest storing string sizes (as a prefix) to avoid > scanning for string lengths. > It might do, keeping in mind that reading pretty much every existing object file format already requires scanning for string lengths. Certainly...