[lldb-dev] [8.0.0 Release] Release schedule
Hello everyone, I know 7.0.1 isn't out the door yet, and 8.0.0 isn't due for a while, so relax :-) But I would like to get the schedule decided before folks disappear over the holidays. According to the usual schedule, the branch would be created two weeks into January, with the goal of shipping early March, so this is my proposal: - 16 January 2019: Create the 8.0.0 branch, RC1 tagged soon after. - 6 February, RC2 tag. - 27 February, Final tag, release shipping a few days after. What do you think, especially release testers? For the 6.0.0 release, the branch was created earlier in January after a request from the community. This time I haven't heard anything, but please let me know if a different schedule would be better for you. Ideally I'd like to finalize and post the schedule by the end of the week. Thanks, Hans ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] Adding breakpad "symbol" file support
Hello all, I'd like to propose adding support for reading breakpad symbol files to LLDB. The breakpad files are textual files, which contain just enough information to produce a backtrace from a crash dump. This information includes: - UUID, architecture and name of the module - line tables - list of symbols - unwind information They are meant to complement the "minidump" files (already supported by lldb), which are the "core" files produced by breakpad when an application crashes. A minimal breakpad file could look like this: MODULE Linux x86_64 24B5D199F0F766FF5DC30 a.out INFO CODE_ID B52499D1F0F766FF5DC3 FILE 0 /tmp/a.c FUNC 1010 10 0 _start 1010 4 4 0 1014 5 5 0 1019 5 6 0 101e 2 7 0 PUBLIC 1010 0 _start STACK CFI INIT 1010 10 .cfa: $rsp 8 + .ra: .cfa -8 + ^ STACK CFI 1011 $rbp: .cfa -16 + ^ .cfa: $rsp 16 + STACK CFI 1014 .cfa: $rbp 16 + Even though this data would normally be considered "symbol" information, in the current lldb infrastructure it is assumed every SymbolFile object is backed by an ObjectFile instance. So, in order to better interoperate with the rest of the code (particularly symbol vendors). I propose to also add an ObjectFileBreakpad class to access the breakpad file at a lower level. My plan tentative plan is to present the individual chunks of the breakpad file as ObjectFile , which can then be used by other parts of the codebase (SymbolFileBreakpad ?) to vend the necessary information. I have a preliminary patch (D55214), which adds the scaffolding necessary to recognise breakpad files as on object format, and parses the information in the breakpad header (i.e., it's UUID and architecture). The other parts are to be added later. Please let me know if you have any questions or concerns about this, pavel ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Adding breakpad "symbol" file support
Yay! In case anyone is interested in the details, the Breakpad symbol format is documented here: https://chromium.googlesource.com/breakpad/breakpad/+/master/docs/symbol_files.md On Mon, Dec 3, 2018 at 5:39 AM Pavel Labath via lldb-dev < lldb-dev@lists.llvm.org> wrote: > Hello all, > > I'd like to propose adding support for reading breakpad symbol files to > LLDB. > > The breakpad files are textual files, which contain just enough > information to produce a backtrace from a crash > dump. This information includes: > > - UUID, architecture and name of the module > - line tables > - list of symbols > - unwind information > > They are meant to complement the "minidump" files (already supported by > lldb), which are the "core" files produced by breakpad when an > application crashes. > > A minimal breakpad file could look like this: > MODULE Linux x86_64 24B5D199F0F766FF5DC30 a.out > INFO CODE_ID B52499D1F0F766FF5DC3 > FILE 0 /tmp/a.c > FUNC 1010 10 0 _start > 1010 4 4 0 > 1014 5 5 0 > 1019 5 6 0 > 101e 2 7 0 > PUBLIC 1010 0 _start > STACK CFI INIT 1010 10 .cfa: $rsp 8 + .ra: .cfa -8 + ^ > STACK CFI 1011 $rbp: .cfa -16 + ^ .cfa: $rsp 16 + > STACK CFI 1014 .cfa: $rbp 16 + > > Even though this data would normally be considered "symbol" information, > in the current lldb infrastructure it is assumed every SymbolFile object > is backed by an ObjectFile instance. So, in order to better interoperate > with the rest of the code (particularly symbol vendors). I propose to > also add an ObjectFileBreakpad class to access the breakpad file at a > lower level. My plan tentative plan is to present the individual chunks > of the breakpad file as ObjectFile , which can then be used by > other parts of the codebase (SymbolFileBreakpad ?) to vend the necessary > information. > > I have a preliminary patch (D55214), which adds the scaffolding > necessary to recognise breakpad files as on object format, and parses > the information in the breakpad header (i.e., it's UUID and > architecture). The other parts are to be added later. > > Please let me know if you have any questions or concerns about this, > pavel > ___ > lldb-dev mailing list > lldb-dev@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
