From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24949 invoked by alias); 12 Mar 2014 17:34:40 -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 24931 invoked by uid 89); 12 Mar 2014 17:34:39 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mail-ve0-f169.google.com Received: from mail-ve0-f169.google.com (HELO mail-ve0-f169.google.com) (209.85.128.169) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Wed, 12 Mar 2014 17:34:38 +0000 Received: by mail-ve0-f169.google.com with SMTP id pa12so10871025veb.28 for ; Wed, 12 Mar 2014 10:34:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=An7mTEjKCzAuqifJRqZmhI5NFvewUd4k/oNiYk5Ayfc=; b=aGcehFQsl672ycD6RHV8bLhJY7Hy22imArzjfBXevdhIxn/n93Z66W+4Xk3lbg4Bgc A37Lh6E9KgekCpQTP0qrg5CKp3eydseRuFK8UDqwayeWCt2o+igUC9w6vUUhJU6HkRJv wDJuEaLvKhH6WALVa1QviejYG8t3z2wTXeglDgacuqfnFlM5tt/H2hjRYjfe+Md7+gV9 /9S5TIfSSY5vl3r0d5J7dvA4BZhJN9TpifsdYbS+5MUO3600mh0F/6RQGMYOJyTNWBqk GEK/+m8VA+w+6rQxZO/i2/LFejc4xiDrYga1YLlZBPmU64KyR3VC7TkO+7xjxXN5APu0 uERg== X-Gm-Message-State: ALoCoQlTextBI0QcQaDsTcddMi2Uf4IESPZ3b8uEm9BpOQHhPV1dwyKCuEkMDwdZPsM9BHyvX4T8a3LlDm2TXuyMKWDjquE+5FWG+GMykQs+umRW2LYk7rIINWnLvizn1eyfg8lgHjP4cmeKg6MHz8/PMiOUZHLogaMT2H0mdiiHfLanoTr/DWRRxljHlfTLz+YC7PHdnLRe MIME-Version: 1.0 X-Received: by 10.58.190.99 with SMTP id gp3mr1176797vec.32.1394645676422; Wed, 12 Mar 2014 10:34:36 -0700 (PDT) Received: by 10.52.13.101 with HTTP; Wed, 12 Mar 2014 10:34:36 -0700 (PDT) In-Reply-To: <20140312071701.GW26922@bubble.grove.modra.org> References: <20140312071701.GW26922@bubble.grove.modra.org> Date: Wed, 12 Mar 2014 17:34:00 -0000 Message-ID: Subject: Re: vdso handling From: Doug Evans To: "Metzger, Markus T" , "gdb@sourceware.org" , "binutils@sourceware.org" Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2014-03/txt/msg00024.txt.bz2 On Wed, Mar 12, 2014 at 12:17 AM, Alan Modra wrote: > On Mon, Mar 10, 2014 at 01:04:33PM +0000, Metzger, Markus T wrote: >> I noticed that the BFD created for the VDSO (system-provided in-memory >> DSO) does not contain any BFD sections. Is this intentional? Or has >> there just been no need for them? > [snip] >> The vdso is processed in symbol_file_add_from_memory at >> gdb/symfile-mem.c:84. It calls bfd_from_remote_memory to create a BFD >> for the vdso and then processes it. > > The underlying cause is that you're trying to debug an ELF binary that > only contains the execution view. The linking view (of which the > sections are a part) is not loaded, so bfd_from_remote_memory does not > have this information. See elfcode.h bfd_from_remote_memory. > > You can see similar breakage of gdb and binutils if you zap e_shoff, > e_shnum, and e_shstrndx of your favourite hello world program. > > I suppose one way to provide something that gdb and other tools expect > would be to treat the vdso like a core file, and create fake sections > corresponding to the program headers. I'm not really keen on the idea > though, since I know that will open up a can of worms. 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." :-)