From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/10989 Path: news.gmane.org!.POSTED!not-for-mail From: He X Newsgroups: gmane.linux.lib.musl.general Subject: Re: Re: a bug in bindtextdomain() and strip '.UTF-8' Date: Mon, 30 Jan 2017 20:36:41 +0800 Message-ID: References: <20170129133946.GT17692@port70.net> <20170129140747.GJ1533@brightrain.aerifal.cx> <20170129164008.GU17692@port70.net> <20170129164916.GN1533@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=94eb2c1234587d867405474f1268 X-Trace: blaine.gmane.org 1485779838 20112 195.159.176.226 (30 Jan 2017 12:37:18 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 30 Jan 2017 12:37:18 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-11004-gllmg-musl=m.gmane.org@lists.openwall.com Mon Jan 30 13:37:13 2017 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1cYBCr-0004zC-5N for gllmg-musl@m.gmane.org; Mon, 30 Jan 2017 13:37:13 +0100 Original-Received: (qmail 16243 invoked by uid 550); 30 Jan 2017 12:37:14 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 16214 invoked from network); 30 Jan 2017 12:37:13 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=f5pyVDdUoYIEarvC/FnHYtLE8j2cAP4IeIFcqUsJs40=; b=a+LkeXNoZuWb7mAC7t0zvJw1alZJZvPjWSho/LZ5JwyuVzxYmvVj90vEXiqiWPPnvL WEWAGGSFCV0nsy57leTkBd86CCn2tQ/RFlinNvertP8a7+ThFE854jlG9UteTsicL0Ht Hb99kkVnu9MC/hcyOZ3DRwWnayrAW8o+erVYRvDQR7qS23KRkxbeqDc1RMEbUnGw6tMS QGIzm2+LabTowjYX/AagOiuQuyngn9mP9mg99xIe1uRevL1ThovPoKbRQA1AoQVlyrF+ VfY0NG/7CS3mE1ZdWERZ1ljSgGIKm08SPFMCHoQ8lQHMpJHT64qCcuni1CgbMbOy+X7U n/AA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=f5pyVDdUoYIEarvC/FnHYtLE8j2cAP4IeIFcqUsJs40=; b=pqpueru4O5PG54+0G3xOmX01qBw8d35B2aY82w7WmIH1W/qwfBY7EnsOuYADmTQwry pingk8/nF8T2kpWP2r6+kCo3WNzxqxS3LIyipJd0hJXU+YM3ZiAJVeT02+6sWPLWAuw0 Yne22zzavqIyRttfR5QP+zj/+LMEDK9SS9+/g0fzjwEospWCXN/sYFTMC27N5YRY1zZR jktt7sdw9K73wZ9mh1ccYiA4aPCpX+icc7Xpx5XG8vWu69gIXr+nZ80dcJXlZf2Zoj8g PHjd2Esn5sEf/TVXVH45+3lbUGmc22s5N+RU4Q2xHSnpVPsin3IdKXiQWZlOlHj3lJgy ZQyw== X-Gm-Message-State: AIkVDXK7OGX39hobmJOAOFEARn6Z84HGpZ1ElX3b/iOt+kMV7WSNIt+Pfie95sPXvFXkfoEnQn0gWBEogJin1A== X-Received: by 10.159.39.199 with SMTP id b65mr9088355uab.3.1485779821755; Mon, 30 Jan 2017 04:37:01 -0800 (PST) In-Reply-To: <20170129164916.GN1533@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:10989 Archived-At: --94eb2c1234587d867405474f1268 Content-Type: text/plain; charset=UTF-8 worked! http://paste.ubuntu.com/23893379/ -su-4.4# nm -D /usr/lib/libstdc++.so.6 |grep __locale_struct |wc -l 0 anything i missed? it it acceptable ? and how could i post this to the upstream? 2017-01-30 0:49 GMT+08:00 Rich Felker : > On Sun, Jan 29, 2017 at 05:40:08PM +0100, Szabolcs Nagy wrote: > > * He X [2017-01-29 22:48:34 +0800]: > > > 2. no other ways, musl will use generic config 100%, and then the > > > exception, the run time error is hardcoded there; but i doubt if this > > > really breaks binaries, the function is only called by libstdc++ > itself. > > > you cant only update the config, but does not update libstdc++. > libstdc++ > > > exported the same abi for common binaries, wont break most > dynamic-loaded > > > binary in my view. > > > > that's not how abi works.. you change the __c_locale typedef > > of the generic config from int* to locale_t, such change > > breaks abi and cannot be upstreamed to gcc. (it's unfortunate > > that the c++ locale handling default for non-gnu systems > > does not use posix locales correctly, but breaking abi > > for all non-gnu systems is not an acceptable fix.) > > > > with your change the abi of libstdc++ would look like > > the current gnu abi: > > > > $ grep __locale_struct libstdc++-v3/config/abi/post/ > x86_64-linux-gnu/baseline_symbols.txt |wc -l > > 72 > > > > the abi on a musl based system is like > > > > $ nm -D /usr/lib/libstdc++.so.6 |grep __locale_struct |wc -l > > 0 > > > > so with your patch if a compiled binary refers to any one > > of those 72 symbols then the dynamic linker will fail to > > load it on a musl based system. > > So would this work? > > struct __generic_locale { > int dummy; > localt_t locale; > }; > > Then allocate these objects with new. That way int* could point to the > object (by pointing to its first member) and the locale_t could be > obtained. Wasteful and ugly, but valid. > > Any other fix seems to assume int* can represent locale_t; I don't > think that's valid for a "generic" implementation. > > Rich > --94eb2c1234587d867405474f1268 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
worked! =C2=A0http://paste.ubuntu.com/23893379/
-su-4.4# nm -D /usr/lib/libstdc= ++.so.6 |grep __locale_struct |wc -l
0
anything i missed? it = it acceptable ? and how could i post this to the upstream?
<= /div>

2017-01-30 0= :49 GMT+08:00 Rich Felker <dalias@libc.org>:
On Sun, Jan 29, 20= 17 at 05:40:08PM +0100, Szabolcs Nagy wrote:
> * He X <xw897002528@gmail.= com> [2017-01-29 22:48:34 +0800]:
> > 2. no other ways, musl will use generic config 100%, and then the=
> > exception, the run time error is hardcoded there; but i doubt if = this
> > really breaks binaries, the function is only called by libstdc++ = itself.
> > you cant only update the config, but does not update libstdc++. l= ibstdc++
> > exported the same abi for common binaries, wont break most dynami= c-loaded
> > binary in my view.
>
> that's not how abi works.. you change the __c_locale typedef
> of the generic config from int* to locale_t, such change
> breaks abi and cannot be upstreamed to gcc. (it's unfortunate
> that the c++ locale handling default for non-gnu systems
> does not use posix locales correctly, but breaking abi
> for all non-gnu systems is not an acceptable fix.)
>
> with your change the abi of libstdc++ would look like
> the current gnu abi:
>
> $ grep __locale_struct libstdc++-v3/config/abi/post/x86_64-linux-= gnu/baseline_symbols.txt |wc -l
> 72
>
> the abi on a musl based system is like
>
> $ nm -D /usr/lib/libstdc++.so.6 |grep __locale_struct |wc -l
> 0
>
> so with your patch if a compiled binary refers to any one
> of those 72 symbols then the dynamic linker will fail to
> load it on a musl based system.

So would this work?

struct __generic_locale {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 int dummy;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 localt_t locale;
};

Then allocate these objects with new. That way int* could point to the
object (by pointing to its first member) and the locale_t could be
obtained. Wasteful and ugly, but valid.

Any other fix seems to assume int* can represent locale_t; I don't
think that's valid for a "generic" implementation.

Rich

--94eb2c1234587d867405474f1268--