From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30193 invoked by alias); 17 Jul 2015 11:55:56 -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 30100 invoked by uid 89); 17 Jul 2015 11:55:55 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,KAM_ASCII_DIVIDERS,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=no version=3.3.2 X-HELO: mail-pa0-f54.google.com Received: from mail-pa0-f54.google.com (HELO mail-pa0-f54.google.com) (209.85.220.54) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Fri, 17 Jul 2015 11:55:52 +0000 Received: by pachj5 with SMTP id hj5so59993170pac.3 for ; Fri, 17 Jul 2015 04:55:50 -0700 (PDT) X-Received: by 10.67.30.136 with SMTP id ke8mr28663061pad.79.1437134150627; Fri, 17 Jul 2015 04:55:50 -0700 (PDT) Received: from E107787-LIN (gcc1-power7.osuosl.org. [140.211.15.137]) by smtp.gmail.com with ESMTPSA id ll6sm11029184pbc.28.2015.07.17.04.55.47 (version=TLS1_2 cipher=AES128-SHA256 bits=128/128); Fri, 17 Jul 2015 04:55:49 -0700 (PDT) From: Yao Qi To: Don Breazeal Cc: Yao Qi , "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> <55A7E4A0.2030203@codesourcery.com> Date: Fri, 17 Jul 2015 11:55:00 -0000 In-Reply-To: <55A7E4A0.2030203@codesourcery.com> (Don Breazeal's message of "Thu, 16 Jul 2015 10:06:40 -0700") Message-ID: <86y4ifhubq.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2015-07/txt/msg00505.txt.bz2 Don Breazeal writes: > 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=3D1, argv=3D0x7fffffffe9d8) 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 > -------------------------------------------------------------------- > I thought gdb.multi/multi-arch-exec.exp has already covered the case above. It fails in my clean GDB build. If it doesn't cover, we need to improve it or write a new one to cover the case. > 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. Yes, this needs some re-ordering... > > 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. I think my patch series will address this, and I am testing them. In the mean time, I don't think this multi-arch issue blocks the review to this patch series. As you said, they are related, but separated issues. --=20 Yao (=E9=BD=90=E5=B0=A7)