From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 72163 invoked by alias); 16 Jan 2020 19:21:44 -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 72153 invoked by uid 89); 16 Jan 2020 19:21:43 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 spammy=ps_err_e, Whatever, H*f:sk:4HqVviD, H*f:sk:c1a3a25 X-HELO: us-smtp-delivery-1.mimecast.com Received: from us-smtp-2.mimecast.com (HELO us-smtp-delivery-1.mimecast.com) (205.139.110.61) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 16 Jan 2020 19:21:33 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1579202492; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=8NyXG3opqbIUqW4gWdpKctSE1LsXpFCN/qx/3AORl+c=; b=Hp8llPv6MOwALPczEczTTaHlEniPefw9RxEVYUmmfPmqTt9XXhT7u2QNX5dXp2EQiMsw57 MAvgHIA/MmtpAYhtA6LTyrnEw5l9gGVxGSgmhI3N43IjkXffZw2YCocdlps23jh3Uu2p0L bQE4lfIsUst9M0+ydXAre17MZQ/ZgCo= Received: from mail-wr1-f70.google.com (mail-wr1-f70.google.com [209.85.221.70]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-152-YOnZ0M9uOGensW05PDzzlQ-1; Thu, 16 Jan 2020 14:21:30 -0500 Received: by mail-wr1-f70.google.com with SMTP id j13so9562026wrr.20 for ; Thu, 16 Jan 2020 11:21:30 -0800 (PST) Return-Path: Received: from ?IPv6:2001:8a0:f913:f700:56ee:75ff:fe8d:232b? ([2001:8a0:f913:f700:56ee:75ff:fe8d:232b]) by smtp.gmail.com with ESMTPSA id x18sm30797316wrr.75.2020.01.16.11.21.27 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 16 Jan 2020 11:21:27 -0800 (PST) Subject: Re: [PATCH][PR build/24805] Explicitly export symbols from gdb_proc_service To: Norbert Lange References: <20200104202004.83439-1-nolange79@gmail.com> <466b1cd0-ce93-15f2-6986-aae17cbee6cf@redhat.com> <6cebf642-05a8-585f-2ec8-786d56820371@redhat.com> Cc: gdb-patches@sourceware.org From: Pedro Alves Message-ID: <8bcb4e8b-3623-62ff-cb44-31ca37b916db@redhat.com> Date: Thu, 16 Jan 2020 19:56:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2020-01/txt/msg00463.txt.bz2 On 1/14/20 4:56 PM, Norbert Lange wrote: > Am Di., 14. Jan. 2020 um 16:36 Uhr schrieb Pedro Alves : >> >> We can't drop support for the glibc header, since that would mean >> to also drop support for the Solaris version of the header, and >> also for whatever other libcs that people build gdb with (e.g., >> does musl have its own version of the header with different types?). >> Up until not so long ago, glibc didn't use to install the header, >> that's why we keep a local copy, IIRC. > > No, you don't get what I am trying to say. > Commonly you only use external headers for function calls, > and the exact definition can vary a bit. > > What you are doing, for ex. in proc-service.c is implementing the function. > > like: >> ps_err_e >> ps_pdread (struct ps_prochandle *ph, psaddr_t addr, void *buf, size_t size) > > you don't get much, if any, information from the header that's not replicated > in the source. The only upside would be to be able to detect mismatches > (but that could be done in a separate test_external_proc_header.c, > potentially even during configuration). > > Whatever other libc's (musl doesnt provide/use this AFAIK) or OS's do, > including their header does not help at all? Well, there's also typedefs, enums, structures. ps_err_e, for example. > > You get no mismatch: Don't need it. > You get a mismatch: you need to fix that in your c file aswell. Or in the header, if the mismatch is in the (non-function) types. > >> >> How about something like this? It's similar to your #2 at >> , but >> I'm using typeof to avoid issues with different systems using >> different prototypes. > > Yeah, that's better, unless typeof is not supported by the compiler > (or its C++ mode). AFAIK, all relevant compilers support it. >>> How about something like this? It's similar to your #2 at >>> , but >>> I'm using typeof to avoid issues with different systems using >>> different prototypes. >> >> BTW, I forgot to mention why I suggested this as alternative >> to the push/pop approach. It was that the push/pop approach >> makes everything indirectly included by >> have default visibility too. I don't know whether that ends >> up being any function in practice, though. > > Yes I am aware of this issue, and its a latent problem I guess. > Normally you don't implement header definitions, so you might be ok. > > Adding tests whether the functions are exported would be nice. Agreed. I've merged this to master now. Thanks, Pedro Alves