From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 59255 invoked by alias); 16 Jul 2015 17:06:54 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 59246 invoked by uid 89); 16 Jul 2015 17:06:54 -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,KAM_ASCII_DIVIDERS,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=no version=3.3.2 X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 16 Jul 2015 17:06:52 +0000 Received: from svr-orw-fem-04.mgc.mentorg.com ([147.34.97.41]) by relay1.mentorg.com with esmtp id 1ZFmcS-0004zu-SZ from Don_Breazeal@mentor.com ; Thu, 16 Jul 2015 10:06:48 -0700 Received: from [172.30.10.42] (147.34.91.1) by SVR-ORW-FEM-04.mgc.mentorg.com (147.34.97.41) with Microsoft SMTP Server (TLS) id 14.3.224.2; Thu, 16 Jul 2015 10:06:48 -0700 Message-ID: <55A7E4A0.2030203@codesourcery.com> Date: Thu, 16 Jul 2015 17:06:00 -0000 From: Don Breazeal User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Yao Qi CC: "gdb-patches@sourceware.org" , "palves@redhat.com" Subject: Re: [PATCH 1/5] Extended-remote exec events References: <1436996979-32350-1-git-send-email-donb@codesourcery.com> <1436996979-32350-2-git-send-email-donb@codesourcery.com> <86bnfcjj6v.fsf@gmail.com> <55A7D316.8050302@codesourcery.com> <55A7DD57.3030205@gmail.com> In-Reply-To: <55A7DD57.3030205@gmail.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2015-07/txt/msg00481.txt.bz2 On 7/16/2015 9:35 AM, Yao Qi wrote: > On 16/07/15 16:51, Don Breazeal wrote: >> You make a good point, GDBserver doesn't handle that case. I assume >> that's what this is about: >> --- >> warning: Selected architecture i386 is not compatible with reported >> target architecture i386:x86-64 >> --- >> I'll investigate. > > This messages shows that GDB (rather than GDBserver) doesn't handle > that case. AFAIK, GDBserver doesn't handle that case either. > > I am working on patches create target description at the right time > in GDBserver, derived from this patch > https://sourceware.org/ml/gdb-patches/2015-07/msg00403.html > Current GDBserver creates target description too early, if we use > --wrapper option, GDBserver created target description according > to wrapper program, instead of the program we want to debug, which > is wrong. > There is a difference between the native and gdbserver behavior with multi-arch exec. Native seems to handle multi-arch exec events: ------------------------------------------------------------------- Reading symbols from ./execler64...done. (gdb) b main Breakpoint 1 at 0x4006a4: file execler.c, line 19. (gdb) r Starting program: /home/dbreazea/junk/execler64 Breakpoint 1, main (argc=1, argv=0x7fffffffe848) at execler.c:19 19 printf ("starting %s\n", argv[0]); (gdb) info reg rax 0x7ffff7dd9ea8 140737351884456 rbx 0x0 0 rcx 0x0 0 ---etc--- (gdb) catch exec Catchpoint 2 (exec) (gdb) c Continuing. starting /home/dbreazea/junk/execler64 in execler process 5588 is executing new program: /home/dbreazea/junk/execee32 warning: the debug information found in "/lib/ld-2.11.1.so" does not match "/lib/ld-linux.so.2" (CRC mismatch). Catchpoint 2 (exec'd /home/dbreazea/junk/execee32), 0xf7fe0850 in ?? () from /lib/ld-linux.so.2 (gdb) info reg eax 0x0 0 ecx 0x0 0 ---etc--- --------------------------------------------------------------------- While the gdbserver case looks like this, unfortunately: --------------------------------------------------------------------- Reading symbols from ./execler64...done. (gdb) tar ext localhost:51111 Remote debugging using localhost:51111 Reading symbols from target:/lib64/ld-linux-x86-64.so.2...(no debugging symbols found)...done. 0x00007ffff7dddaf0 in ?? () from target:/lib64/ld-linux-x86-64.so.2 (gdb) b main Breakpoint 1 at 0x4006a4: file execler.c, line 19. (gdb) c Continuing. Breakpoint 1, main (argc=1, argv=0x7fffffffe9d8) at execler.c:19 19 printf ("starting %s\n", argv[0]); (gdb) info reg rax 0x7ffff7dd9ea8 140737351884456 rbx 0x0 0 rcx 0x0 0 ---etc--- (gdb) catch exec Catchpoint 2 (exec) (gdb) c Continuing. Thread 5561.5561 is executing new program: /home/dbreazea/junk/execee32 warning: Selected architecture i386 is not compatible with reported target architecture i386:x86-64 warning: the debug information found in "target:/lib/ld-2.11.1.so" does not match "target:/lib/ld-linux.so.2" (CRC mismatch). Remote 'g' packet reply is too long: 000000000000000000000000000000... ---several 'g' packet errors (gdb) q A debugging session is active. Inferior 1 [process 5561] will be killed. Quit anyway? (y or n) y warning: Selected architecture i386 is not compatible with reported target architecture i386:x86-64 -------------------------------------------------------------------- At first glance it looks like in linux_low_filter_event, the execing inferior needs to be marked as a 'new_inferior' (proc->priv->new_inferior) in order to do the right thing and call the_low_target.arch_setup (). That may require some re-ordering of things in linux-low.c:linux_low_filter_event, since handle_extended_wait and the exec event handling happen after the arch setup. Do you think the work you are doing will address this, or should I continue looking at a fix for the problem above? They seem like they are related, but separate issues. thanks --Don