From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7646 invoked by alias); 26 Dec 2012 00:47:09 -0000 Received: (qmail 7627 invoked by uid 22791); 26 Dec 2012 00:47:06 -0000 X-SWARE-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RCVD_IN_BRBL_LASTEXT,RCVD_IN_HOSTKARMA_YE,RCVD_IN_MSPIKE_BL,RCVD_IN_MSPIKE_L3,RCVD_IN_NJABL_RELAY,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from new.toad.com (HELO new.toad.com) (209.237.225.253) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 26 Dec 2012 00:46:55 +0000 Received: from new.toad.com (localhost.localdomain [127.0.0.1]) by new.toad.com (8.12.9/8.12.9) with ESMTP id qBQ1ZOJJ024756; Tue, 25 Dec 2012 17:35:24 -0800 Message-Id: <201212260135.qBQ1ZOJJ024756@new.toad.com> To: Aleksandar Ristovski cc: John Gilmore , Jan Kratochvil , Raphael Zulliger , gdb@sourceware.org Subject: Re: Ensure correct symbol-file when attaching to a (remote) process In-reply-to: <50D8B4C9.9080708@qnx.com> References: <50D3FC31.1020103@indel.ch> <20121221161114.GA32638@host2.jankratochvil.net> <50D4D099.3030601@qnx.com> <201212220138.qBM1caIl012256@new.toad.com> <50D520D8.1080602@qnx.com> <50D8B4C9.9080708@qnx.com> Comments: In-reply-to Aleksandar Ristovski message dated "Mon, 24 Dec 2012 15:02:17 -0500." Date: Wed, 26 Dec 2012 00:47:00 -0000 From: John Gilmore X-IsSubscribed: yes 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 X-SW-Source: 2012-12/txt/msg00080.txt.bz2 > I have addressed some of your concerns, and some issues I found while > writing the testcase. Please take a look: > http://sourceware.org/ml/gdb-patches/2012-12/msg00809.html Thank you! There are several places where you assume that there are only two possible pointer sizes ("if (ptr_size == 4)" and "else"). These should abort -- or return false -- if they encounter a pointer size they don't understand. And what is this constant "4" doing in there? In read_program_headers_from_target, you initialize load_base_trusted to 0, then in the first executable statement, you test it and abort if it's zero. It took me some detailed reading to discover that in another initializer, you pass load_base_trusted's address to lm_addr_check, which modifies it as a side effect. Could you move that call to lm_addr_check to just before the if statement, so it's clearly in a place where people can see that a side effect will occur? In svr4_validate_ehdr_match, you compare the "magic numbers" by directly feeding struct pointers to memcmp. You should compare the magic number field the same way you compare all the other fields -- as e.g. ehdr1->_32.e_magic. I'm still bothered that you read the symbol file's ELF header three times, once when BFD opens the file, once when you read the ELF header because you don't use BFD's copy, and once again when you need it to find the phdrs. And you're still reading it from location "0" in the file. Ditto for accessing the target memory twice, unnecessarily. I am also wondering why all this infrastructure has been made specific to shared libraries (it's in the solib ops vector). The original request on the mailing list was for this validation to occur for ordinary symbol-files; this implementation prevents it from ever being used for that. John