X-Authentication-Warning:	delorie.com: mail set sender to djgpp-bounces using -f
X-Recipient:	djgpp AT delorie DOT com
X-Original-DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=gmail.com; s=20210112;
	h=message-id:date:mime-version:user-agent:subject:content-language:to
	:references:from:in-reply-to:content-transfer-encoding;
	bh=zgzG+S9wg8YQbw5ImM7ElVZAbd80UCBAmtl5NHw42a8=;
	b=dHeMltAYCsFDwfrjHIfv5rQcKN5X/G8xmM2WoXGdl93wLyTt+s/agl51PvRU1AqkYu
	aswY/ubh+Lo6FYXlS8rXqdhNVVYMbVHTJq1AOB4gw4WuA/qyqpszIpG9YQOOQWHn/WBr
	Akvyb06ADBpECEQz70l151MX1k03iIeR0Qe6nvK5HlXjw5hNSWFz6CecCnQYtSOhIIZN
	34QUg7CcnZnNR0s7ub1ILK+w+UCKNUC7mWrcWUibvPfBoFy/BJ3GlMwgjbeXpIGqOWOK
	y51u2NLP4k3hbQeGmHwTLUF/lZr0kloKjbz7JbQXRccSvRrSvsBK8LVDAXaMmNNh5AuK
	2AVg==
X-Google-DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20210112;
	h=x-gm-message-state:message-id:date:mime-version:user-agent:subject
	:content-language:to:references:from:in-reply-to
	:content-transfer-encoding;
	bh=zgzG+S9wg8YQbw5ImM7ElVZAbd80UCBAmtl5NHw42a8=;
	b=1FHF7uBOpUV6EjasP2Gt+MUkHmDGH6elhc+1Ri3D2yOfnIrbWK+Yl8FkkMvzdg5zmm
	iixH73OwndjUKOxaOHRe+7SGPgpiqsmyonuVUmSobEz3L0Cm9hiUzBWfqeZoWVhI6MxV
	HvuHKKzyE5NFPQf4bC1FawjMygcf2BHdktCK7BGT1Qx35e+2mOfrCUeQLsmvNYK22lsV
	Jwh/QoodeTAcU7lfflHk9G3OgsD+sFesXXRfqXsNwYruzas94lyBld9uInyGzmcghyoI
	FXkxaZ9JBFilRkZn+9Vsey35ItTSTAA6cTf3dQawkDrxQjT5Iv0xq/RlxWdtWWWatW8p
	TGTg==
X-Gm-Message-State:	AOAM532OsttwIWcBYeYYsRC5TISx9WXUf3RUkDvROOT5C213/csn0y4K
	u1cSCRQ3viaJVUAJDqd4VOLjuNXcVV8=
X-Google-Smtp-Source:	ABdhPJwaLrpU1fW43OK2pKWHH8q4NqPPp76kLdWCWVNnz/nQpdId0ivNE6zolDs4h1IWmpSycnPX3w==
X-Received:	by 2002:a05:6402:1007:b0:428:beb6:f483 with SMTP id c7-20020a056402100700b00428beb6f483mr36185041edu.391.1653506230703;
	Wed, 25 May 2022 12:17:10 -0700 (PDT)
Message-ID:	<13904ce4-1b5c-c82f-7939-d0cc40c61d3b@gmail.com>
Date:	Wed, 25 May 2022 21:17:10 +0200
MIME-Version:	1.0
User-Agent:	Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:91.0) Gecko/20100101
	Thunderbird/91.9.1
Subject:	Re: GNU pth during djgpp build time?
To:	djgpp AT delorie DOT com
References:	<a52c077b-55b2-4a1f-877e-ebdcef7c1e01n AT googlegroups DOT com>
	<224eb9dc-337e-f78f-ea4e-58bb15eb580b AT gmail DOT com>
	<7466fdea-7958-467e-aa06-f051df1bf3fen AT googlegroups DOT com>
From:	"J.W. Jagersma (jwjagersma AT gmail DOT com) [via djgpp AT delorie DOT com]" <djgpp AT delorie DOT com>
In-Reply-To:	<7466fdea-7958-467e-aa06-f051df1bf3fen@googlegroups.com>
Reply-To:	djgpp AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	djgpp AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

On 2022-05-25 19:53, janezz55 (janezz55 AT gmail DOT com) [via djgpp AT delorie DOT com] wrote:
>> Surprisingly, configuring gcc with --enable-threads is actually possible, but 
>> it did require a small patch to Pth. The executables it produces however, will 
>> not run. A thread-aware libgcc will try to lock a mutex in 
>> __register_frame_info(), which is invoked from crt0 before __crt1_startup(). 
>> But locking a mutex involves a whole series of libc functions that rely on 
>> things like _dos_ds, which are only initialized from __crt1_startup(). 
> 
> patch libgcc? Why would it want to lock a mutex anyway?

As I understand it, __register_frame_info() is called to register .eh_frame
sections in a global list.  This also happens on shared library loads, at which
point there may be multiple active threads.  The same list is also accessed
whenever an exception is thrown.  So it makes sense to use a mutex here, but
in our case it's just not necessary to do so on startup.

- Raw text -