From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22489 invoked by alias); 19 Sep 2014 17:39:27 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 22426 invoked by uid 89); 19 Sep 2014 17:39:26 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.2 X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 19 Sep 2014 17:39:24 +0000 Received: from svr-orw-fem-02x.mgc.mentorg.com ([147.34.96.206] helo=SVR-ORW-FEM-02.mgc.mentorg.com) by relay1.mentorg.com with esmtp id 1XV29R-0003G2-1O from Luis_Gustavo@mentor.com ; Fri, 19 Sep 2014 10:39:21 -0700 Received: from [172.30.12.3] (147.34.91.1) by svr-orw-fem-02.mgc.mentorg.com (147.34.96.168) with Microsoft SMTP Server id 14.3.181.6; Fri, 19 Sep 2014 10:39:20 -0700 Message-ID: <541C6A43.2000200@codesourcery.com> Date: Fri, 19 Sep 2014 17:39:00 -0000 From: Luis Machado Reply-To: User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Pedro Alves , "'gdb-patches@sourceware.org'" Subject: Re: [PATCH] MIPS bit field failures in gdb.base/store.exp References: <5413534F.7000705@codesourcery.com> <541C63DF.8090206@redhat.com> In-Reply-To: <541C63DF.8090206@redhat.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2014-09/txt/msg00638.txt.bz2 Hi, On 09/19/2014 02:11 PM, Pedro Alves wrote: > Hi Luis, > > On 09/12/2014 09:10 PM, Luis Machado wrote: > >> Now, GDB knows how to do bit field assignment properly, but MIPS is one >> of those architectures that uses a hook for the register-to-value >> conversion. Although we can properly tell when the type being passed is >> a structure or union, we cannot tell when it is a bit field, because the >> bit field data lives in a value structure. Such data only lives in a >> "type" structure when the parent structure is being referenced, thus you >> can collect them from the flds_bnds members. >> > >> A bit field type structure looks pretty much the same as any other >> primitive type like int or char, so we can't distinguish them. Forcing >> more fields into the type structure wouldn't help much, because the type >> structs are shared. > > If we can't do that, then ... > >> It feels to me GDB's type system is a bit dated and needs to be more >> precise about what it is describing, but for now i just want to fix a >> pending bug. > > ... this leaves me wondering about what you're thinking we'd > do differently if we had infinite time? > That is a dangerous question! It could create infinite work. :-) In a quick response, I'd move that data out of the value struct and put it in the type struct, but that would require additional changes to prevent sharing the base types that have bit field data in them. For a longer answer, i think for everyday normal use GDB's current type mechanism works OK, but if you go beyond that and start doing alternate named address spaces, different kinds of pointers and strange type castings you start to reach the limits of the assumptions GDB makes (or has made in the past). There is definitely room for improvement in the type system. The difficulty to change this is because the type mechanism is a bit entangled with the symbol machinery and the DWARF reader, with potential for breakage. I haven't dealt much with C++ types, but from what I've dealt with, it seems we have some difficulties in there too. Again, it works, but could be better. Anyway, i think this has potential for a bigger and interesting discussion. >> >> The most elegant solution i could find without having to touch a number >> of other type-related data structures is making the >> gdbarch_convert_register_p predicate accept a value structure instead of >> a type structure. That way we can properly tell when a bit field is >> being manipulated in registers. >> >> There is still a little problem though. We don't always have a >> meaningful value struct to pass to this predicate, like both ocurrences >> of it in findvar.c. In those cases i went for a dummy value. >> >> In the end, it is functional but a bit ugly. Unless folks have a better >> suggestion, is this ok? > > Well, why not pass down value_bitsize() (an integer) instead of > the whole value? > I thought about doing that, but seems weird to have a function parameter just for the bit field information. I'm not sure if we're not missing other bits of information that may be useful for register/value conversion, that's why i went with passing the value structure. It holds everything anyway, not just the bit field data. Passing the bit size is OK with me though. >> I did tests with x86, mips32 be/le and mips64 be/le. No regressions found. >> >> The lack of bit field data in the type struct also affects other >> functions that rely on type descriptions, though there may not be >> explicit failures due to those yet. > > That's a bit vague. :-) Got pointers? > I meant the functions that have to act on the type that is passed as a parameter rather than the value itself, like the following: gdbarch_register_to_value gdbarch_value_to_register gdbarch_value_from_register The dummy call hook already acts on the value structs of the parameters, so it doesn't sound totally wrong to want to pass the value struct in this case too. Luis