From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <libc-help-return-4440-listarch-libc-help=sourceware.org@sourceware.org>
Received: (qmail 25434 invoked by alias); 24 Jan 2018 17:47:03 -0000
Mailing-List: contact libc-help-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Subscribe: <mailto:libc-help-subscribe@sourceware.org>
List-Post: <mailto:libc-help@sourceware.org>
List-Help: <mailto:libc-help-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: libc-help-owner@sourceware.org
Received: (qmail 25362 invoked by uid 89); 24 Jan 2018 17:47:03 -0000
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 spammy=
X-HELO: bhuna.collabora.co.uk
Received: from bhuna.collabora.co.uk (HELO bhuna.collabora.co.uk) (46.235.227.227) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 24 Jan 2018 17:47:01 +0000
Received: from collabora.com (unknown [IPv6:2a00:5f00:102:0:2430:b45c:e00d:8497])	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))	(No client certificate requested)	(Authenticated sender: vivek)	by bhuna.collabora.co.uk (Postfix) with ESMTPSA id 018F4270D05;	Wed, 24 Jan 2018 17:46:59 +0000 (GMT)
Date: Wed, 24 Jan 2018 17:47:00 -0000
From: =?UTF-8?Q?Vivek_Das=C2=A0Mohapatra?= <vivek@collabora.com>
To: Adhemerval Zanella <adhemerval.zanella@linaro.org>
cc: libc-help@sourceware.org
Subject: Re: A possible libc/dlmopen/pthreads bug
In-Reply-To: <9ff5882f-879f-3069-1ea0-268e2c5e6ac0@linaro.org>
Message-ID: <alpine.DEB.2.20.1801241742170.22921@noise.cbg.collabora.co.uk>
References: <alpine.DEB.2.20.1801241345460.22921@noise.cbg.collabora.co.uk> <41b64265-397f-1ead-dd79-50052b2d19af@arm.com> <9ff5882f-879f-3069-1ea0-268e2c5e6ac0@linaro.org>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
X-IsSubscribed: yes
X-SW-Source: 2018-01/txt/msg00014.txt.bz2

> In fact I think Vivek examples of running process with two different libcs
> are working mainly because the different glibc define and access the shared
> resources in same manner.  I bet it will break the moment we change some
> state internal layout or semantic (for instance the __stack_user struct size).

A slight correction - we are deliberately using the _same_ libc to
avoid exactly that problem - it's that dlmopen as currently implemented
creates a new mapping of the same libc for the dlmopen namespace.

I also don't need (or expect) complete isolation of the libc cluster:
If I could, I would share the same mapping of libc & co with the main
link map.