From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10670 invoked by alias); 22 Feb 2018 17:15:30 -0000 Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org Received: (qmail 10458 invoked by uid 89); 22 Feb 2018 17:15:15 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM,HK_RANDOM_ENVFROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=no version=3.3.2 spammy=lieu, 20150623, sk:differe, excessively X-HELO: mail-lf0-f46.google.com Received: from mail-lf0-f46.google.com (HELO mail-lf0-f46.google.com) (209.85.215.46) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 22 Feb 2018 17:15:14 +0000 Received: by mail-lf0-f46.google.com with SMTP id f75so3426288lfg.6 for ; Thu, 22 Feb 2018 09:15:06 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Aod06r2GQzoMJ6gm6nQQwvytUF5MjFkO/BIXyqf8oe0=; b=ZcNR534StJFom46i0EDw/BUDsyWyA8F8Emc39QIFIZBurPcwI4R9IZGawySN4gt+K/ jT0qlBD7su5jBBB7m1RJIerGaLdf2GcwWzl95TG66zrJX2TqSbcq/MV+BZ2ltbt3pwya Qb/6z8kZlerS9c8SMGmeupGW3ZYAS4+/fQ9OHT/GJ4inZmjEG1/YL/kJ8yB2o1Kas2n5 yhzsqAf9hrhqzvI69AgVnhuKAW+Dvyw+k95UX1OLP4ky+x1oQ7fOomQ08s+pxmhNxyn/ CMWfNRFOzj6KSYGsPOEYQafcFGDocNvCb+VeAkYv2thYsuZW18gnrPoN8+FxXU/Xurm1 8+Ng== X-Gm-Message-State: APf1xPBt1Hj+o0dz12pe4vL1W5lVUfDJQ9HdxgYYAN5P7CaIykFstDkd GJ0TFsDYGYq102VJywobRqsfs2RMVZSSbH5vvjV1rw== X-Google-Smtp-Source: AG47ELu+0ekBVQ4kxktNJwI+ZY/2q1VDIZIfbAps7yZkkcdfc6W6RklEZM8yW+AO/LBDQuwkolKLcRAFG2fZ5GnRG18= X-Received: by 10.25.218.26 with SMTP id r26mr256532lfg.76.1519319704513; Thu, 22 Feb 2018 09:15:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.46.112.4 with HTTP; Thu, 22 Feb 2018 09:15:03 -0800 (PST) From: Corey Thompson Date: Thu, 22 Feb 2018 20:43:00 -0000 Message-ID: Subject: Simple "INSERT AFTER" linker script results in excessively large binary To: gcc-help@gcc.gnu.org Content-Type: text/plain; charset="UTF-8" X-SW-Source: 2018-02/txt/msg00131.txt.bz2 I'm not sure to which mailing list this question should go, so apologies if I should be addressing the binutils list. I have put together a minimal working example of some behavior in recent gcc/ld versions that I cannot explain. I have a simple linker script for the purpose of locating related data together so that I can iterate it from a function in my program. Strangely, the type or contents of the data seem to have a drastic impact on the output size of the binary executable. First, version info: $ gcc --version; ld --version gcc (Debian 6.3.0-18) 6.3.0 20170516 Copyright (C) 2016 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. GNU ld (GNU Binutils for Debian) 2.28 Copyright (C) 2017 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or (at your option) a later version. This program has absolutely no warranty. My linker script, test.ld: SECTIONS { .rodata.foo : { PROVIDE_HIDDEN(foo_start = .); *(.foo) PROVIDE_HIDDEN(foo_end = .); } } INSERT AFTER .rodata My program source, test.c: #include struct foo { int x, y; }; static const struct foo bar __attribute__ ((section (".foo"))) = { .x = 123, .y = 456, }; extern const struct foo foo_start[], foo_end[]; int main() { printf("%p %p\n", (void *)foo_start, (void *)foo_end); return 0; } I compile it as follows and find a generated a.out that is 8.7KB in size, as I would expect: $ gcc -T test.ld test.c $ ls -lh a.out -rwxr-xr-x 1 corey corey 8.7K Feb 22 11:10 a.out Now I make a small, seemingly benign change to my program - I edit struct foo to include a pointer to some static const int: #include struct foo { int x; const int *y; }; static const int y = 456; static const struct foo bar __attribute__ ((section (".foo"))) = { .x = 123, .y = &y, }; extern const struct foo foo_start[], foo_end[]; int main() { printf("%p %p\n", (void *)foo_start, (void *)foo_end); return 0; } With this new source, I compile and find a generated a.out that is 2.1MB in size!: $ gcc -T test.ld test.c $ ls -lh a.out -rwxr-xr-x 1 corey corey 2.1M Feb 22 11:12 a.out I tried the same test on another machine with the following gcc/ld versions and did not see this problem; both programs resulted in an a.out of ~8.6KB or so: $ gcc --version; ld --version gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-4) Copyright (C) 2015 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. GNU ld version 2.23.52.0.1-55.el7 20130226 Copyright 2013 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or (at your option) a later version. This program has absolutely no warranty. Any thoughts or suggestions? Using the -Wl,-zmax-page-size=0x1000 option seems to reduce the binary size considerably, but given that a differently-versioned toolchain produced expected results, and that the unexpected result is exposed by simply changing the structure to include the address of another symbol, I'm more inclined to suspect that the root cause is either that I've done something wrong or that there's a toolchain bug somewhere, in which case -zmax-page-size would only be a workaround in lieu of a better fix. Thank you, Corey