Hi everyone,
I’m currently playing with the clang driver and I encounter a strange bug.
It occurs when I used the getSize function from the SymbolRef class.
On iOS, the number returned is not always correct (some function have the right
size).
Sadly,
This is my code (at the end of the main function into driver.cpp) :
####
ErrorOr<OwningBinary<Binary>> BinaryOrErr = createBinary(file);
if (std::error_code ec = BinaryOrErr.getError()) {
return ec.value();
}
Binary &Binary = *BinaryOrErr.get().getBinary();
object::ObjectFile *objfile;
objfile = dyn_cast<ObjectFile>(&Binary);
for (const SymbolRef &Symbol : objfile->symbols()) {
uint64_t size;
Symbol.getAddress(size);
}
####
During my previous search, I check machODump.cpp in order to see of the list all
the function.
They never use the getSize() but they use the address (getAddress()) of the next
function.
Does anyone have ever heard of a bug with this function or did I do something
wrong?
Greeting,
Johan Wehrli
> On 15.07.2015, at 17:52, Wehrli Johan <johan.wehrli at heig-vd.ch> wrote: > > > Hi everyone, > > I’m currently playing with the clang driver and I encounter a strange bug. > > It occurs when I used the getSize function from the SymbolRef class. > > On iOS, the number returned is not always correct (some function have the right size).Only ELF has usable size information, MachO and COFF do not. That's also the reason why SymbolRef::getSize doesn't exist anymore in LLVM trunk. To get the real sizes you can either use the address trick used by MachODump.cpp or use computeSymbolSizes which wraps this in a convenient API. - Ben> > Sadly, > > This is my code (at the end of the main function into driver.cpp) : > > #### > > ErrorOr<OwningBinary<Binary>> BinaryOrErr = createBinary(file); > if (std::error_code ec = BinaryOrErr.getError()) { > return ec.value(); > } > > Binary &Binary = *BinaryOrErr.get().getBinary(); > object::ObjectFile *objfile; > > objfile = dyn_cast<ObjectFile>(&Binary); > > for (const SymbolRef &Symbol : objfile->symbols()) { > uint64_t size; > Symbol.getAddress(size); > > } > > #### > > During my previous search, I check machODump.cpp in order to see of the list all the function. > > They never use the getSize() but they use the address (getAddress()) of the next function. > > Does anyone have ever heard of a bug with this function or did I do something wrong? > > Greeting, > > Johan Wehrli > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Ok thanks for the answer. I will try the computeSymbolSizes. Johan> On 15 Jul 2015, at 18:07, Benjamin Kramer <benny.kra at gmail.com> wrote: > > >> On 15.07.2015, at 17:52, Wehrli Johan <johan.wehrli at heig-vd.ch> wrote: >> >> >> Hi everyone, >> >> I’m currently playing with the clang driver and I encounter a strange bug. >> >> It occurs when I used the getSize function from the SymbolRef class. >> >> On iOS, the number returned is not always correct (some function have the right size). > > Only ELF has usable size information, MachO and COFF do not. That's also the reason why SymbolRef::getSize doesn't exist anymore in LLVM trunk. To get the real sizes you can either use the address trick used by MachODump.cpp or use computeSymbolSizes which wraps this in a convenient API. > > - Ben > >> >> Sadly, >> >> This is my code (at the end of the main function into driver.cpp) : >> >> #### >> >> ErrorOr<OwningBinary<Binary>> BinaryOrErr = createBinary(file); >> if (std::error_code ec = BinaryOrErr.getError()) { >> return ec.value(); >> } >> >> Binary &Binary = *BinaryOrErr.get().getBinary(); >> object::ObjectFile *objfile; >> >> objfile = dyn_cast<ObjectFile>(&Binary); >> >> for (const SymbolRef &Symbol : objfile->symbols()) { >> uint64_t size; >> Symbol.getAddress(size); >> >> } >> >> #### >> >> During my previous search, I check machODump.cpp in order to see of the list all the function. >> >> They never use the getSize() but they use the address (getAddress()) of the next function. >> >> Does anyone have ever heard of a bug with this function or did I do something wrong? >> >> Greeting, >> >> Johan Wehrli >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >