From owner-cvs-all Tue Apr 2 17:52: 3 2002 Delivered-To: cvs-all@freebsd.org Received: from kayak.xcllnt.net (209-128-86-226.bayarea.net [209.128.86.226]) by hub.freebsd.org (Postfix) with ESMTP id 1FDEC37B405; Tue, 2 Apr 2002 17:51:57 -0800 (PST) Received: from athlon.pn.xcllnt.net (athlon.pn.xcllnt.net [192.168.4.3]) by kayak.xcllnt.net (8.11.6/8.11.4) with ESMTP id g331pub30229; Tue, 2 Apr 2002 17:51:56 -0800 (PST) (envelope-from marcel@kayak.pn.xcllnt.net) Received: from athlon.pn.xcllnt.net (localhost [127.0.0.1]) by athlon.pn.xcllnt.net (8.12.2/8.12.2) with ESMTP id g331puFI002498; Tue, 2 Apr 2002 17:51:56 -0800 (PST) (envelope-from marcel@athlon.pn.xcllnt.net) Received: (from marcel@localhost) by athlon.pn.xcllnt.net (8.12.2/8.12.2/Submit) id g331pt6e002497; Tue, 2 Apr 2002 17:51:55 -0800 (PST) Date: Tue, 2 Apr 2002 17:51:55 -0800 From: Marcel Moolenaar To: "David O'Brien" Cc: Poul-Henning Kamp , Dag-Erling Smorgrav , Robert Watson , cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/ia64/ia64 ia64dump.c Message-ID: <20020403015155.GB2462@athlon.pn.xcllnt.net> References: <34442.1017781370@critter.freebsd.dk> <20020403003200.GB315@dhcp01.pn.xcllnt.net> <20020402172009.A3970@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020402172009.A3970@dragon.nuxi.com> User-Agent: Mutt/1.3.27i Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, Apr 02, 2002 at 05:20:09PM -0800, David O'Brien wrote: > On Tue, Apr 02, 2002 at 04:32:00PM -0800, Marcel Moolenaar wrote: > > On Tue, Apr 02, 2002 at 11:02:50PM +0200, Poul-Henning Kamp wrote: > > > > > > The format of the header is not architecture dependent, it is the > > > same 512 bytes of the same exact layout on all architectures. > > > > Correct. The endianness is trivially solved: > > You can also get this information from the ELF header itself. You need to interpret the dump header before you can seek to the start of the dump to read the ELF header. Hence, you already need to know the byte order before you can read the ELF header to get the byte order. On top of that, you would create a dependency on what a coredump looks like. This we should avoid, because the number of possibilities is too large to be ignored (ELF, non-ELF; 32-bit, 64-bit; LE, BE) Another approach is to write the dump header in network order and use ntohX. It doesn't really matter that much, as long as you can determine what the byte order is. BTW: I think that dumping in a fixed byte order is probably less troublesome for the kernel than it is for savecore to handle all possible by orders -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message