From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9985 invoked by alias); 1 May 2009 15:37:31 -0000 Received: (qmail 9975 invoked by uid 22791); 1 May 2009 15:37:30 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 01 May 2009 15:37:24 +0000 Received: (qmail 9361 invoked from network); 1 May 2009 15:37:20 -0000 Received: from unknown (HELO orlando) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 1 May 2009 15:37:20 -0000 From: Pedro Alves To: danny.backx@scarlet.be Subject: Re: Post mortem debugging for Windows CE Date: Fri, 01 May 2009 15:37:00 -0000 User-Agent: KMail/1.9.10 Cc: gdb-patches@sourceware.org References: <1240929901.29047.110.camel@dannypc> <200904301058.14585.pedro@codesourcery.com> <1241188513.500.41.camel@dannypc> In-Reply-To: <1241188513.500.41.camel@dannypc> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200905011637.17476.pedro@codesourcery.com> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2009-05/txt/msg00022.txt.bz2 On Friday 01 May 2009 15:35:13, Danny Backx wrote: > I've done some of that, but I'm stuck, I have questions. > > Basically I think I don't find the documentation that says what (from my > new minidump-core.c module) is used to implement things like the > backtrace command. GDB needs registers and the thread's stack memory, so it can unwind the stack, and needs to be tought about the register layout in those ".reg" sections, as that layout differs between machines, ABIs, and core file formats. > warning: "/home/danny/src/gdb/gdb/arm/gdb/examples/Ce042809-01.kdmp": no > core file handler recognizes format, using default You need to fix this. Look at i386-cygwin-tdep.c, and do something similar in arm-wince-tdep.c. You'll need to register a new sniffer in _initialize_arm_wince_tdep (probably for bfd_target_unknown_flavour or for a new minidump flavour you've added?), the sniffer callback can be the current `arm_wince_osabi_sniffer' function, but you'll need to tweak it to return GDB_OSABI_WINCE for your bfd. Then, in arm_wince_init_abi, you need to register a callback with set_gdbarch_regset_from_core_section that extracts the registers from .reg sections. > I see code that creates ".reg", ".crash", ".data" sections. > Where can I find documentation for that ? Docs, who needs stinking docs ?!!!1 :-) I don't know where these things are documented, I just look at src/gdb/corelow.c to see what GDB expects. > Are these the things I need to do ? Yes. In your case, it will be one '.reg/TID' section per thread. The thread that was current at the time of the crash gets a literal ".reg" section, that lives at the same offset as its corresponding ".reg/TID" section. Best look at the sections of a core file on your linux box to see what I mean (objdump -h core). You can borrow bits from bfd/elf.c:_bfd_elfcore_make_pseudosection for this. ".crash" isn't used by GDB, it seems specific to cisco cores. It doesn't matter the name of the section that contains data (only the section flags count), but ".data" is fine. I (re-)suggest to also add a ".module" section, containing the list of loaded dlls, and their load addresses, and then to copy the bits from i386-cygwin-tdep.c to arm-wince-tdep.c that parse that section --- start with this bit: set_gdbarch_core_xfer_shared_libraries (gdbarch, windows_core_xfer_shared_libraries); It looks to me that this ends sharing significant chunks of code between arm-wince-tdep.c and i386-cygwin-tdep.c, so we could move those bits of shared code to windows-tdep.c. -- Pedro Alves