Displaying 3 results from an estimated 3 matches for "coff_symbol".
2011 Oct 18
3
[LLVMdev] non-POD type with llvm-objdump
...nx " << unsigned(symbol->NumberOfAuxSymbols) << ") "
<< "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;
suppo...
2011 Oct 19
0
[LLVMdev] non-POD type with llvm-objdump
...unsigned(symbol->NumberOfAuxSymbols) << ") "
> << "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;
> ...
2012 Jan 04
0
[LLVMdev] exposing container-specific features in the Object library
Hello,
The ObjectFile class (in Object/ObjectFile.h) presents a format-independent interface for object files. In addition, for COFF and MachO, some internal format details are exposed in special headers. For example, Object/COFF.h exposes coff_file_header and coff_symbol. Object/MachOFormat.h exposes headers, "segment load commands" and so on.
ELF, however, is not exposed and completely hidden behind the ObjectFile.h interface.
My questions is - what is the reasoning behind this design, which apparently takes 2 different approaches. Is the intention to ev...