From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20914 invoked by alias); 13 Apr 2019 00:17:54 -0000 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 Received: (qmail 20902 invoked by uid 89); 13 Apr 2019 00:17:53 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-0.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy= X-HELO: mail-vk1-f182.google.com Received: from mail-vk1-f182.google.com (HELO mail-vk1-f182.google.com) (209.85.221.182) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 13 Apr 2019 00:17:52 +0000 Received: by mail-vk1-f182.google.com with SMTP id x2so2526249vkx.13 for ; Fri, 12 Apr 2019 17:17:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sifive.com; s=google; h=mime-version:from:date:message-id:subject:to; bh=Fl864tQu2UJbEQWXAFVIiO3IWUJwx450wtOKWoQmwdg=; b=ZapqkncpVgV+uh9NegK6UFHUbjHMRqJ+xHiErz/9UlumAebQznlH/U7mgGaElAut3x b7rpRbrApk+QC1fwLdL11DLh7cQaHAb6BtXd+PV2+HX7s29BFI6j4rsEMECdFb0kMQqc jWs+3mt2Ah6cMb8ul223idUVNqQC86hS2Iok4rkXthSFrpQH+IVfrz/fu7bMoplEb8t7 nuBP8CpJg+1YnnNO4RdxeoxxzY+kd2QundfjSI0ej0oa0AIQLMvUxDGXmgM2iX63Ak50 +PJiRO6YckoxkghwgOFrGr3tiQ43G06Lv/svU3jfqut78c1nkMmZ8txShSpYRY725n+e 6wlw== MIME-Version: 1.0 From: Jim Wilson Date: Sat, 13 Apr 2019 00:17:00 -0000 Message-ID: Subject: RISC-V and fake function debug info in the testsuite To: gdb@sourceware.org Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2019-04/txt/msg00003.txt.bz2 Some of the testsuite testcases construct debug info for functions that don't exist using Dwarf::assemble. This is causing trouble for riscv64-linux. The problem here is that we have two types of breakpoints, 2-byte and 4-byte. The easy way to tell which one is safe to use is to read from target memory. But if we have debug info for a function that doesn't exist, pointing at memory locations that don't exist, then reading target memory at that address fails, causing the breakpoint command to fail. This feature can be turned off, and gdb forced to always use a 2-byte or 4-byte breakpoint which does not require reading target memory. I tried this, and found that this fixed 46 testsuite failures in gdb.cp/nsalias.exp and 1 testsuite failure in gdb.dwarf2/inlined_subroutine-inheritance.exp. The question is what to do next. I don't want to turn this feature off by default for the testsuite, as we should be testing it. We could modify the two testcases to add RISC-V specific support that turns the feature off for these testcases. We just need to send one command to gdb at the start "set riscv use-compressed-breakopints on" or off but not auto which is the default. Or maybe there is a more general way that we can fix this? Jim