From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6577 invoked by alias); 26 May 2017 19:48:56 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 122265 invoked by uid 89); 26 May 2017 19:48:28 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy= X-HELO: mail-qk0-f172.google.com X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=gGCRN8qv7EuR0w1Y9p+hs8pIXVwjuDsCj5RsfUTrqI0=; b=uPoXK8TO6cfSFbS42X8qI8t2x0MoJAvC8zKDb5wOlBjX/UGzq59L8vDxSmxWJ8C/MG zLwxjKTHXV2eYrmPaW1mqWke95ds8U0hhHF25gFG0LQzc0ETxHmWvsdM+wJdjVkN+8yj dtDJd1e1Wduhign8QAb7TBQjxtBWCTsOB+i6HZQRydc/Vx6VipNRt04mRGTsHuvVo9Qt ZZ2bLcqzAWtzjA5ktHiJXMIU4G0TmD6AmpgdYK11s7fTbTDfUgRbCgD714L0KEEwYkVN d2MzEle7LdASm8xtmpRJz1ZAB9Hz+T4rupzCTQoOZHTmwZLiiivHmJi3HxOQLSfB8POl 0yDQ== X-Gm-Message-State: AODbwcAy8lGjh0wi+BawxHrEKRrz9i+nbYL66Rxq8BsLJZ7n4xBfNBk7 Oe3avQfpBvxKvN2Kf+aWrQ== X-Received: by 10.55.18.68 with SMTP id c65mr3649237qkh.41.1495828098903; Fri, 26 May 2017 12:48:18 -0700 (PDT) Subject: Re: Pulling libgcc compat symbols out of libgcc.a To: libc-alpha@sourceware.org References: From: Adhemerval Zanella Message-ID: Date: Fri, 26 May 2017 19:48:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-SW-Source: 2017-05/txt/msg00811.txt.bz2 On 24/05/2017 15:26, Zack Weinberg wrote: > In https://sourceware.org/ml/libc-alpha/2017-05/msg00453.html I asked > why the architectures that need to put exposed compatibility versions > of libgcc symbols into libc.so don't get their definitions from > libgcc.a (or, in other words, why ./sysdeps/wordsize-32/divdi3.c > exists in our source tree), and after a bit of confusion Joseph > replied that current libgcc defines these as hidden, unversioned > symbols and he didn't know any way to fix that. > > Well, it *appears* that it can be fixed with objcopy: > > $ ar x libgcc.a divdi3.o # this is gcc6/i386 libgcc.a > $ readelf -s _divdi3.o > > Symbol table '.symtab' contains 7 entries: > Num: Value Size Type Bind Vis Ndx Name > 0: 00000000 0 NOTYPE LOCAL DEFAULT UND > 1: 00000000 0 SECTION LOCAL DEFAULT 1 > 2: 00000000 0 SECTION LOCAL DEFAULT 2 > 3: 00000000 0 SECTION LOCAL DEFAULT 3 > 4: 00000000 0 SECTION LOCAL DEFAULT 4 > 5: 00000000 0 SECTION LOCAL DEFAULT 5 > 6: 00000000 362 FUNC GLOBAL HIDDEN 1 __divdi3 > > $ objcopy --add-symbol __divdi3@GLIBC_2.0=.text:__divdi3,function,global \ > --strip-symbol __divdi3 _divdi3.o _divdi3_g.o > $ readelf -s _divdi3_g.o > > Symbol table '.symtab' contains 7 entries: > Num: Value Size Type Bind Vis Ndx Name > 0: 00000000 0 NOTYPE LOCAL DEFAULT UND > 1: 00000000 0 SECTION LOCAL DEFAULT 1 > 2: 00000000 0 SECTION LOCAL DEFAULT 2 > 3: 00000000 0 SECTION LOCAL DEFAULT 3 > 4: 00000000 0 SECTION LOCAL DEFAULT 4 > 5: 00000000 0 SECTION LOCAL DEFAULT 5 > 6: 00000000 0 FUNC GLOBAL DEFAULT 1 __divdi3@GLIBC_2.0 > > (Yes, a versioned symbol really is just a regular symbol table entry > with @WHATEVER tacked on the end of its name, at least in an .o file. > I checked.) > > The only differences (ignoring the actual contents of the text > section) I can find between this object file and the one we currently > get from shlib-compat.h are that this file doesn't have an unsuffixed > definition of __divdi3 (which is fine, because the version script > would strip it anyway) and the new __divdi3@GLIBC_2.0 symbol doesn't > have a size annotation (which I *think* is harmless). > > But before I do a lot of painful mucking around in the Makefiles to > make this happen, I'd like to ask whether there's any reason this > won't work. I used to know ELF inside and out, but that was a long > time ago and there's a lot I've forgotten. I can't really tell if it won't work, but I am not very found of this approach for some reasons: * It does not guarantee to solve any problem described in your description. If the architecture backends still emits about for __buitin_trap it will continue potentially pull abort where it should not. For second problem, it can potentially be fixed by pulling libgcc.a implementation, but we can also just keep both in sync. These are usually stable implementation that do not change over time, so keep them in sync is not usually a burden. * Maybe glibc will never support other build compiler than gnu ones, but I would like to avoid add more tooling specific features and simplify general building. I know we already have specific binutils version as pre-requisite, but for this specific case I see no straightforward gain of adding another external tool support as build pre-requisite.