From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20426 invoked by alias); 6 Nov 2012 20:20:15 -0000 Received: (qmail 20411 invoked by uid 22791); 6 Nov 2012 20:20:13 -0000 X-SWARE-Spam-Status: No, hits=-4.5 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL X-Spam-Check-By: sourceware.org Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 06 Nov 2012 20:20:04 +0000 Received: from svr-orw-exc-10.mgc.mentorg.com ([147.34.98.58]) by relay1.mentorg.com with esmtp id 1TVpcv-0005fR-Sb from Luis_Gustavo@mentor.com ; Tue, 06 Nov 2012 12:20:01 -0800 Received: from NA1-MAIL.mgc.mentorg.com ([147.34.98.181]) by SVR-ORW-EXC-10.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 6 Nov 2012 12:20:01 -0800 Received: from [0.0.0.0] ([172.16.63.104]) by NA1-MAIL.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 6 Nov 2012 12:20:01 -0800 Message-ID: <509970EF.1060503@codesourcery.com> Date: Tue, 06 Nov 2012 20:20:00 -0000 From: Luis Machado Reply-To: lgustavo@codesourcery.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.28) Gecko/20120313 Lightning/1.0b2 Thunderbird/3.1.20 MIME-Version: 1.0 To: Pedro Alves CC: lgustavo@codesourcery.com, Joel Brobecker , gdb-patches@sourceware.org Subject: Re: [PATCH,tests] Run to main before doing any tests in structs3.exp References: <50994431.1040405@codesourcery.com> <20121106173029.GC5103@adacore.com> <50995C16.2060507@codesourcery.com> <50996120.9070806@redhat.com> In-Reply-To: <50996120.9070806@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes 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 X-SW-Source: 2012-11/txt/msg00129.txt.bz2 On 11/06/2012 05:12 PM, Pedro Alves wrote: > On 11/06/2012 06:51 PM, Luis Machado wrote: >> Hi Joel, >> >> On 11/06/2012 03:30 PM, Joel Brobecker wrote: >>>> On remote targets, we don't always start at the entry point. Thus, >>>> it is safer to get to main and do the tests from that point onwards. >>> >>> Can you elaborate more? Your patch looks reasonable at first sight, >>> but then at the same time now introduces a new requirement that it >>> needs to be run on the target, whereas that was not the case before. >>> >>> The testcase only prints global variables. I don't suppose there >>> is much of a guaranty that you could print global variables without >>> starting the program first, but it's been generally working. So >>> I am curious as to why it isn't working in your case. >> >> We've been generally only testing these with native targets or with gdbserver on linux, both of which have well-known inferior startup procedures. >> >> Consider, for example, a target that runs on QEMU. QEMU won't start the binary in exactly the same way as gdbserver running on linux. Thus, global variable initialization procedures may not have happened at that point yet. Consider that we start even before the dynamic loader had a chance to run and do all the relocation magic. >> >> In this case, it makes no sense to try to print global variables since they will only contain garbage. >> >> Effectively starting the binary and running to a known location helps avoid such a situation, and it does not change much for targets that already passed these tests. >> >> Hopefully this explains things a little better. > > The difference between native and remote debugging, is that on native > debugging, we don't start the inferior in any way at all. Ideally we'd > make the test environments in both cases as similar as possible. > So we have two options: > > #1 - Always run to main, so to get past startup for remote targets, > thus on native debugging we'll start the inferior too. This is your patch. > > #2 - Don't start the inferior at all against remote targets too. > We have several tests that do this, as not spawning the remote > server cuts a bit of test time. This is done by using gdb_file > instead of gdb_load (it is usually gdb_load that spawns the remote > side). > > I haven't really thought if #2 makes sense for this test; I just wanted > to explain that option #2 exists. > Thanks Pedro. #2 seems to work just as well. We will read data straight from the binary's sections without having to touch real memory. I'm fine with either solution.