From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 738 invoked by alias); 13 Mar 2014 10:07:20 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 604 invoked by uid 89); 13 Mar 2014 10:07:18 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-Spam-User: qpsmtpd, 2 recipients X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 13 Mar 2014 10:07:17 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s2DA7Dvm012867 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 13 Mar 2014 06:07:13 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s2DA7Ajc015461; Thu, 13 Mar 2014 06:07:11 -0400 Message-ID: <5321834E.9000509@redhat.com> Date: Thu, 13 Mar 2014 10:07:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: "Metzger, Markus T" CC: Alan Modra , Cary Coutant , Doug Evans , "gdb@sourceware.org" , "binutils@sourceware.org" Subject: Re: vdso handling References: <20140312071701.GW26922@bubble.grove.modra.org> <20140313010147.GZ26922@bubble.grove.modra.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2014-03/txt/msg00030.txt.bz2 On 03/13/2014 08:23 AM, Metzger, Markus T wrote: >> -----Original Message----- >> From: Alan Modra [mailto:amodra@gmail.com] >> Sent: Thursday, March 13, 2014 2:02 AM >> To: Cary Coutant >> Cc: Doug Evans; Metzger, Markus T; gdb@sourceware.org; >> binutils@sourceware.org >> Subject: Re: vdso handling >> >> On Wed, Mar 12, 2014 at 01:22:58PM -0700, Cary Coutant wrote: >>>> I think a case can be made that gdb should be able to use the >>>> "execution view" of the program here. >>>> As for how to achieve that ... "Discuss." :-) >>> >>> Add a PT_DEBUG program header entry? The PT_DEBUG segment would >> need >>> to have a small header that allows the debugger to find .debug_abbrev, >>> .debug_info, etc. (i.e., a mini section table). Or, just add >>> individual program header entries for each of the standard debug >>> sections: PT_DEBUG_ABBREV, PT_DEBUG_INFO, etc. >> >> Debug sections are not normally loaded. For that reason I don't think >> it makes any sense to specify program headers for them. It wouldn't >> help in the vdso case anyway, since the problem there is that you only >> have the loaded part of the original ELF file. > > The vdso contains a section table, as well. When I hack > bfd_from_remote_memory to create BFD sections from them similar > to what elf_object_p does, I get the target sections that I wanted in GDB. I got curious. Indeed: $ gdb --quiet /bin/ls Reading symbols from /usr/bin/ls...(no debugging symbols found)...done. (gdb) catch syscall Catchpoint 1 (any syscall) (gdb) r Starting program: /usr/bin/ls Catchpoint 1 (call to syscall brk), 0x000000323d0163fa in __brk (addr=addr@entry=0x0) at ../sysdeps/unix/sysv/linux/x86_64/brk.c:32 32 __curbrk = newbrk = (void *) INLINE_SYSCALL (brk, 1, addr); (gdb) shell cat /proc/23042/maps|grep vdso 7ffff7ffd000-7ffff7fff000 r-xp 00000000 00:00 0 [vdso] (gdb) dump memory /tmp/vdso.so 0x7ffff7ffd000 0x7ffff7fff000 (gdb) q $ objdump -h /tmp/vdso.so /tmp/vdso.so: file format elf64-x86-64 Sections: Idx Name Size VMA LMA File off Algn 0 .hash 00000040 ffffffffff700120 ffffffffff700120 00000120 2**3 CONTENTS, ALLOC, LOAD, READONLY, DATA 1 .dynsym 00000108 ffffffffff700160 ffffffffff700160 00000160 2**3 CONTENTS, ALLOC, LOAD, READONLY, DATA 2 .dynstr 0000005e ffffffffff700268 ffffffffff700268 00000268 2**0 CONTENTS, ALLOC, LOAD, READONLY, DATA 3 .gnu.version 00000016 ffffffffff7002c6 ffffffffff7002c6 000002c6 2**1 CONTENTS, ALLOC, LOAD, READONLY, DATA 4 .gnu.version_d 00000038 ffffffffff7002e0 ffffffffff7002e0 000002e0 2**3 CONTENTS, ALLOC, LOAD, READONLY, DATA 5 .note 0000003c ffffffffff700318 ffffffffff700318 00000318 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 6 .eh_frame_hdr 0000003c ffffffffff700354 ffffffffff700354 00000354 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 7 .eh_frame 00000138 ffffffffff700390 ffffffffff700390 00000390 2**3 CONTENTS, ALLOC, LOAD, READONLY, DATA 8 .dynamic 000000f0 ffffffffff7004c8 ffffffffff7004c8 000004c8 2**3 CONTENTS, ALLOC, LOAD, DATA 9 .rodata 00000020 ffffffffff7005b8 ffffffffff7005b8 000005b8 2**3 CONTENTS, ALLOC, LOAD, READONLY, DATA 10 __bug_table 0000000c ffffffffff7005d8 ffffffffff7005d8 000005d8 2**0 CONTENTS, ALLOC, LOAD, READONLY, DATA 11 .discard 00000006 ffffffffff7005e4 ffffffffff7005e4 000005e4 2**0 CONTENTS, ALLOC, LOAD, DATA 12 .altinstructions 00000048 ffffffffff7005ea ffffffffff7005ea 000005ea 2**0 CONTENTS, ALLOC, LOAD, READONLY, DATA 13 .altinstr_replacement 00000012 ffffffffff700632 ffffffffff700632 00000632 2**0 CONTENTS, ALLOC, LOAD, READONLY, CODE 14 .text 0000069d ffffffffff700700 ffffffffff700700 00000700 2**4 CONTENTS, ALLOC, LOAD, READONLY, CODE 15 .comment 0000002c 0000000000000000 0000000000000000 00000d9d 2**0 CONTENTS, READONLY > The patch is rather big, though, and duplicating a lot of elf_object_p's code. Why's that? Why doesn't the memory-backed bfd paths take the same paths as a file-backed bfd internally in bfd? It sounds to me that this should be doable without duplication. -- Pedro Alves