From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ot1-x32b.google.com (mail-ot1-x32b.google.com [IPv6:2607:f8b0:4864:20::32b]) by sourceware.org (Postfix) with ESMTPS id E0D8D3858D34 for ; Wed, 21 Feb 2024 18:02:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org E0D8D3858D34 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=tramnitz.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=tramnitz.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org E0D8D3858D34 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::32b ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1708538555; cv=none; b=Yn79nwJcLLAu2tfEIduqJthXyhFJOFWJ4nhQN98TgnISEIyeyJ2vi4RJOHwhyiPKg1/AzCyVePDzqnsJiMP7EiVl6X84nXIQGTOACtU+S3sjAXjBhExMYPlVhK7nXLg7aYTBl5Kf3MKm6pOHqqveW3dr61n+EQFlMyCPv2viiJ0= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1708538555; c=relaxed/simple; bh=kp5eRNYPTAuR0QAiSEeDAu5bF8wBt4hN9S4j9tW+wMw=; h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; b=kT90jK3SWNDt32VxyCCpeQ3fcGraKY8Uq2oIWka/TRuJmMha6MYcvF0QEF7TqhRptuAEsjtMb/GFOaP8+aiBMNmlF3czR/pLmewU5+Pj04e28CdCJS6BRP6DS5sbZg4fUolAd8p+ApxRnZRk9LzfBxDswOzWF9s0N0zdyTCX0lw= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-ot1-x32b.google.com with SMTP id 46e09a7af769-6e0f43074edso560660a34.1 for ; Wed, 21 Feb 2024 10:02:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tramnitz-com.20230601.gappssmtp.com; s=20230601; t=1708538553; x=1709143353; darn=sourceware.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=kp5eRNYPTAuR0QAiSEeDAu5bF8wBt4hN9S4j9tW+wMw=; b=lIQRq/Cbj1SbXfNM+cd4CgiWu8rNdtRqz4JxM+tM7sY7G4NfAuVezijXsIg9orxFZt FF7qCWMSgBiecH0k+9OYYRQKqseShTairsCj50xrb3IAXobq9bC+TCKnb4YrbMHlYH6H QRiyUI0LoMKiQGWyhyyBEZinpTgOdmynZK0rQ2fNFe05mh51HGuqXe5tUwayVHwzOVwH eCkIGrCv5j4EHtGlMLlgkwmv0NBl/MtdlglogT30WRB8sCL2u56rF0kR9nbnl7WkLPrn F5NxyzLm9UzV4KsDxPzBjYu7ItXvRODKRRxC1+iiUEsSd2WyG4kW50ASo32pc7/Jz9QK kaLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708538553; x=1709143353; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=kp5eRNYPTAuR0QAiSEeDAu5bF8wBt4hN9S4j9tW+wMw=; b=GNqJXuV3x8RZceylQRwoihyhPccWgxrBg/SDFgGodK+F41bAmCBbJY+OgMvcl3EAK/ jHiH/z+HtJ9yvQVdnVOzbpYElpch2zkSTs5teS2wlVzJJDRktlPgcjixWhT/WxWX/sWt AFH0lwd06y2emKSkq023xq9YPEPwFDo5sJOZv4WPDmN5f97wOu/L8wFBMYBFhj69G7hs cyFwBjFZ12Mi9ZlwWOWd1emE2hMCTGdzOVFYCc3eNX1VG48ABQ9jEGbllAlnLX1csUat Wa+dtd7yeNbpHCrtPP0JF58XWYS2ek2JpFQ5922B5FkOko8cZwx/MqIV+zmn5n/oNdA6 aqzQ== X-Gm-Message-State: AOJu0Yxr+nhhA+61HZPvCXhtzS//wkxZCHZdxL/RWF9Ihw9XnDQ7rGhl JgvRAOxMabN0fkSU+hISphTDVN5S3s86i0Xfuh4ktUwhalOUhPPNwyJjTJljArGjnCNLrEYTAVF wB3ycWLjOgFUyqSkdxysYYfKaoRuGUqatagOXJy/OsrEK9S3No/E= X-Google-Smtp-Source: AGHT+IGbxDFJ/QNQwCNWt+GDzBzKlT2lDc8/rr3WRf5OqqSfGEaapI3MM7O7Ua3RP7eldRemYvnZn20UO7Mo/n9L6P4= X-Received: by 2002:a9d:4b17:0:b0:6e1:d90:c429 with SMTP id q23-20020a9d4b17000000b006e10d90c429mr16703712otf.7.1708538553082; Wed, 21 Feb 2024 10:02:33 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Christian Tramnitz Date: Wed, 21 Feb 2024 19:01:55 +0100 Message-ID: Subject: ld: document static libraries when performing static linking To: binutils@sourceware.org Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE 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: Hello, For statically linked binaries one wants to keep track of external libraries that were pulled in at link time. I haven't found any initiatives or standards trying to achieve this yet, so I would like to make a proposal. ld already supports the `--depedency-file=` option to create a depfile, to some degree, documenting dependencies in Makefile format. While it's a good starting point, it's not sufficient. Would it be feasible to create another option, that a) just records dependencies to external, static-libs (within the depfile this could be achieved by looking for path names outside the build dir and having an .a file extension - but this is not neccessarily exhaustive). This doesn't need to be unique, post-processing is expected to take place anyway. b) documents the actual objects (enhanced: down to function level if information exists from compiling with -ffunction-sections and -fdata-sections) that were pulled in from the library archive, similar to the output from `--verbose` "(/usr/lib/gcc/x86_64-pc-linux -gnu/13/../../../../lib64/libc.a)stpcpy-avx2.o" c) outputs this in some sort of structured format for later processing, e.g. as simple as ,, my-obj,/usr/lib64/libc.a,stpcpy-avx2.o my-obj,/usr/lib64/libc.a,stpcpy-avx2-rtm.o my-obj,/usr/lib64/libc.a,getsrvbynm.o my-obj,/usr/lib64/libc.a,stpcpy-evex.o d) - if ld doesn't support this already (couldn't find looking through man) - ld had some sort of no-op/pretend option that doesn't actually produce a linked output but only pretends it would? Purpose: The consumer of this information might be a distributor, keeping track of things in the distribution specific packaging database format. Or it could even be embedded into the resulting binary itself. Background: This output can be used to I) validate license compliance (it would make it possible to discover conflicting licenses of derived work) II) allow vulnerability tracking, when vulnerabilities existed in included static libraries (at build/link time) The latter would be further supported by b) as a vulnerability may not even exist in the resulting object if the vulnerable function wasn't included by linking. Best regards, Christian