From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 98369 invoked by alias); 15 Nov 2017 01:35:36 -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 98353 invoked by uid 89); 15 Nov 2017 01:35:36 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.4 required=5.0 tests=AWL,BAYES_00,KB_WAM_FROM_NAME_SINGLEWORD,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=no version=3.3.2 spammy=debate X-HELO: rock.gnat.com Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 15 Nov 2017 01:35:34 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 2398A1162D1; Tue, 14 Nov 2017 20:35:33 -0500 (EST) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id zstzNhKeXeIA; Tue, 14 Nov 2017 20:35:33 -0500 (EST) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id E4AFA1162B6; Tue, 14 Nov 2017 20:35:32 -0500 (EST) Received: by joel.gnat.com (Postfix, from userid 1000) id 2A4A387459; Tue, 14 Nov 2017 17:35:31 -0800 (PST) Date: Wed, 15 Nov 2017 01:35:00 -0000 From: Joel Brobecker To: Pedro Alves Cc: gdb-patches@sourceware.org Subject: Re: RFC: problems with minimal symbols (without a type) Message-ID: <20171115013531.cwj5pzjttrihofhl@adacore.com> References: <20171109012540.ds5ixw4pq6rclhgc@adacore.com> <4bca71af-2877-2adf-9f54-e51d7e6b5b8b@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4bca71af-2877-2adf-9f54-e51d7e6b5b8b@redhat.com> User-Agent: NeoMutt/20170113 (1.7.2) X-SW-Source: 2017-11/txt/msg00263.txt.bz2 > > And unfortunately, the Ada equivalent of casting does not work either: > > > > (gdb) print integer(constraint_error) > > 'constraint_error' has unknown type; cast it to its declared type > > Shouldn't we just make that work, like it works for C? Of course. It's at the top of my list, and independent in my mind of the discussion about forcing the cast. It was a convenient work-around, however, allowing me to reduce the urgency to fix this issue with casting. That being said... > Let me quote a conversation that happened on IRC just last week > (user name anonymized): [...] > you have to cast malloc to the right function pointer type, and then call that. > something like: p ((void * (*) (size_t )) malloc) (128) > in master, the simpler 'p (void*)malloc (128)' does the right thing. > (it infers the prototype from the type of the passed in arguments + the cast-to type) I understand why GDB now behaves more naturally when using the casting information to infer the symbol's type and how this is an improvement. But wouldn't that part be orthogonal to the question whether GDB should make this case mandatory or not? This is probably a judgement call. And since I didn't comment on the patch when it was proposed, I suppose it's fair that I try it for Ada users as well, and see how they react. It'll keep the languages consistent too, which is an advantage. Just to answer some of your questions (therefore not in the spirit of continuing a debate): > At least an Ada conversion/cast is Ada syntax. > The "print {my_type} minsym'address" syntax above looks like > the GDB syntax/extension that works with C too? Yes, this part is documented in the Ada section of the GDB manual. > How do users discover that that gdb syntax extension is available > and that they need to use it? > For non-integer types, users must already do some casting to get at > the real data. Why treat integers differently? For me, this is because those minimal symbols are typically integral types. So, for a non-trivial part of the times I use this feature, it actually gives me the right answer. Therefore, for me, GDB lost a small feature that didn't always work, but still did work for a good chunk of the scenarios I was involved in. I'll work on fixing the casting whenever I find some time... That got me to one piece of code in evaluate_subexp_for_cast: /* Don't allow e.g. '&(int)var_with_no_debug_info'. */ if (VALUE_LVAL (val) == lval_memory) { if (value_lazy (val)) value_fetch_lazy (val); VALUE_LVAL (val) = not_lval; } I was wondering why do we not want to allow someone get its address? I checked the commit that introduced this change, and it doesn't say. Thanks for the feedback, -- Joel