From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from nikam.ms.mff.cuni.cz (nikam.ms.mff.cuni.cz [195.113.20.16]) by sourceware.org (Postfix) with ESMTPS id 2718E3858CDB for ; Fri, 1 Dec 2023 12:03:03 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 2718E3858CDB Authentication-Results: sourceware.org; dmarc=fail (p=none dis=none) header.from=ucw.cz Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=kam.mff.cuni.cz ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 2718E3858CDB Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=195.113.20.16 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1701432185; cv=none; b=wsxImDEBAQgHAIilZnO69yIu7spOBKnW+k+qTshAeaNmYYwL3TY6TkIJLVsrL6SmHj68xmQgJw54cTwLzhcCwEyIBgvWrQ7S2eXV9tqKsy4rPTD5wLrf1RSB0oNefZPz8ydEDETR2fT6f8+RxdqpT6evj9n2LQ3YiQtVJfqxjcg= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1701432185; c=relaxed/simple; bh=4MbQ5mk0lSNgUen8unmUzkl1kDgyKV2wFYM32onizos=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=HKC0etyqZc0F8FGevTwQmMUHHvcf5GUcaCwKldTOC59qKXwWnE99gftbT/ywUKuTFokMt80V+jyr0BXaUlJgWy5KJY7J+skFObw2N9pwrQXRt28Kr79j9Ak+hOmRUS+l+gFeDeO+99hNObXqMAWnDjMus1by+N8O/1LrwHzeoKk= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by nikam.ms.mff.cuni.cz (Postfix, from userid 16202) id A731028BD8A; Fri, 1 Dec 2023 13:03:01 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ucw.cz; s=gen1; t=1701432181; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=KLGt0teNJDBK4sYvNkRmUBhztEAYJKuHgHpKihFWl3U=; b=rNrf7sYU26QP07tsK1N92N7W+QgCy0KXv7UaYWysTSQ0I16dGOQPDiti+P0I6RyEGYtog9 qP5GsXDph3KqJimNwmz7rQ2ySAI8r+wwH0bQE6JjRvgtNw4oFbV8bNPpztVFHSHD7ewest 3HrLuGaVDrmAnhe39c8+7A/TwGzX320= Date: Fri, 1 Dec 2023 13:03:01 +0100 From: Jan Hubicka To: Andreas Schwab Cc: Richard Biener via Gcc , Florian Weimer , Richard Biener , Jonathan Yong <10walls@gmail.com>, Nathan Sidwell Subject: Re: libgcov, fork, and mingw (and other targets without the full POSIX set) Message-ID: References: <878r6es634.fsf@oldenburg.str.redhat.com> <8734wms3ks.fsf@oldenburg.str.redhat.com> <87il5idwr3.fsf@igel.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87il5idwr3.fsf@igel.home> X-Spam-Status: No, score=-4.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,JMQ_SPF_NEUTRAL,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: > On Dez 01 2023, Richard Biener via Gcc wrote: > > > Hmm, so why's it then referenced and not "GCed"? > > This has nothing to do with garbage collection. It's just the way > libgcc avoids having too many source files. It would be exactly the > same if every function were in its own file. THe ifdef machinery makes every function to go insto its own .o file which are then archived. So if user code never calls to fork, the .o file with fork wrapper should not be picked by linker and we should not have link error. If user code calls fork, then the .o file with wrapper should be picked and we will get linker error on missing fork. So I think it ought to work as it is now. Does mingw linker behave somehow differently with archives? Or is there problem with a libgcov being DLL or something? Honza > > -- > Andreas Schwab, schwab@linux-m68k.org > GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 > "And now for something completely different."