From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id CD7373858433 for ; Mon, 15 May 2023 11:13:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org CD7373858433 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1684149230; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=GlH89ggqyMESCIi+y2cdjCa+WRGy4OkG+nUFE4VN1MM=; b=SsAIixGaf/XYUQ2k3PxzAxR+pJ5zj/7zS96+wbKdbrnXpActQ1dlC4uTvNThNkKHsqIhRH D1VvIZ95gJJkPg8CP/299pOwOsaS0zVD1qRJoPt94H6/uczuokiqwIAopsXIS12fKxMSEM e+Tg5zoWuyksljbHPuDgmvn3oOLhE2Q= Received: from mail-qv1-f72.google.com (mail-qv1-f72.google.com [209.85.219.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-512-bVSuLIH2O02CG0RO7yCy9w-1; Mon, 15 May 2023 07:13:49 -0400 X-MC-Unique: bVSuLIH2O02CG0RO7yCy9w-1 Received: by mail-qv1-f72.google.com with SMTP id 6a1803df08f44-61b591eb0cfso62602966d6.2 for ; Mon, 15 May 2023 04:13:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684149228; x=1686741228; h=content-transfer-encoding:in-reply-to:subject:from:references:to :content-language:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=GlH89ggqyMESCIi+y2cdjCa+WRGy4OkG+nUFE4VN1MM=; b=ddN8omrFZ38hYGXL0ovx1lebuT6O7hqA8nXmuWWuEJUKhF15j4f7Tx/4bdpKMVbs8F ajdlghdpUxXRTAKdLXA4JZcJm+TNT1TmBiVqXlahjyS4OdpSIbl27u+byYc8GknKt8us FIyCVYuCaQWqF8MebXf9LxMmAxYi3yBjYkBReCdbdWM8ktg4xmmDNrqODTlGDHZSQGCm 28UXxrfP5P+O0HxtL7oE9GvkJVj84DDtVt7Ms+Ou+VXOAwvK7C+EsGlTKNc6p2mLKfRU O66USLeFBPyMGvRl685IZx+y+GNy6MXuHp2bwZjR44xb+s5ZZbj6svUFBmmhdvTLGzuU 10Xw== X-Gm-Message-State: AC+VfDzw2yslbQ2MzLo9ox4SEVFpy+9YvV4kjrDg2mH3ZqLz79QVpC2P CnoZSeDrqE3TDtpAtp4+2CgV96fLJTkvLId91jjpKN+BheoV6bH4+6XziT3r+vPeReC6lXDsOJg jE99jKjAVHa3V3q9oRj6lLQF5rg== X-Received: by 2002:a05:6214:1c88:b0:5ef:4455:fd35 with SMTP id ib8-20020a0562141c8800b005ef4455fd35mr45095368qvb.4.1684149228386; Mon, 15 May 2023 04:13:48 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ6tz/8fs7RUo9VWBO+0FlUeImzYZEJEJGBQn7pyr/iYgcjrxBdifcaFnbJiRD1kRwRUZSE19w== X-Received: by 2002:a05:6214:1c88:b0:5ef:4455:fd35 with SMTP id ib8-20020a0562141c8800b005ef4455fd35mr45095343qvb.4.1684149228126; Mon, 15 May 2023 04:13:48 -0700 (PDT) Received: from [192.168.1.7] ([79.123.86.193]) by smtp.gmail.com with ESMTPSA id z9-20020a0cd789000000b005e750d07153sm4862802qvi.135.2023.05.15.04.13.47 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 15 May 2023 04:13:47 -0700 (PDT) Message-ID: <1b22c812-9575-5709-d6fc-09a18f157ffc@redhat.com> Date: Mon, 15 May 2023 12:13:39 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 To: Indu Bhagat , binutils@sourceware.org References: From: Nick Clifton Subject: Re: Changes to libsframe ABI In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-GB Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.9 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hi Indu, > I would like to make an existing API sframe_get_funcdesc_with_addr () static. The interface provided by this function is not a healthy abstraction to expose: the return > type is sframe_func_desc_entry, which is defined in include/sframe.h (the SFrame binary format definition). This ties up the library in a undesirable way.  Most > importantly, this function should technically not be directly necessary for _any_ external customer, like a stack tracer.  A stack tracer should only need to do a > sframe_find_fre (). > > I would like to make it static because this API should only be needed (and used) internally in the library, at least in the current form. > > Is it okay to make such a change ?  The first release of libsframe was Binutils 2.40. I do not expect any users of sframe_get_funcdesc_with_addr () out there currently. > IMO, this is OK to do. WDYT ? I think that it can be done, but you should allow for the possibility that there are programs out there that are using the function. So I would suggest: * Increase the version number of the library (to version N+1). * Rename sframe_get_funcdesc_with_addr to something else, such as sframe_get_funcdesc_with_addr_internal. Make this new function static, or use the hidden visibility if you need it accessible from everywhere inside libsframe. * Update all places where the old function name was used in the libsframe library. * Create a new dummy function called sframe_get_funcdesc_with_addr and have it just return null or whatever error value it was supposed to return if things went wrong. Change the return type of the function to void *. Add a comment to the prototype of the function in whichever header file documents it. The comment should indicate that the function is deprecated and will be removed in version N+2. * Wait a year and release version N+2 without the function... > A larger question still looms over as well: The library is young at this time, and making guarantees of a stable ABI in the current shape looks limiting to me. Apart from > the above change, I would also like to make some further changes to other existing APIs (which will also break the ABI). How can this be managed without causing pain ? This sounds like a situation where you would want to use symbol versioning. You could have old and new versions of functions with different ABIs, and applications can be built to use the version that they prefer. The glibc library for example makes extensive use of this feature. Cheers Nick