From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-testers-return-110352-listarch-gdb-testers=sources.redhat.com@sourceware.org>
Received: (qmail 88367 invoked by alias); 10 May 2018 17:30:40 -0000
Mailing-List: contact gdb-testers-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <gdb-testers.sourceware.org>
List-Subscribe: <mailto:gdb-testers-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb-testers/>
List-Post: <mailto:gdb-testers@sourceware.org>
List-Help: <mailto:gdb-testers-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: gdb-testers-owner@sourceware.org
Received: (qmail 88249 invoked by uid 89); 10 May 2018 17:30:34 -0000
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.2 spammy=confirms, our
X-HELO: kwanyin.sergiodj.net
Received: from kwanyin.sergiodj.net (HELO kwanyin.sergiodj.net) (158.69.185.54) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 10 May 2018 17:30:32 +0000
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: [binutils-gdb] gdbserver/Windows: crash during connection establishment phase
From: sergiodj+buildbot@sergiodj.net
To: gdb-testers@sourceware.org
Message-Id: <190852c8ac75cb62a737c58edfadfb0e1fcef78a@gdb-build>
Date: Thu, 10 May 2018 17:39:00 -0000
X-SW-Source: 2018-q2/txt/msg03859.txt.bz2

*** TEST RESULTS FOR COMMIT 190852c8ac75cb62a737c58edfadfb0e1fcef78a ***

Author: Joel Brobecker <brobecker@adacore.com>
Branch: master
Commit: 190852c8ac75cb62a737c58edfadfb0e1fcef78a

gdbserver/Windows: crash during connection establishment phase

On Windows, starting a new process with GDBserver seems to work,
in the sense that the program does get started, and GDBserver
confirms that it is listening for GDB to connect. However, as soon as
GDB establishes the connection with GDBserver, and starts discussing
with it, GDBserver crashes, with a SEGV.

This SEGV occurs in remote-utils.c::prepare_resume_reply...

  | regp = current_target_desc ()->expedite_regs;
  | [...]
  | while (*regp)

... because, in our case, REGP is NULL.

This patches fixes the issues by adding a parameter to init_target_desc,
in order to make sure that we always provide the list of registers when
we initialize a target description.

gdb/ChangeLog:

        PR server/23158:
        * regformats/regdat.sh: Adjust script, following the addition
        of the new expedite_regs parameter to init_target_desc.

gdb/gdbserver/ChangeLog:

        PR server/23158:
        * tdesc.h (init_target_desc) <expedite_regs>: New parameter.
        * tdesc.c (init_target_desc) <expedite_regs>: New parameter.
        Use it to set the expedite_regs field in the given tdesc.
        * x86-tdesc.h: New file.
        * linux-aarch64-tdesc.c (aarch64_linux_read_description):
        Adjust following the addition of the new expedite_regs parameter
        to init_target_desc.
        * linux-tic6x-low.c (tic6x_read_description): Likewise.
        * linux-x86-tdesc.c: #include "x86-tdesc.h".
        (i386_linux_read_description, amd64_linux_read_description):
        Adjust following the addition of the new expedite_regs parameter
        to init_target_desc.
        * lynx-i386-low.c: #include "x86-tdesc.h".
        (lynx_i386_arch_setup): Adjust following the addition of the new
        expedite_regs parameter to init_target_desc.
        * nto-x86-low.c: #include "x86-tdesc.h".
        (nto_x86_arch_setup): Adjust following the addition of the new
        expedite_regs parameter to init_target_desc.
        * win32-i386-low.c: #include "x86-tdesc.h".
        (i386_arch_setup): Adjust following the addition of the new
        expedite_regs parameter to init_target_desc.