From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com [IPv6:2a00:1450:4864:20::330]) by sourceware.org (Postfix) with ESMTPS id 288363858400 for ; Sun, 9 Oct 2022 23:46:22 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 288363858400 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=harmstone.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-wm1-x330.google.com with SMTP id bi26-20020a05600c3d9a00b003c1e11f54d2so4354963wmb.2 for ; Sun, 09 Oct 2022 16:46:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :sender:from:to:cc:subject:date:message-id:reply-to; bh=4K1hFrw1K0lWuRA1XN0RqGUMCHTuaonGY943kAwe0Dk=; b=DTlcawtAG6RHksH3vht59HOos+1pjFOEjkzvHMdajs5Q6EfUUyY+xyJ1fla4sDdkm6 GXWvV7XVF2G0KkJanmkfOZk09obc+nl7hm+oyO2NjYEPL9cGyqBh6GOp24Q+oOEp59I4 vsJ5ZxVlc9VRxvME/1+L8+ogZD/SzEUYP2tsJ3Cq7aS3nTa3iUkHjjBhVZKiubcTnM+3 C85JaJUp6Koy/p3y1ywuJBoR6PkivhGmrIV/C/ZBU3Jk6oHtXwtLDh2dve0pZKMRL7LQ mnL8y2ksu4lyTESiAk2nEGmXoU2APyXeuQXkr2nVl5GXWXMjaPtyeZzBV5UBL2tbHV+F mwTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :sender:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=4K1hFrw1K0lWuRA1XN0RqGUMCHTuaonGY943kAwe0Dk=; b=tOiJc0INzKbg1PaFZKIw4rSniTjbV3nRCaGiBGabdHpaC+S9ly7uJcosIKqL/6P05K Nf+Po4sMEfnu8EjC9KX+HyGaU5XxZ86oXCieeD31BaJwRiITumC2LtGsCEImxfvJSVVJ K6PoLXKP4lrDkGbgh11L9PfooFpb9KMJOLLj4n0GVd0yc5sONMHaZ0ZcgUSYAvbO2ia7 VxyhetJbuyeXhUwbA+3DANFW1m8eJGH8GoXFirc/3asyJyArDJAkdAZmJNsrFNmvUwqO tsgVax7pVAuEZz0EIAQ6542ghAa2eG/3nUm12yI3oZKVFkKT6D7uJO2C5BlWko6LeBtr pFxA== X-Gm-Message-State: ACrzQf3sPWBiqwCqwujNdUQvB7loGCIvPwgmU9aFr+Gy3BTaW3HUQ5SH kRXdM67JC59OpWaC+9I9HtOzgzqlnZU= X-Google-Smtp-Source: AMsMyM5U0GB9IiQJOMnWYakrUGmUiqhtJe0FIj+3HR1HESQi4tUZ2LHTe4vlAuvKb0YKmiFETRT/XA== X-Received: by 2002:a05:600c:4856:b0:3b4:9aa3:cb57 with SMTP id j22-20020a05600c485600b003b49aa3cb57mr11188421wmo.116.1665359180530; Sun, 09 Oct 2022 16:46:20 -0700 (PDT) Received: from ?IPV6:2a02:8010:64ea:0:8eb8:7eff:fe53:9d5f? ([2a02:8010:64ea:0:8eb8:7eff:fe53:9d5f]) by smtp.googlemail.com with ESMTPSA id s3-20020adfdb03000000b0022e309d35f8sm7484371wri.12.2022.10.09.16.46.19 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 09 Oct 2022 16:46:19 -0700 (PDT) Sender: Mark Harmstone Message-ID: <2e5696c4-57db-6cd1-603b-e106754b70f5@harmstone.com> Date: Mon, 10 Oct 2022 00:46:09 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.3.2 Subject: Re: [PATCH 1/2] ld: Add --pdb option To: =?UTF-8?Q?Martin_Storsj=c3=b6?= Cc: binutils@sourceware.org References: <20221003014313.28766-1-mark@harmstone.com> <26dfc8b7-e89d-9212-da69-b05044d2d8a9@martin.st> <7e5d88ff-9aa9-dbfd-aa80-1793c2c48fde@martin.st> <2b3caba0-de53-6c2c-1038-5581deb2b8e@martin.st> Content-Language: en-US From: Mark Harmstone In-Reply-To: <2b3caba0-de53-6c2c-1038-5581deb2b8e@martin.st> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-11.7 required=5.0 tests=BAYES_00,BODY_8BITS,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,GIT_PATCH_0,HEADER_FROM_DIFFERENT_DOMAINS,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham 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 7/10/22 13:16, Martin Storsjö wrote: > On Mon, 3 Oct 2022, Martin Storsjö wrote: > >> On Mon, 3 Oct 2022, Mark Harmstone wrote: >> >>> Hi Martin, >>> >>>> As I assume you're aware, lld's mingw port also supports PDB generation - and the description of this option also sounds like it's chosen to match lld's option for outputting PDB files - that's good! >>> >>> Yes, that's right. One notable difference is that the parameter here is optional, unlike with lld, making it a lot easier to fit this into e.g. CMake toolchain files or LDFLAGS. >> >> LLD also has got that behaviour, since https://github.com/llvm/llvm-project/commit/2c52ddf31f5421c5373923535b958b84c79772e3 in 2019. That's in particular why I wanted to make sure that this case works the same in binutils too. >> >>> It looks like the equals sign is mandatory when providing optional parameters, otherwise it interprets the filename as another parameter. >> >> Yep, that's the case in LLD too. >> >> Unfortunately I didn't think of this behaviour initially when I first added this option - otherwise we could have had e.g. --pdb as a boolean option to just output to the default name, and e.g. --output-pdb= if you wanted to specify the name. But oh well, "-pdb=" works, and I guess it isn't the worst thing in the world. >> >>> But it does mean that the form "-pdb=out.pdb" will work on both ld and lld, which I think is the most important thing. >> >> TBH, I consider the "-pdb=" case equally important too - that's what most people would use in the end. > > FWIW, I'm actually a bit concerned about the interop between binutils and lld here. I don't want interop between binutils and lld to work only for some subset of the used parameter forms, I'd like it to work for all commonly used forms. > > > First off, the (slightly awkward) syntax that lld uses for an optional empty output name, "-pdb=" really should be handled by binutils too - handling that doesn't conflict with anything else and should be simple to support. > > This is the format of the option that I've been recommending people to use, and this has been in use in third party projects for years already - e.g. this: https://code.videolan.org/videolan/vlc/-/blob/master/configure.ac#L429 > > This should be trivial to support in your patch: > > diff --git a/ld/emultempl/pep.em b/ld/emultempl/pep.em > index 11216830dd3..538fdf5054b 100644 > --- a/ld/emultempl/pep.em > +++ b/ld/emultempl/pep.em > @@ -926,7 +926,7 @@ gld${EMULATION_NAME}_handle_option (int optc) >        if (emit_build_id == NULL) >         emit_build_id = xstrdup (DEFAULT_BUILD_ID_STYLE); >        pdb = 1; > -      if (optarg) > +      if (optarg && optarg[0]) >         pdb_name = xstrdup (optarg); >        break; >      } > > (And the same for pe.em.) > > > Secondly, for explicitly naming an output file, I've documented to end users that they can use either -Wl,-pdb= or -Wl,-pdb, - see https://github.com/mstorsjo/llvm-mingw/blob/master/README.md?plain=1#L175. > > In the original implementation in the mingw frontend in lld in 2018, the "-pdb " format was the only format for the option: https://github.com/llvm/llvm-project/commit/b7d50115ba4900da6db7afb6460ad42ff19ba6a2 > > Only one year later with the implicit output name, the "-pdb=" and "-pdb=" form was added: https://github.com/llvm/llvm-project/commit/2c52ddf31f5421c5373923535b958b84c79772e3 > > In one of my test scripts, I use the initial form of the option, -Wl,-pdb,: > https://github.com/mstorsjo/llvm-mingw/blob/master/run-tests.sh#L234 > > It seems like Wine has picked up on the -Wl,-pdb, form: > https://gitlab.winehq.org/wine/wine/-/blob/wine-7.18/tools/winegcc/winegcc.c#L467 > > Also here are a couple of other cases I found that all seem to use that form: > https://youtrack.jetbrains.com/issue/KT-47175/How-to-generate-kotlin-native-debug-info-filesPDB-on-windows-platform > https://git.kernel.dk/?p=fio.git;a=commitdiff;h=76bc30ca118fda404f19c17d97bafdba9779c4c2 > > So with all these users, I'd be kinda hesitant to change lld's interpretation of this option form, and to have binutils ld in parallel interpreting that form differently. What do you think? > > > // Martin Hi Martin, Fair enough - I'm not overly wedded to this, and will change it if, as you say, it'll cause issues elsewhere. Mark