From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-f47.google.com (mail-wm1-f47.google.com [209.85.128.47]) by sourceware.org (Postfix) with ESMTPS id EC980386EC08 for ; Thu, 9 May 2024 15:49:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org EC980386EC08 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=palves.net Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org EC980386EC08 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=209.85.128.47 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1715269776; cv=none; b=sEYUSlnlpREG6wPUrfLkUyFmCVO6SzKpnnZqJBNgInLwgIsWp6P46M8S9AUOIp2xNk6QiJTco2lF3t0feRZWwGEYnW0Eg6pPX+gyBzYNeXBI7VbLhTYMmEFPbBW5MdEz2TSaJ+2kh8n9kJTrpnBuFo9/qwZTV0BF++WQcTR1NA8= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1715269776; c=relaxed/simple; bh=RS46UczWxIn49H/EjNg7CZj/butoeJMnu84SfZOa/tA=; h=Message-ID:Date:MIME-Version:Subject:To:From; b=obJ+9IfnFVMnU3kbrOxAd1ivjE0mNgw9XLIWfAKZoJI692qwSi5oqq9j71qr009T8FAZrVIXz9FYdZlSC+Pv6sdCcPjtQEXgXGVzIJTrBJXcKMvbJZeGBwUpCXRiZZ3G3dkohCCe5an8+DcUmSqLDS74iMzqlcfmKLKFcmU5e/s= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-wm1-f47.google.com with SMTP id 5b1f17b1804b1-41b79451145so7982345e9.3 for ; Thu, 09 May 2024 08:49:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1715269773; x=1715874573; h=content-transfer-encoding:in-reply-to:content-language:from :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=KtET1PgAqba8f3zWq13vpLrjsLsj+vUlXAPC8dsBYu8=; b=SHhF1VAHyutEkNaekzUsYVSN5097xDhkFvQ1CXtPTMpRviEaPXimN4kJQ6+pyQ9tz4 unZLJ8iuFUBeZgp5n6WwXwY6UlccuysmeL/C+n8Q3hd6Xpw6FVnV33ZRdRL4C89FRTrK 5RNvHJwXbeM7cGLoCpZtB+5Ld4OUWGEut22PRFClZKSSZQ7ps4+b1H8n1kPSjzb0dgbi sI1RqAEW5TiidEh0VJ9J84gSOVqcvLWB1/Op6WPY9Ow6YaSriUsu35IGBGylJqN0Evb0 uVyPcfXccjq/MprdSOoAbXO1nIonZzgFl25LNACKno4mVePbmtP2fGG503j5cjPqmfPz e3zg== X-Gm-Message-State: AOJu0YxOd6X3541AApIaJNQLelf7E2IUamubihajCrtWwrEJBpmSMJ3r gdtKPtRU8Xc8+A/zBGznY6TmB8rSi8N5w9X+GLUrYsOJfir0jOLwgEhCi/oe X-Google-Smtp-Source: AGHT+IHyEgh4TqDKWt01X6X/2ydGMzIJRq4fhgZA8Clr48TpGvVHOCtPzrUOT5nSi97yiAEQotJJmA== X-Received: by 2002:a05:600c:4f45:b0:41f:9ae3:57f2 with SMTP id 5b1f17b1804b1-41fead65a45mr572295e9.37.1715269772503; Thu, 09 May 2024 08:49:32 -0700 (PDT) Received: from ?IPV6:2001:8a0:f908:4900:881:a2f1:7c74:444d? ([2001:8a0:f908:4900:881:a2f1:7c74:444d]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-41fccee94dasm29082735e9.32.2024.05.09.08.49.31 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 09 May 2024 08:49:32 -0700 (PDT) Message-ID: <275dc4af-a3ac-4e3b-96f0-6bc60a3a3f99@palves.net> Date: Thu, 9 May 2024 16:49:27 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 09/12] gdb_target_is_native -> gdb_protocol_is_native To: Bernd Edlinger , Tom Tromey Cc: gdb-patches@sourceware.org References: <20240419151342.1592474-1-pedro@palves.net> <20240419151342.1592474-10-pedro@palves.net> <87edb1w5iq.fsf@tromey.com> <3a7ddd13-c4f7-4dcd-99d4-2c943195540a@palves.net> From: Pedro Alves Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3.5 required=5.0 tests=BAYES_00,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS,KAM_DMARC_STATUS,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 2024-05-09 16:01, Bernd Edlinger wrote: > On 5/9/24 15:31, Pedro Alves wrote: >> >> On 2024-05-09 14:19, Bernd Edlinger wrote: >>> Hmm, okay, it is better than now, >> >> Indeed, seems strictly better. Some tests that are meant for the native target are now properly >> skipped. >> >>> but the test casese that are affected, would probably >>> be broken by this change, if my target toolchain would either have the -linux in the name, >>> or the newlib would have a sleep and/or support the #include . >> >> I am afraid I don't know what you mean by this. Why would they be broken? Can you clarify? > > What I mean is this: > > there are in total 44 test cases failed to compile because of undefined reference to sleep, usleep or nanosleep > with your patch it is now one less. > > But it would be piece of cake to implement some functions like > sleep(), usleep(), and nanosleep in the newlib, and then make the simulator simulate it. > > Likewise there are currently 5 test cases failed to compile because of missing sys/mman.h header, > and with your patch it will be one less, but what if we want to add that to the > simulator, why cant we simulate a linux O/S? > > What is so special in the one test case that changed the behavior, that > explains why the other 4 are good enough to try to include, and see if works? > The gdb.base/load-command.exp testcase just doesn't make sense to test with the native target, since with the native target, you don't use the "load" command to load programs. So the testcase checks for that: if [gdb_protocol_is_native] { unsupported "the native target does not support the load command" return } Normally, a testcase that checks whether it is testing with the native target does so because it is testing some feature of the native target (the ptrace support, etc.), and so such an early check isn't that much about whether sleep or sys/mman.h exists (they don't exist on native Windows, for example, and there are native-only tests that you'd still want to run there). If a testcase should run against the sim target and would no longer run because we set gdb_protocol, then that would be a problem with the testcase itself, for using the wrong predicate to skip itself. We've had plenty of cases of testcases using the wrong predicate over the years, that is something that we're fixing pretty frequently, so please don't be surprised if we need to do that after this change too. Looking at gdb.base/many-headers.exp for example (the first in your previous message that shows compile errors), it has: if { [target_info gdb_protocol] != "" } { # Even though the feature under features being tested are supported by # gdbserver, the way this test is written doesn't make it easy with a # remote target. unsupported "not native" return } Note the comment -- it is saying to skip testing on remote, but then it skips on any board that sets gdb_protocol to anything (meaning, not native). If this truly should only be skipped with remote targets, then it should instead do this: require gdb_protocol_is_remote which is equivalent to: if { [target_info gdb_protocol] == "remote" || [target_info gdb_protocol] == "extended-remote" } { return } But, actually looking at the testcase, we see that it launches a program outside gdb, so that the program crashes and generates a core (core_find), and then debugs the core under gdb, with GDB stack limited to 4MB. From the commit's log (31aceee86308), it's the equivalent of doing: $ ulimit -s 4096 $ gdb -batch ./a.out core.saved [New LWP 19379] Segmentation fault (core dumped) ... So, I don't really understand what the "features being tested are supported by gdbserver" remark is alluding to, since gdbserver does not support loading cores. But then again, the test doesn't even connect to the native target nor the remote target anyhow. So we could let the testcase run when testing against a gdbserver board anyhow. Maybe what the comment is trying to say is, not easy to test with a "remote target" in dejagnu sense, i.e., when you have to connect to a remote host board running on a separate system, as in that scenario it's not easy to set ulimit. Is so, a better predicate to check would be "require !is_remote host" or "require isnative". A similar analysis would have to be done to the other testcases.