From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28568 invoked by alias); 26 Sep 2004 20:54:55 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 28551 invoked from network); 26 Sep 2004 20:54:52 -0000 Received: from unknown (HELO walton.sibelius.xs4all.nl) (82.92.89.47) by sourceware.org with SMTP; 26 Sep 2004 20:54:52 -0000 Received: from elgar.sibelius.xs4all.nl (elgar.sibelius.xs4all.nl [192.168.0.2]) by walton.sibelius.xs4all.nl (8.13.0/8.13.0) with ESMTP id i8QKspb7005573 for ; Sun, 26 Sep 2004 22:54:51 +0200 (CEST) Received: from elgar.sibelius.xs4all.nl (localhost [127.0.0.1]) by elgar.sibelius.xs4all.nl (8.12.6p3/8.12.6) with ESMTP id i8QKslAH009266 for ; Sun, 26 Sep 2004 22:54:47 +0200 (CEST) (envelope-from kettenis@elgar.sibelius.xs4all.nl) Received: (from kettenis@localhost) by elgar.sibelius.xs4all.nl (8.12.6p3/8.12.6/Submit) id i8QKslJa009263; Sun, 26 Sep 2004 22:54:47 +0200 (CEST) Date: Sun, 26 Sep 2004 20:54:00 -0000 Message-Id: <200409262054.i8QKslJa009263@elgar.sibelius.xs4all.nl> From: Mark Kettenis To: gdb@sources.redhat.com Subject: [RFC] Clear SEC_HAS_CONTENTS for read-only sections in gcore files? X-SW-Source: 2004-09/txt/msg00234.txt.bz2 The discussion starting with: http://sources.redhat.com/ml/gdb/2004-09/msg00202.html raised the question why we're clearing SEC_LOAD, but don't clear SEC_HAS_CONTENTS when generating a core file with the gcore command. This results in core files with zero-filled read-only sections that just waste space on disk. I tried the attached patch and it seems to work fine on i386-unknown-freebsd4.7; no regressions in the testsuite. Here is some readelf output on the resulting core file: There are 22 section headers, starting at offset 0xc748c: Section Headers: [Nr] Name Type Addr Off Size ES Flg Lk Inf Al [ 0] NULL 00000000 000000 000000 00 0 0 0 [ 1] note0 PROGBITS 00000000 0002b4 0001c0 00 A 0 0 1 [ 2] load NOBITS 08048000 000474 1c3000 00 AX 0 0 1 [ 3] load PROGBITS 0820b000 000474 00c000 00 WA 0 0 1 [ 4] load PROGBITS 08217000 00c474 01a000 00 WA 0 0 1 [ 5] load PROGBITS 08231000 026474 04d000 00 WAX 0 0 1 [ 6] load NOBITS 2820b000 073474 012000 00 AX 0 0 1 [ 7] load PROGBITS 2821d000 073474 001000 00 WA 0 0 1 [ 8] load PROGBITS 2821e000 074474 002000 00 WA 0 0 1 [ 9] load PROGBITS 28220000 076474 008000 00 WAX 0 0 1 [10] load NOBITS 28228000 07e474 035000 00 AX 0 0 1 [11] load PROGBITS 2825d000 07e474 009000 00 WAX 0 0 1 [12] load PROGBITS 28266000 087474 003000 00 WAX 0 0 1 [13] load NOBITS 28269000 08a474 017000 00 AX 0 0 1 [14] load PROGBITS 28280000 08a474 004000 00 WAX 0 0 1 [15] load NOBITS 28284000 08e474 005000 00 AX 0 0 1 [16] load PROGBITS 28289000 08e474 001000 00 WAX 0 0 1 [17] load NOBITS 2828a000 08f474 081000 00 AX 0 0 1 [18] load PROGBITS 2830b000 08f474 005000 00 WAX 0 0 1 [19] load PROGBITS 28310000 094474 013000 00 WAX 0 0 1 [20] load PROGBITS bfbe0000 0a7474 020000 00 WAX 0 0 1 [21] .shstrtab STRTAB 00000000 0c7474 000016 00 0 0 1 Key to Flags: W (write), A (alloc), X (execute), M (merge), S (strings) I (info), L (link order), G (group), x (unknown) O (extra OS processing required) o (OS specific), p (processor specific) What do people think about this change? Mark Index: gcore.c =================================================================== RCS file: /cvs/src/src/gdb/gcore.c,v retrieving revision 1.15 diff -u -p -r1.15 gcore.c --- gcore.c 15 Jun 2004 01:04:19 -0000 1.15 +++ gcore.c 26 Sep 2004 20:45:53 -0000 @@ -354,7 +354,7 @@ gcore_create_callback (CORE_ADDR vaddr, || (start >= vaddr && end <= vaddr + size)) && !(bfd_get_file_flags (abfd) & BFD_IN_MEMORY)) { - flags &= ~SEC_LOAD; + flags &= ~(SEC_LOAD | SEC_HAS_CONTENTS); goto keep; /* break out of two nested for loops */ } }