From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5674 invoked by alias); 26 Mar 2013 22:30:04 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 5587 invoked by uid 89); 26 Mar 2013 22:29:56 -0000 X-Spam-SWARE-Status: No, score=-4.9 required=5.0 tests=BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RP_MATCHES_RCVD autolearn=ham version=3.3.1 Received: from mail.stusta.mhn.de (HELO mail.stusta.mhn.de) (141.84.69.5) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Tue, 26 Mar 2013 22:29:53 +0000 Received: from [10.150.42.66] (r042066.stusta.swh.mhn.de [10.150.42.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.stusta.mhn.de (Postfix) with ESMTPS id 48F4F194F0 for ; Tue, 26 Mar 2013 23:29:49 +0100 (CET) Message-ID: <5152215D.4060605@stusta.mhn.de> Date: Tue, 26 Mar 2013 22:30:00 -0000 From: Markus Teich User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: gdb@sourceware.org Subject: Re: unexpected output from print References: <4dbff288e0c76a516273ba1cb19694b4@mail.fs.tum.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-SW-Source: 2013-03/txt/msg00077.txt.bz2 Thanks, that helped a lot. @Tom: I am already using the machine interface, but unfortunately the functions for symbol querying are not implemented in gdbmi (the C library), therefore i parse the output of -data-evaluate-expression manually. Since gdbmi is not developed actively anymore: Is there a better way to use the gdb machine interface from a C program? --Markus Am 26.03.2013 02:09, schrieb Sergio Durigan Junior: > On Saturday, March 23 2013, Markus Teich wrote: > >> Yesterday i stumbled upon an unexpected case, where gdb would output a >> single value without the attribute name in a struct: >> __in6_u = {__u6_addr8 = "325243A2", '\000' , >> __u6_addr16 = {41941, 12865, 0, 0, 0, 0, 0, 0}, __u6_addr32 = >> {843162581, 0, 0, 0}} > > This is because GDB is telling you what's the value of every byte of > this union according to the interpretation each field's type. `uint8_t' > is actually `unsigned char' on most architectures, so it is treating the > `__u6_addr8' field as an array of characters. > > If you use pretty-printing, you will see things more organized. Try > `set print pretty on', and print the struct again. Then you will > understand that the output is actually something like: > > __in6_u = { > __u6_addr8 = "325243A2", '\000' , > __u6_addr16 = {41941, 12865, 0, 0, 0, 0, 0, 0}, > __u6_addr32 = {843162581, 0, 0, 0} > } > > I.e., the `'\000' ' part refers to the first field, > and is not a second-field-without-a-name as you guessed. > > In short: if you want GDB to stop printing the '\000' part, try using > `set print null-stop on'. >