From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30021 invoked by alias); 25 Jul 2005 20:41:57 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 28912 invoked by uid 22791); 25 Jul 2005 20:40:32 -0000 Received: from palrel11.hp.com (HELO palrel11.hp.com) (156.153.255.246) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Mon, 25 Jul 2005 20:40:32 +0000 Received: from cllmail.cup.hp.com (cllmail.cup.hp.com [15.244.92.83]) by palrel11.hp.com (Postfix) with ESMTP id D24BB341C; Mon, 25 Jul 2005 13:40:30 -0700 (PDT) Received: from [15.244.95.35] (powerbook.americas.hpqcorp.net [15.244.95.35]) by cllmail.cup.hp.com (8.9.3 (PHNE_29774)/8.9.3 SMKit7.04) with ESMTP id NAA20964; Mon, 25 Jul 2005 13:40:30 -0700 (PDT) In-Reply-To: <200507251931.j6PJVpbU032683@elgar.sibelius.xs4all.nl> References: <20050705195104.GA1584@ns1.xcllnt.net> <20050715000144.GB21620@nevyn.them.org> <2845064d598c2c3d2433909ea136f830@cup.hp.com> <20050715021634.GA27723@nevyn.them.org> <81d1f4d6faa9a09741ad6d68f3c1e5a9@cup.hp.com> <20050724212649.GA13210@nevyn.them.org> <20050725173545.GA11163@nevyn.them.org> <03c60378b24ce0cdffee57bd8f06c9d2@cup.hp.com> <200507251931.j6PJVpbU032683@elgar.sibelius.xs4all.nl> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <1d3f3017d5dfb59bdd958da933a8fed3@cup.hp.com> Content-Transfer-Encoding: 7bit Cc: drow@false.org, gdb-patches@sources.redhat.com From: Marcel Moolenaar Subject: Re: [PATCH] New port: ia64-*-freebsd Date: Mon, 25 Jul 2005 20:41:00 -0000 To: Mark Kettenis X-SW-Source: 2005-07/txt/msg00196.txt.bz2 On Jul 25, 2005, at 12:31 PM, Mark Kettenis wrote: > From: Marcel Moolenaar > Date: Mon, 25 Jul 2005 10:58:30 -0700 > > On Jul 25, 2005, at 10:35 AM, Daniel Jacobowitz wrote: > >> On Mon, Jul 25, 2005 at 10:32:27AM -0700, Marcel Moolenaar wrote: >>>> That's where I get confused. How is >>>> the data in the core file mapped onto the memory space? >>> >>> I'm not quite sure I get your drift. Let me just answer what I think >>> you mean: >>> >>> The backing store is nothing more than a second stack. The first >>> being >>> the well-known memory stack onto which (stacked) local variables >>> live. >>> The backing store grows upwards and the memory stack grows downwards. >>> So, in essence, it's a mmap'd region. Either created by the kernel >>> when >>> the process is created, or created by the threading implementation. >>> In the core file the backing store is part of some loadable segment. >>> Either by itself or part of a larger block of memory. >> >> No, that's not what I mean. >> >> Here and further below you think I'm talking about the concept of the >> target object. I'm not. I'm talking specifically about the corefile >> implementation you included. >> >> That implementation reads from an address in memory to find the >> registers. If there's no room for them in memory, where the heck are >> they, and how can you find them by reading from memory? > > They're lost. If the core file is created because the process ran > out > of backing store, then you're pretty much hosed. There's no way you > can get a stack trace because the stacked registers you'll need > first > are the dirty ones and those aren't in the core file. This is the > fundamental problem that Linux has. > > Damn, I'm somehow lost. Are we talking about Linux or FreeBSD here? Both. Currently the FreeBSD kernel "flushes" the dirty stacked registers onto the backing store (i.e. writes it out to the process' memory before the memory map is dumped) because there's no immediate support in the toolchain (both binutils and gdb) for having them "out-of-band" in notes. This is a temporary measure until the toolchain has been enhanced. If and when the toolchain is enhanced, I'll fix the FreeBSD kernel and the statements above will only apply to Linux. > In any case it seems a rather nasty problem. It seems that the kernel > should somehow be able to realise it ran out of backing store, and > stick the stacked registers somewhere else in the core file. This is > what you had in mind for FreeBSD isn't it? Yes. Since we talked about revamping the core file notes prior to FreeBSD 5.3, I did some swift finger-based arithmetic and came to the conclusion that as a first implementation it would be acceptable (for me :-) that this corner case would not be finished. BTW, to get into details: I'll have the kernel dump the dirty stacked registers in a note unconditionally. In other words, even if the core dump doesn't seem to be caused by backing store overflow. The reason for this is that even if the backing store could be written to, the kernel may actually destroy valuable state. Think for example about a multi-threaded application for which the memory stack grows down towards the backing store and the register stack grows upwards to the memory stack. Suppose also that the stacks are not protected from each other by a guard page. Then, writing the dirty stacked registers may cause the kernel to overwrite the memory stack even in the situation that the running process did not overflow either stacks (due to the lazy nature with which the processor flushes dirty registers). Better safe than sorry... > Then, if GDB knew how to > find those dirty registers, it'd be able to do proper backtraces. But > then the user wouldn't be able to tell why the program crashed. It's > probably better to be able to provide a useful backtrace though. Agreed. One can infer that a process dumped core due to an overflow of the backing store. The faulting instruction would typically be the alloc or flushrs instruction and the faulting address would typically be the value of BSPSTORE and would typically point to the first byte of the page after the backing store itself (this last is probably not that easy to figure out because one typically does not know the extend of the backing store, nor can one fully trust that BSPSTORE points inside the backing store). But other than that: there are some telltale signs. *snip* > The proper way to push this out of GDB is (in my opinion) what I did > for StackGhost on OpenBSD/sparc. GDB expects to find a .wcookie > (psuedo-)section in the core file. Filling this section is the job of > platform-dependent code in BFD. For ELF core files the most logical > way would be to provide a note which is converted into that section by > BFD. That's how I would do it for .wcookie in ELF core files anyway. > But since OpenBSD still uses old NetBSD-style core files, this isn't > implemented yet. This whole approach is handled very similar to the > way normal register are handled in core files. Interesting. I'll keep that in mind. I don't know the details about StackGhost, but it might be something to guide me. > >>> All I can say is that I'll think about it: The FreeBSD release >>> schedule >>> is >>> now in my advantage, but getting binutils to grok a whole new kind of >>> core >>> notes may by itself turn out to be... euh... challenging... :-) >> >> Actually it's quite easy. > > Challenge extended... > > ... Challenge accepted :-) > > I think the code that implements NetBSD core file handling is a good > example of how to do this. Yes, you mentioned this before. There was just one problem I ran into: The PID and LWPID are concatenated into a 32-bit integral and passed on the GDB as the "pid". On FreeBSD this cannot be done, because both PID and LWPID are already 32-bit by itself. As such, the BFD to GDB interface for extracting the thread ID needs to be modified if we want to do it right. To be exact: elfcore_make_pid() in binutils/bfd/elf.c needs to be fixed. Anyway: let's not jump ahead. I haven't studied the code lately and things may be much easier now or I may understand the code better than before. -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net