search for: datarefimpls

Hi everyone, Having proper error handling in LLVM's Object parsing library is a nice thing by itself, but it would additionally allow us to find bugs by fuzzing (see r238451 that adds llvm-dwarfdump-fuzzer tool), for which the clean input validation is essential. This is a generic discussion of state of affairs. I want to do some progress in fuzzing before we finish it (especially if we

On 29 May 2015 at 19:06, Alexey Samsonov <vonosmas at gmail.com> wrote: > Hi everyone, > > Having proper error handling in LLVM's Object parsing library is a nice > thing by itself, but it would additionally allow us to find bugs by fuzzing > (see r238451 that adds llvm-dwarfdump-fuzzer tool), for which the clean > input validation is essential. > > This is a

On Fri, May 29, 2015 at 4:06 PM, Alexey Samsonov <vonosmas at gmail.com> wrote: > Hi everyone, > > Having proper error handling in LLVM's Object parsing library is a nice > thing by itself, but it would additionally allow us to find bugs by fuzzing > (see r238451 that adds llvm-dwarfdump-fuzzer tool), for which the clean > input validation is essential. > > This

...ol iterators were being returned with uninitialized bytes; the type DataRefImpl is a union between 2 32-bit words (d.a and d.b) and a single intptr_t word (p). Only p was being initialized, so in 32-bit builds the result would be iterators with random upper 32-bit words in their DataRefImpls. This caused random failures when seeking around in object files. Let me know if any of this is questionable or you've suggestions on style, as I may submit subsequent bugs along these lines; we're using the LLVM object-file reading facilities in rustc, so will be fixing any bugs w...

With comdats parts of the file might never be read. There are also multiple levels of cache and while all the relocations of a file will fit in ram, it is probably still more efficient to validate them as they are read. But I think (typing on a phone) that relocations are another case where the best is to have a more specific api: the only way the relocation is invalid from the perspective of

On Wed, Oct 12, 2011 at 3:17 AM, Songmao <smtian at ingenic.cn> wrote: > Michael, >    I have rework the patch according to your suggestion.  And I have read > binutil/objdump source code and found that it has a logic that if there's no > symtab, it will use dynsym, which is missing in llvm-objdump. > > Songmao > @@ -747,12 +747,28 @@ error_code

Michael, I have rework the patch according to your suggestion. And I have read binutil/objdump source code and found that it has a logic that if there's no symtab, it will use dynsym, which is missing in llvm-objdump. Songmao -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Fix-the-address-calculation-for-llvm-objdump.patch Type: text/x-patch

Hi David, Sorry, I forget to attach the valgrind dump to this. I was not sure if my implementation was ok, so I wanted to ask if I've done something wrong first. Process terminating with default action of signal 11 (SIGSEGV) Access not within mapped region at address 0xB at 0x54F4516: llvm::object::COFFObjectFile::moveSectionNext(llvm::object::DataRefImpl&) const

Hi folks, I am trying to implement the C bindings API for DebugInfo::DWARF::DWARFDie. My goal is to have a C library that reads and parses DWARF debugging format (just like how llvm-dwarfdump does, but maybe more than just dumping debug info) I've started with creating C structure for DebugInfo::DWARF::DWARFContext which contains all DWARF DIEs in the object file. For this I used ```

Hi, I'm currently working my way through the tutorial with LLVM 3.9.1 on Windows (finished chapter 4) and stumbled over a few things which could be improved: - "LLVMContext" does not exist as a variable -> "TheContext" - Chapter 3: 5 times - Chapter 4: 1 time - Chapter 5: 4 times - Chapter 6: 2 times - Chapter 7: 2 times 3.4. Function Code