From owner-freebsd-toolchain@freebsd.org Thu Mar 30 19:29:46 2017 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F1477D26852 for ; Thu, 30 Mar 2017 19:29:46 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B9CD37BA; Thu, 30 Mar 2017 19:29:46 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-it0-x234.google.com with SMTP id e75so339945itd.1; Thu, 30 Mar 2017 12:29:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=EsjwmqntLtnl3ZKKVUK/ZeKbp9C5ZBt52cI1w6wCxPo=; b=Zy4gGzHDpAVqDRwNrFKEPt4ytjFJ8364UaOuo2ZFe5grgZ8gj3Z6altK7rH9DRK1rq 74KnU3zN+HDZkfo1iSuLdlnl4XkC5l0SeBMxwOwmjodTq+KnTpxtG4XDw7fUJd24Wj1S W7Ruhe4oL3JmdsR/JHv+AM+K5Th1Il3ZH8zPP1KT8BIxfR6DPaWRMUNrX2677e+gc+ZE 9QFNO51kgwRUNo9JU6vlMgFgrUBemDfwxWgN5jg6dxL0rlgywsXW80HqyvjUf4tJ9WeK 79qz5PYDVtg9vvJxonh7gv35giP3UDXPwYzQb2l44Lges6DCXQoWgZuKQFnQAq4qr5F7 M9zg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-transfer-encoding; bh=EsjwmqntLtnl3ZKKVUK/ZeKbp9C5ZBt52cI1w6wCxPo=; b=dnL28zjOzNVZJNjiQdIwPBwCwPrs/seAlvgKA0PWERXSKEvvtpBJLgxRw0u9Ou3FXS FmJXMikjMj/pMJF+Cixa3d4h9/syMQp8flwIpJadyf3pFJYRwkCTAzbxkkdMbGMcxp9G 5A2HZ9a89+K0PP3y6PmTCPcwJ9plYDMhJkiGftN3T73bnkQfYHKaFlhLPpUq64Mx+SDR puEdjSUEYQ2k4r8cgDXCcn+LZniHmXrZdjRhYaNU/9Dj7OT+zTSzs3v0U+qPcTzqsVpO yiBgK6+ahA9F9RFQteqC/vnAMUxECAmYVlS6/G0Q35Ejaq0WRccj2BDSHZed79llr2IR 6lFg== X-Gm-Message-State: AFeK/H0d1UaNxt+CK6wJkGfXitXyFDcWmHVBOnVUAX21YidhDi7Yvqxst1y7N/+pSNYYQAkBRGoT34SRaX9EbA== X-Received: by 10.36.125.143 with SMTP id b137mr2547059itc.4.1490902186027; Thu, 30 Mar 2017 12:29:46 -0700 (PDT) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 10.107.30.209 with HTTP; Thu, 30 Mar 2017 12:29:25 -0700 (PDT) In-Reply-To: <20170324122129.GA24947@bali> References: <1612271904400.79526@mx5.roble.com> <20170324122129.GA24947@bali> From: Ed Maste Date: Thu, 30 Mar 2017 15:29:25 -0400 X-Google-Sender-Auth: u8yVtRh30tN0eNDoLny0O9R6Tak Message-ID: Subject: Re: /tmp/ecp.* created during kernel build? To: Andre Albsmeier Cc: Dimitry Andric , "freebsd-toolchain@freebsd.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Mar 2017 19:29:47 -0000 [redirected to freebsd-toolchain] On 24 March 2017 at 08:21, Andre Albsmeier wr= ote: > > Interesting is also that libc.a grows(!): > > Before the strip: > -r--r----- 1 andre wheel 2622684 24 Mar 13:18 libc.a > > After: > -r--r----- 1 andre wheel 2713792 24 Mar 13:19 libc.a It seems this is a side effect of the way elfcopy writes the new archive and objects. Using diffoscope to compare libc.a and a stripped libc.a we see a few interesting things: % objcopy --strip-debug /usr/lib/libc.a libc.strip1.a % diffoscope /usr/lib/libc.a libc.strip1.a --- /usr/lib/libc.a +++ libc.strip1.a =E2=94=9C=E2=94=80=E2=94=80 file list =E2=94=82 @@ -1,1258 +1,1258 @@ =E2=94=82 ----------- 0 0 0 83210 1970-01-01 00:00:00.00= 0000 / =E2=94=82 +---------- 0 0 0 83210 2017-03-30 19:01:14.00= 0000 / * Elfcopy is updating the timestamp on the "/" entry, despite leaving all other archive metadata alone. =E2=94=82 --rw-r--r-- 0 0 0 1104 1970-01-01 00:00:00.000000 iconvlist.o =E2=94=82 +-rw-r--r-- 0 0 0 1184 1970-01-01 00:00:00.000000 iconvlist.o * As you discovered output is larger, and this is true for the individual .o files in the .a archive. =E2=94=82 File: lib.a(iconvctl.o) =E2=94=82 ELF Header: =E2=94=82 Magic: 7f 45 4c 46 02 01 01 09 00 00 00 00 00 00 00 00 =E2=94=82 Class: ELF64 =E2=94=82 Data: 2's complement, little endi= an =E2=94=82 Version: 1 (current) =E2=94=82 OS/ABI: FreeBSD =E2=94=82 ABI Version: 0 =E2=94=82 Type: REL (Relocatable file) =E2=94=82 Machine: Advanced Micro Devices x86-= 64 =E2=94=82 Version: 0x1 =E2=94=82 Entry point address: 0 =E2=94=82 Start of program headers: 0 (bytes into file) =E2=94=82 - Start of section headers: 528 (bytes into file) =E2=94=82 + Start of section headers: 536 (bytes into file) =E2=94=82 Flags: 0 =E2=94=82 Size of this header: 64 (bytes) =E2=94=82 Size of program headers: 0 (bytes) =E2=94=82 Number of program headers: 0 =E2=94=82 Size of section headers: 64 (bytes) =E2=94=82 - Number of section headers: 9 =E2=94=82 - Section header string table index: 1 =E2=94=82 + Number of section headers: 10 =E2=94=82 + Section header string table index: 9 Section headers are at a different offset, elfcopy/strip output has an extra section. =E2=94=9C=E2=94=80=E2=94=80 readelf --wide --sections {} =E2=94=82 @@ -1,23384 +1,24634 @@ =E2=94=82 =E2=94=82 File: lib.a(iconvlist.o) =E2=94=82 -There are 9 section headers, starting at offset 0x210: =E2=94=82 +There are 10 section headers, starting at offset 0x220: =E2=94=82 =E2=94=82 Section Headers: =E2=94=82 [Nr] Name Type Addr Off Size ES Flg Lk Inf Al =E2=94=82 [ 0] NULL 0000000000000000 000000 000000 00 0 0 0 =E2=94=82 - [ 1] .strtab STRTAB 0000000000000000 000180 00008c 00 0 0 1 =E2=94=82 - [ 2] .text PROGBITS 0000000000000000 000040 00000a 00 AX 0 0 16 =E2=94=82 - [ 3] .rela.text RELA 0000000000000000 000150 000018 18 8 2 8 =E2=94=82 - [ 4] .comment PROGBITS 0000000000000000 00004a 000053 01 MS 0 0 1 =E2=94=82 - [ 5] .note.GNU-stack PROGBITS 0000000000000000 00009d 000000 00 0 0 1 =E2=94=82 - [ 6] .eh_frame X86_64_UNWIND 0000000000000000 0000a0 000038 00 A 0 0 8 =E2=94=82 - [ 7] .rela.eh_frame RELA 0000000000000000 000168 000018 18 8 6 8 =E2=94=82 - [ 8] .symtab SYMTAB 0000000000000000 0000d8 000078 18 1 3 8 =E2=94=82 + [ 1] .text PROGBITS 0000000000000000 000040 00000a 00 AX 0 0 16 =E2=94=82 + [ 2] .rela.text RELA 0000000000000000 000180 000018 18 I 7 1 8 =E2=94=82 + [ 3] .comment PROGBITS 0000000000000000 00004a 000053 01 MS 0 0 1 =E2=94=82 + [ 4] .note.GNU-stack PROGBITS 0000000000000000 00009d 000000 00 0 0 1 =E2=94=82 + [ 5] .eh_frame X86_64_UNWIND 0000000000000000 0000a0 000038 00 A 0 0 8 =E2=94=82 + [ 6] .rela.eh_frame RELA 0000000000000000 000198 000018 18 I 7 5 8 =E2=94=82 + [ 7] .symtab SYMTAB 0000000000000000 0000d8 0000a8 18 8 5 8 =E2=94=82 + [ 8] .strtab STRTAB 0000000000000000 0001b0 00001b 00 0 0 1 =E2=94=82 + [ 9] .shstrtab STRTAB 0000000000000000 0001cb 00004e 00 0 0 1 =E2=94=82 Key to Flags: =E2=94=82 W (write), A (alloc), X (execute), M (merge), S (strings) =E2=94=82 I (info), L (link order), G (group), x (unknown) =E2=94=82 O (extra OS processing required) o (OS specific), p (processor= specific) Sections are in a different order, and elfcopy/strip includes a separate section header string table, while Clang's output stores both symbol names and names used in the section header in .strtab. The increased size is interesting and somewhat unfortunate, but not necessarily a bug. > strip (objcopy) does more curious things: > > $ cd /tmp > $ cp /usr/lib/libc.a . > $ strip --strip-debug libc.a > $ strip --strip-debug libc.a > > [1] 960 segmentation fault strip --strip-debug libc.a This is also reproducible as: % objcopy --strip-debug /usr/lib/libc.a libc.1.a % objcopy --strip-debug libc.1.a libc.2.a zsh: bus error (core dumped) objcopy --strip-debug libc.1.a libc.2.a It wasn't reproducible in some trivial cases I tried though (e.g. .a archive with two trivial .o objects), or with some other .a archives: % objcopy --strip-debug /usr/lib/libm.a libm.1.a % objcopy --strip-debug libm.1.a libm.2.a % I've submitted ELF Tool Chain ticket #548 for this issue https://sourceforge.net/p/elftoolchain/tickets/548/