From owner-p4-projects@FreeBSD.ORG Wed Dec 27 19:43:26 2006 Return-Path: X-Original-To: p4-projects@freebsd.org Delivered-To: p4-projects@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 32767) id 58F8016A416; Wed, 27 Dec 2006 19:43:26 +0000 (UTC) X-Original-To: perforce@freebsd.org Delivered-To: perforce@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0B70116A40F for ; Wed, 27 Dec 2006 19:43:26 +0000 (UTC) (envelope-from marcel@freebsd.org) Received: from repoman.freebsd.org (repoman.freebsd.org [69.147.83.41]) by mx1.freebsd.org (Postfix) with ESMTP id F193E13C46D for ; Wed, 27 Dec 2006 19:43:25 +0000 (UTC) (envelope-from marcel@freebsd.org) Received: from repoman.freebsd.org (localhost [127.0.0.1]) by repoman.freebsd.org (8.13.6/8.13.6) with ESMTP id kBRJhPZp091182 for ; Wed, 27 Dec 2006 19:43:25 GMT (envelope-from marcel@freebsd.org) Received: (from perforce@localhost) by repoman.freebsd.org (8.13.6/8.13.4/Submit) id kBRJhPNX091177 for perforce@freebsd.org; Wed, 27 Dec 2006 19:43:25 GMT (envelope-from marcel@freebsd.org) Date: Wed, 27 Dec 2006 19:43:25 GMT Message-Id: <200612271943.kBRJhPNX091177@repoman.freebsd.org> X-Authentication-Warning: repoman.freebsd.org: perforce set sender to marcel@freebsd.org using -f From: Marcel Moolenaar To: Perforce Change Reviews Cc: Subject: PERFORCE change 112174 for review X-BeenThere: p4-projects@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: p4 projects tree changes List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Dec 2006 19:43:26 -0000 http://perforce.freebsd.org/chv.cgi?CH=112174 Change 112174 by marcel@marcel_nfs on 2006/12/27 19:42:41 Save some WIP. Affected files ... .. //depot/projects/gdb/sys/sys/core.h#2 edit Differences ... ==== //depot/projects/gdb/sys/sys/core.h#2 (text+ko) ==== @@ -1,5 +1,5 @@ /*- - * Copyright (c) 2005 Marcel Moolenaar + * Copyright (c) 2005, 2006 Marcel Moolenaar * All rights reserved. * * Redistribution and use in source and binary forms, with or without @@ -30,38 +30,50 @@ #define _SYS_CORE_H_ /* - * Process and thread information is stored as a sequence of (tag,size,value) - * triples. The tag describes what information is being provided, the size - * specifies how many bytes the information occupies, and the value is the - * actual information. This scheme allows any consumer to scan the sequence - * and extract whatever information it knows or cares about, without having - * to understand all the information. Also, it avoids the typical problems - * that structure-based approaches have, which is that third-party software - * and cross-tools often need to hardcode structure offsets to access the - * information as they cannot always depend on the original definition of - * the structure. + * The auxiliary information in a core file is constructed according to the + * definitions in this header. The information thus constructed is stored in + * a core file in a file format specific manner. For ELF based core files, + * it is stored in one or more PT_NOTE sections. The PT_NOTE section is the + * container for the information. + * + * The definitions in this header are designed with the following properties + * in mind: + * 1. The creation of a core file and the auxiliary information contained + * in it can be based on independent sub-procedures with limited scope. + * As such, the context in which each bit of information is placed is + * mostly unknown to the procedure that constructs the information. + * 2. The amount of auxiliary information is highly dynamic. Not only is + * there variation between platforms, there's also variation possible + * based on options and settings. + * 3. The tools that process core files and in particular the auxiliary + * information must be able to extract the information they know and + * care about without being programmed for each and every variation. + * + * Auxiliary process and thread information is stored as a sequence of + * (tag,align,size,value) quadruples. The tag describes what information is + * being provided, the size specifies how many bytes the information + * occupies, the align specifies the alignment constraints and the value is + * the actual information. This scheme allows any consumer to scan the + * sequence of quadruples and extract whatever information it knows or cares + * about, without having to understand all the information. Also, it avoids + * the typical problems that structure-based approaches have, which is that + * third-party software and cross-tools often need to hardcode structure + * offsets to access the information as they cannot always depend on the + * original definition of the structure. */ -struct core_triple { - uint16_t ct_tag; - uint16_t ct_size; - uint8_t ct_value[]; + +struct core_quadruple { + uint32_t cq_tag:12; + uint32_t cq_align:4; + uint32_t cq_size:16; + uint8_t cq_data[]; }; -/* - * The __CT_TAG macro encodes its 14-bit argument in such a way that it is - * possible to detect byte-order mismatches. The most-significant bit of - * the two bytes that make up the tag have different values. When there's - * a byte-order mismatch, these values will be opposite. - */ -#define __CT_TAG_HIGH(b) (0x00 | ((b) & 0x7F)) -#define __CT_TAG_LOW(b) (0x80 | ((b) & 0x7F)) -#define __CT_TAG(v) (__CT_TAG_HIGH((v) >> 7) | __CT_TAG_LOW(v)) - -#define CT_TAG_NOTHING __CT_TAG(0x0000) -#define CT_TAG_OSRELDATE __CT_TAG(0x0001) -#define CT_TAG_PID __CT_TAG(0x0002) -#define CT_TAG_COMM __CT_TAG(0x0003) -#define CT_TAG_SIGNAL __CT_TAG(0x0004) -#define CT_TAG_LWPID __CT_TAG(0x0005) +#define CT_TAG_NOTHING 0x000 +#define CT_TAG_OSRELDATE 0x001 +#define CT_TAG_PID 0x002 +#define CT_TAG_COMM 0x003 +#define CT_TAG_SIGNAL 0x004 +#define CT_TAG_LWPID 0x005 #endif /* _SYS_CORE_H_ */