From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8491 invoked by alias); 25 Sep 2014 19:32:10 -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 8474 invoked by uid 89); 25 Sep 2014 19:32:09 -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; Thu, 25 Sep 2014 19:32:07 +0000 Received: from svr-orw-fem-03.mgc.mentorg.com ([147.34.97.39]) by relay1.mentorg.com with esmtp id 1XXElo-00043o-5Y from Luis_Gustavo@mentor.com ; Thu, 25 Sep 2014 12:32:04 -0700 Received: from [172.30.13.9] (147.34.91.1) by svr-orw-fem-03.mgc.mentorg.com (147.34.97.39) with Microsoft SMTP Server id 14.3.181.6; Thu, 25 Sep 2014 12:32:03 -0700 Message-ID: <54246DAE.6080208@codesourcery.com> Date: Thu, 25 Sep 2014 19:32: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> <541C6A43.2000200@codesourcery.com> In-Reply-To: <541C6A43.2000200@codesourcery.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2014-09/txt/msg00745.txt.bz2 On 09/19/2014 02:39 PM, Luis Machado wrote: > 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. ping! Any ideas on different approaches suitable for this problem or is the proposed fix ok (with either passing a value struct or a bit size)? Thanks, Luis