From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1700 invoked by alias); 22 Dec 2012 00:38:54 -0000 Received: (qmail 1692 invoked by uid 22791); 22 Dec 2012 00:38:53 -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; Sat, 22 Dec 2012 00:38:45 +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 qBM1caIl012256; Fri, 21 Dec 2012 17:38:36 -0800 Message-Id: <201212220138.qBM1caIl012256@new.toad.com> To: Aleksandar Ristovski cc: Jan Kratochvil , Raphael Zulliger , gdb@sourceware.org Subject: Re: Ensure correct symbol-file when attaching to a (remote) process In-reply-to: <50D4D099.3030601@qnx.com> References: <50D3FC31.1020103@indel.ch> <20121221161114.GA32638@host2.jankratochvil.net> <50D4D099.3030601@qnx.com> Comments: In-reply-to Aleksandar Ristovski message dated "Fri, 21 Dec 2012 16:11:53 -0500." Date: Sat, 22 Dec 2012 00:38: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/msg00074.txt.bz2 > Interesting timing. I have just posted > http://sourceware.org/ml/gdb-patches/2012-12/msg00776.html addressing > this issue. That's a useful patch. It's smart to read the headers from the "symbol_file" bfd (well, in this case the solib bfd used for symbols) rather than from the "exec_file" bfd. But doesn't it read the ELF header twice? In svr4_validate_hdrs_match, it reads it once in the call to read_elf_header_from_target, and then reads it again by calling read_program_headers_from_target which again calls read_elf_header_from_target. I suspect that you should pass the already-read ELF header into each of the read_program_headers functions. Also, in read_elf_header_from_bfd, BFD has probably already read the ELF header, when it first opened the file, and has it lying around. This code should not be (1) reading it again, nor (2) seeking to file offset "0" (not even a #define, not even "0L", but an int constant!) to get it. Also, it might be simpler in read_program_headers_from_target to just translate the ELF header into its internal BFD struct form - then all that manual messing with byte orders and field lengths could be eliminated. See how read_program_headers_from_bfd does it. You could also just call bfd_get_elf_phdrs (and before that, bfd_get_elf_phdr_upper_bound to size the buffer) which would avoid spreading details into GDB about these headers and how they are read and translated into local byte order. BFD even has a bfd_elf_bfd_from_remote_memory function for creating a BFD by portably reading the target's ELF header and phdrs out of memory. Also, is "validate" the right name for this? That works for checking shared libraries, but it's not as obvious what this function should do when e.g. checking the argument to symbol_file, or immediately after doing "target attach remote". If "validation" fails, should we refuse to read that symbol file, or refuse to attach to the remote target? What exactly are we validating? Perhaps "compare_headers" or "do_symbols_and_target_match" are better names. With those things addressed, it's a good start. Then, shouldn't this call be implemented for non-shared-library symbol files (like Mr. Zulliger was hoping for), and for object file formats other than ELF? Has this code been tested when the target uses a different byte order than the host? Probably not, since it is only currently invoked for shared library loads, which usually only happen native. Is there a test case written for it? Could it be easily extended to check a build-id when one exists? Or would that require different function arguments, or need to happen at a different time? Should "target attach" do this kind of validation traffic to and from the target? Or should checking this be a separate step initiated by the user? The target might be in a relatively sensitive state -- or the user might not want to wait for this check -- immediately after attaching. We could add yet another GDB setting for automatic or manual validation, defaulting to "check", and requiring those who want to bypass the check to set that setting. Is that too much complication for the gain? John