From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 38516 invoked by alias); 19 May 2017 14:44:12 -0000 Mailing-List: contact newlib-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: newlib-owner@sourceware.org Received: (qmail 38504 invoked by uid 89); 19 May 2017 14:44:11 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM autolearn=no version=3.3.2 spammy=inhouse, in-house, Hx-languages-length:1639, philosophy X-HELO: mail-oi0-f54.google.com Received: from mail-oi0-f54.google.com (HELO mail-oi0-f54.google.com) (209.85.218.54) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 19 May 2017 14:44:10 +0000 Received: by mail-oi0-f54.google.com with SMTP id h4so94545341oib.3 for ; Fri, 19 May 2017 07:44:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=75hNpSA9vj6KehiRgDcLDEQXGz0cvsKuJSdDFOZv9/Y=; b=CfSsTfW6uqqeiU85V4S7jg6FR+pZb0/LDikNmqJn+33uds8j9NwhTsSQS+ahmxw14U gYItMZcM0X5TROUQpMlYShMHp0fNdTxwXUjl2iBIRri2/o+w4v+vrfdpj0ExAUNzzOWk /ZkT6d1ioZxGyZ4EW4XhRc2oSLbaeX1pbUY3+2cLsI1qLsiLmh4odwVAHssgwnTwZMVN JcPDz+zANec9MNCFHKqloQHK60lk9JVu2kN843J8ytZx0fy99su1+8LPEDWHcpAGRe45 dAKzLsZQmp5yJXhJ0QQgnUEQAekvmqx8M6n/THtaYr+Ipddod8tqUwAIn+NUwtfYA296 xtpA== X-Gm-Message-State: AODbwcBV4Ii3FYDSCmEMOH0sABdXw3Wn64Z9xdUNVnrIerK4PP+h/ExI W79FLITPo8IFWXlEGID1v6+bfELoKfrGrQU= X-Received: by 10.157.56.151 with SMTP id p23mr5727218otc.239.1495205052480; Fri, 19 May 2017 07:44:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.15.183 with HTTP; Fri, 19 May 2017 07:44:12 -0700 (PDT) From: Olivier Desenfans Date: Fri, 19 May 2017 14:44:00 -0000 Message-ID: Subject: Externally provided __getreent To: newlib@sourceware.org Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2017/txt/msg00337.txt.bz2 Hello, I am currently experimenting with newlib to try and use it with our in-house embedded real-time operating system. I hit a problem when trying to implement the __getreent function. We already have a thread-local information structure in our custom API. The simple way to do this for me would be to simply add a struct _reent to this structure, make an accessor function, call it __getreent and be done with it. This would all be in our custom API to avoid code duplication (at least for the moment). newlib apparently does not let me do that; you can override the default implementation (in sys/reent/getreent.c) by implementing your own version (in sys/myos/getreent.c). I tried to declare that custom version as a weak symbol so that the linker would replace it with the version in our custom API but to no avail. Interestingly the linker does not throw a duplicate symbol error. There seems to be some magic trickery in the build system that prevents me from achieving this. Therefore I wanted an opinion on a few things: - Is what I want possible? Should there be a patch to add a way to supply __getreent externally (i.e. GETREENT_PROVIDED, just like it is done for malloc)? - In the end my problem is that for various reasons I'd have to reimplement arch-dependent code to retrieve the _reent struct for all the architectures we support (x86, PPC64, ARMv7/8, ...) in newlib as well as our thread info structure. I can avoid this duplication at the cost of a link dependency to our own API. Is it a good idea/does it follow the philosophy of newlib? Thanks, Best regards, Olivier Desenfans