Re: Minimal core dump mapping set
vijay nag <[email protected]>
| Newsgroups | gmane.comp.gdb.devel |
|---|---|
| Message-ID | <CAKhyrx8xV5ESt1-xVvVafnRLL-pQw92eByHuyVeuu9gT2eUmZw@mail.gmail.com> |
On Wed, Apr 20, 2016 at 10:29 PM, Кукушкин Павел Геннадьевич <[email protected]> wrote: > Dear developers, > > I want to generate core dump file by application itself. Of course it supposed to be compatible with gdb. When I store all anonymous mappings to the file I get no problems. I can see stacks and heaps and so forth. But I want to store only stacks without heap. So I decided to skip anonymous mappings. Here I get in trouble. Gdb can't open that kind of core. I noticed that storing last 4 anonymous mappings (I mean in proc maps list) solves the problem. But how can I be sure that and if the particular mapping is vital for gdb. And what do those mappings keep. > > Thank you for answer, > Pavel Kukushkin, > [email protected] > > > If you are looking for only stacktrace, you don't have to bother about including anonymous mappings of your task. You simply have to dump the stack pages from the current stack-top ($esp or $rsp) till the stack bottom(stack bottom can be the first variable in the main function) in your signal handler if stack pages aren't corrupted(Use madvise or msync to know the sanity of a page). Along with stack pages, you'll need register contents especially ($eip/$rip) for stack crawling. With this data, you can teach GDB to load the stack trace from your core by writing a BFD backend.