From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id E6060385B835 for ; Sun, 29 Mar 2020 22:10:20 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org E6060385B835 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=simark.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=simark@simark.ca Received: from [10.0.0.11] (unknown [192.222.164.54]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 5F3E81E5F8; Sun, 29 Mar 2020 18:10:20 -0400 (EDT) Subject: Re: [PATCH v3] Add support for "info auxv" on NetBSD To: Kamil Rytarowski , gdb-patches@sourceware.org Cc: tom@tromey.com References: <20200316181710.7542-1-n54@gmx.com> <20200320172739.26705-1-n54@gmx.com> From: Simon Marchi Message-ID: Date: Sun, 29 Mar 2020 18:10:19 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: <20200320172739.26705-1-n54@gmx.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US-large Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-12.9 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Mar 2020 22:10:22 -0000 On 2020-03-20 1:27 p.m., Kamil Rytarowski wrote: > @@ -47,3 +48,40 @@ nbsd_pc_in_sigtramp (CORE_ADDR pc, const char *func_name) > return (func_name != NULL > && startswith (func_name, "__sigtramp")); > } > + > +/* NetBSD-specific parser for AUXV data with. NetBSD follows the ELF > + specification, contrary to some other ELF Operating Systems. */ > + > +static int > +nbsd_auxv_parse (struct gdbarch *gdbarch, gdb_byte **readptr, > + gdb_byte *endptr, CORE_ADDR *typep, CORE_ADDR *valp) > +{ > + struct type *int_type = builtin_type (gdbarch)->builtin_int; > + struct type *ptr_type = builtin_type (gdbarch)->builtin_data_ptr; > + const int sizeof_auxv_type = TYPE_LENGTH (int_type); > + const int sizeof_auxv_val = TYPE_LENGTH (ptr_type); > + enum bfd_endian byte_order = gdbarch_byte_order (gdbarch); > + gdb_byte *ptr = *readptr; > + > + if (endptr == ptr) > + return 0; > + > + if (endptr - ptr < 2 * sizeof_auxv_val) > + return -1; > + > + *typep = extract_unsigned_integer (ptr, sizeof_auxv_type, byte_order); > + ptr += sizeof_auxv_val; /* Alignment. */ > + *valp = extract_unsigned_integer (ptr, sizeof_auxv_val, byte_order); > + ptr += sizeof_auxv_val; >From this code, I understand that on AMD64/NetBSD, an auxv entry looks like (each character is a byte): T T T T P P P P V V V V V V V V Where T is the type value, P is padding and V is value. Is that right? > + > + *readptr = ptr; > + return 1; > +} Instead of defining this function that is very similar to default_auxv_parse, I would strongly suggest making a parametrized version of default_auxv_parse (and make default_auxv_parse use it). Simon