On Mon, 15 Sep 2014 19:33:42 +0200, Timur Iskhodzhanov <timurrrr at google.com> wrote:> Basically, see my patches to LLVM from early 2014 -- they include tests, > a DI generator and a DI dumper. I'd be happy to review your patches too!Thanks. Looks like it's likely that it's one of the 0xF1 sections, the first one always has the object file name and what seems the compiler name and flags. I cloned that whole thing and it didn't make it work. If I had to guess it would be that it's one of the other two 0xF1 blocks but I can't find any information on those besides the basic format (Len: UInt16, Type: UInt16, Data), these new codeview block types I can't find at all though, at this point I'm rather stuck. -- Carlo Kok RemObjects Software -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140915/3fc97a95/attachment.html>
I *think* the problem is in the sections we already generate, not the 0xF1 ones. 2014-09-16 1:46 GMT+04:00 Carlo Kok <ck at remobjects.com>:> On Mon, 15 Sep 2014 19:33:42 +0200, Timur Iskhodzhanov < > timurrrr at google.com> wrote: > > Basically, see my patches to LLVM from early 2014 -- they include tests, a > DI generator and a DI dumper. I'd be happy to review your patches too! > > > Thanks. Looks like it's likely that it's one of the 0xF1 sections, the > first one always has the object file name and what seems the compiler name > and flags. I cloned that whole thing and it didn't make it work. If I had > to guess it would be that it's one of the other two 0xF1 blocks but I can't > find any information on those besides the basic format (Len: UInt16, Type: > UInt16, Data), these new codeview block types I can't find at all though, > at this point I'm rather stuck. > > > > -- > Carlo Kok > RemObjects Software >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140916/90037903/attachment-0002.html>
On Tue, 16 Sep 2014 12:48:11 +0200, Timur Iskhodzhanov <timurrrr at google.com> wrote:> I *think* the problem is in the sections we already generate, not the > 0xF1 ones.Doesn't look like it, the only thing we currently don't do is put 0x0110, md5 hash in DEBUG_INDEX_SUBSECTION instead of the 0x00 00 00 00, I tried that and nothing happens. The line table and string table look exactly the same. -- Carlo Kok RemObjects Software -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140916/f99be2ef/attachment.html>