[Fwd: gdb: FTBFS on hurd-i386]

[Fwd: gdb: FTBFS on hurd-i386]

[Svante Signell]

[-- Attachment #1: Type: text/plain, Size: 183 bytes --]

Hello,

These patches was submitted to Debian November 13 2017. Nothing has
happened so far, so maybe upstream would be interested to consider the
patches for next release.

Thanks!  

[-- Attachment #2: Forwarded message - gdb: FTBFS on hurd-i386 --]
[-- Type: message/rfc822, Size: 13100 bytes --]

[-- Attachment #2.1.1: Type: text/plain, Size: 905 bytes --]

Source: gdb
Version: 8.0-1
Severity: important
Tags: patch
User: debian-hurd@lists.debian.org
Usertags: hurd, experimental

Hi,

gdb FTBFS on GNU/Hurd due to three reasons:

- Usage of PATH_MAX in gdb/remote.c

- Recent changes in Hurd failing the build of gdb/gnu-nat.c

- A name clash of struct thread_info and the kernel function thread_info()
included in gdb/thread.c and gdb/python/py-record-btrace.c.

Include paths:
1) defs.h: #include "gdbarch.h": struct thread_info

2) defs.h: #include "nm.h":#include <mach.h>:#include <mach/mach_interface.h>
where the function thread_info() is defined:

extern kern_return_t thread_info
(
 mach_port_t target_thread,
 int flavor,
 thread_info_t thread_info_out,
 mach_msg_type_number_t *thread_info_outCnt
);

The attached patches fixes these issues:
gdb-PATH_MAX.patch
gnu-nat.c.patch
struct-thread_info.patch

Thanks :)\r

[-- Attachment #2.1.2: gdb-PATH_MAX.patch --]
[-- Type: text/x-patch, Size: 987 bytes --]

Index: gdb-8.0/gdb/remote.c
===================================================================
--- gdb-8.0.orig/gdb/remote.c
+++ gdb-8.0/gdb/remote.c
@@ -6939,7 +6939,7 @@ Packet: '%s'\n"),
 	  else if (strprefix (p, p1, "exec"))
 	    {
 	      ULONGEST ignored;
-	      char pathname[PATH_MAX];
+	      char *pathname = NULL;
 	      int pathlen;
 
 	      /* Determine the length of the execd pathname.  */
@@ -6948,12 +6948,14 @@ Packet: '%s'\n"),
 
 	      /* Save the pathname for event reporting and for
 		 the next run command.  */
+	      pathname = (char *) xmalloc(pathlen + 1);
 	      hex2bin (p1, (gdb_byte *) pathname, pathlen);
 	      pathname[pathlen] = '\0';
 
 	      /* This is freed during event handling.  */
 	      event->ws.value.execd_pathname = xstrdup (pathname);
 	      event->ws.kind = TARGET_WAITKIND_EXECD;
+	      xfree (pathname);
 
 	      /* Skip the registers included in this packet, since
 		 they may be for an architecture different from the

[-- Attachment #2.1.3: gnu-nat.c.patch --]
[-- Type: text/x-patch, Size: 2815 bytes --]

Index: gdb-8.0/gdb/gnu-nat.c
===================================================================
--- gdb-8.0.orig/gdb/gnu-nat.c
+++ gdb-8.0/gdb/gnu-nat.c
@@ -1869,22 +1869,28 @@ S_proc_wait_reply (mach_port_t reply, ke
   return 0;
 }
 
+/* Note: The third argument to S_proc_getmsgport_reply, S_proc_task2proc_reply and
+   S_proc_pid2proc_reply is of type mach_port_poly_t. Look at gdb/process_reply_S.h
+   derived from process_reply.defs to find out the fourth argument */
+
 ILL_RPC (S_proc_setmsgport_reply,
 	 mach_port_t reply_port, kern_return_t return_code,
 	 mach_port_t oldmsgport)
 ILL_RPC (S_proc_getmsgport_reply,
 	 mach_port_t reply_port, kern_return_t return_code,
-	 mach_port_t msgports)
+	 mach_port_t msgports, mach_msg_type_name_t msgportsPoly)
 ILL_RPC (S_proc_pid2task_reply,
 	 mach_port_t reply_port, kern_return_t return_code, mach_port_t task)
 ILL_RPC (S_proc_task2pid_reply,
 	 mach_port_t reply_port, kern_return_t return_code, pid_t pid)
 ILL_RPC (S_proc_task2proc_reply,
-	 mach_port_t reply_port, kern_return_t return_code, mach_port_t proc)
+	 mach_port_t reply_port, kern_return_t return_code, mach_port_t proc,
+	 mach_msg_type_name_t procPoly)
 ILL_RPC (S_proc_proc2task_reply,
 	 mach_port_t reply_port, kern_return_t return_code, mach_port_t task)
 ILL_RPC (S_proc_pid2proc_reply,
-	 mach_port_t reply_port, kern_return_t return_code, mach_port_t proc)
+	 mach_port_t reply_port, kern_return_t return_code, mach_port_t proc,
+	 mach_msg_type_name_t procPoly)
 ILL_RPC (S_proc_getprocinfo_reply,
 	 mach_port_t reply_port, kern_return_t return_code,
 	 int flags, procinfo_t procinfo, mach_msg_type_number_t procinfoCnt,
@@ -2356,7 +2362,7 @@ gnu_write_inferior (task_t task, CORE_AD
   mach_msg_type_number_t copy_count;
   int deallocate = 0;
 
-  char *errstr = "Bug in gnu_write_inferior";
+  const char *errstr = "Bug in gnu_write_inferior";
 
   struct vm_region_list *region_element;
   struct vm_region_list *region_head = NULL;
@@ -2743,7 +2749,7 @@ show_thread_default_cmd (char *args, int
 }
 
 static int
-parse_int_arg (char *args, char *cmd_prefix)
+parse_int_arg (const char *args, const char *cmd_prefix)
 {
   if (args)
     {
@@ -2758,7 +2764,7 @@ parse_int_arg (char *args, char *cmd_pre
 }
 
 static int
-_parse_bool_arg (char *args, char *t_val, char *f_val, char *cmd_prefix)
+_parse_bool_arg (const char *args, const char *t_val, const char *f_val, const char *cmd_prefix)
 {
   if (!args || strcmp (args, t_val) == 0)
     return 1;
@@ -2774,7 +2780,7 @@ _parse_bool_arg (char *args, char *t_val
   _parse_bool_arg (args, "on", "off", cmd_prefix)
 
 static void
-check_empty (char *args, char *cmd_prefix)
+check_empty (const char *args, const char *cmd_prefix)
 {
   if (args)
     error (_("Garbage after \"%s\" command: `%s'"), cmd_prefix, args);

[-- Attachment #2.1.4: struct-thread_info.patch --]
[-- Type: text/x-patch, Size: 4083 bytes --]

Index: gdb-8.0/gdb/thread.c
===================================================================
--- gdb-8.0.orig/gdb/thread.c
+++ gdb-8.0/gdb/thread.c
@@ -76,21 +76,21 @@ static void restore_current_thread (ptid
 class scoped_inc_dec_ref
 {
 public:
-  explicit scoped_inc_dec_ref (const std::vector<thread_info *> &thrds)
+  explicit scoped_inc_dec_ref (const std::vector<struct thread_info *> &thrds)
     : m_thrds (thrds)
   {
-    for (thread_info *thr : m_thrds)
+    for (struct thread_info *thr : m_thrds)
       thr->incref ();
   }
 
   ~scoped_inc_dec_ref ()
   {
-    for (thread_info *thr : m_thrds)
+    for (struct thread_info *thr : m_thrds)
       thr->decref ();
   }
 
 private:
-  const std::vector<thread_info *> &m_thrds;
+  const std::vector<struct thread_info *> &m_thrds;
 };
 
 
@@ -207,7 +207,7 @@ clear_thread_inferior_resources (struct
 /* Set the TP's state as exited.  */
 
 static void
-set_thread_exited (thread_info *tp, int silent)
+set_thread_exited (struct thread_info *tp, int silent)
 {
   /* Dead threads don't need to step-over.  Remove from queue.  */
   if (tp->step_over_next != NULL)
@@ -254,7 +254,7 @@ init_thread_list (void)
 static struct thread_info *
 new_thread (struct inferior *inf, ptid_t ptid)
 {
-  thread_info *tp = new thread_info (inf, ptid);
+  struct thread_info *tp = new struct thread_info (inf, ptid);
 
   if (thread_list == NULL)
     thread_list = tp;
@@ -1574,7 +1574,7 @@ restore_selected_frame (struct frame_id
 
 struct current_thread_cleanup
 {
-  thread_info *thread;
+  struct thread_info *thread;
   struct frame_id selected_frame_id;
   int selected_frame_level;
   int was_stopped;
@@ -1716,7 +1716,7 @@ static bool tp_array_compar_ascending;
    order is determined by TP_ARRAY_COMPAR_ASCENDING.  */
 
 static bool
-tp_array_compar (const thread_info *a, const thread_info *b)
+tp_array_compar (const struct thread_info *a, const struct thread_info *b)
 {
   if (a->inf->num != b->inf->num)
     {
@@ -1774,11 +1774,11 @@ thread_apply_all_command (char *cmd, int
 	 thread, in case the command is one that wipes threads.  E.g.,
 	 detach, kill, disconnect, etc., or even normally continuing
 	 over an inferior or thread exit.  */
-      std::vector<thread_info *> thr_list_cpy;
+      std::vector<struct thread_info *> thr_list_cpy;
       thr_list_cpy.reserve (tc);
 
       {
-	thread_info *tp;
+	struct thread_info *tp;
 
 	ALL_NON_EXITED_THREADS (tp)
 	  {
@@ -1794,7 +1794,7 @@ thread_apply_all_command (char *cmd, int
 
       std::sort (thr_list_cpy.begin (), thr_list_cpy.end (), tp_array_compar);
 
-      for (thread_info *thr : thr_list_cpy)
+      for (struct thread_info *thr : thr_list_cpy)
 	if (thread_alive (thr))
 	  {
 	    switch_to_thread (thr->ptid);
Index: gdb-8.0/gdb/python/py-record-btrace.c
===================================================================
--- gdb-8.0.orig/gdb/python/py-record-btrace.c
+++ gdb-8.0/gdb/python/py-record-btrace.c
@@ -71,7 +71,7 @@ btrace_insn_from_recpy_insn (const PyObj
 {
   const btrace_insn *insn;
   const recpy_element_object *obj;
-  thread_info *tinfo;
+  struct thread_info *tinfo;
   btrace_insn_iterator iter;
 
   if (Py_TYPE (pyobject) != &recpy_insn_type)
@@ -114,7 +114,7 @@ btrace_func_from_recpy_func (const PyObj
 {
   const btrace_function *func;
   const recpy_element_object *obj;
-  thread_info *tinfo;
+  struct thread_info *tinfo;
   btrace_call_iterator iter;
 
   if (Py_TYPE (pyobject) != &recpy_func_type)
@@ -152,7 +152,7 @@ btrace_func_from_recpy_func (const PyObj
    gdb.RecordInstruction or gdb.RecordGap object for it accordingly.  */
 
 static PyObject *
-btpy_insn_or_gap_new (const thread_info *tinfo, Py_ssize_t number)
+btpy_insn_or_gap_new (const struct thread_info *tinfo, Py_ssize_t number)
 {
   btrace_insn_iterator iter;
   int err_code;
@@ -338,7 +338,7 @@ PyObject *
 recpy_bt_func_level (PyObject *self, void *closure)
 {
   const btrace_function * const func = btrace_func_from_recpy_func (self);
-  thread_info *tinfo;
+  struct thread_info *tinfo;
 
   if (func == NULL)
     return NULL;

Re: Bug#881569: [Fwd: gdb: FTBFS on hurd-i386]

[Héctor Orón Martínez]

Hello Svante,

On Sat, Dec 23, 2017 at 7:41 PM, Svante Signell
<svante.signell@gmail.com> wrote:
> Hello,
>
> These patches was submitted to Debian November 13 2017. Nothing has
> happened so far, so maybe upstream would be interested to consider the
> patches for next release.

I would like to have them applied in Debian package for next release,
however it is taking more time than I thought, then I am going on
vacations. If you are able to upload to Debian, feel free to NMU the
package, otherwise, I'll try to have a look in a couple weeks.

> Thanks!
>
> ---------- Forwarded message ----------
> From: Svante Signell <svante.signell@gmail.com>
> To: Debian Bug Tracking System <submit@bugs.debian.org>
> Cc:
> Bcc:
> Date: Mon, 13 Nov 2017 04:31:34 +0100
> Subject: gdb: FTBFS on hurd-i386
> Source: gdb
> Version: 8.0-1
> Severity: important
> Tags: patch
> User: debian-hurd@lists.debian.org
> Usertags: hurd, experimental
>
> Hi,
>
> gdb FTBFS on GNU/Hurd due to three reasons:
>
> - Usage of PATH_MAX in gdb/remote.c
>
> - Recent changes in Hurd failing the build of gdb/gnu-nat.c
>
> - A name clash of struct thread_info and the kernel function thread_info()
> included in gdb/thread.c and gdb/python/py-record-btrace.c.
>
> Include paths:
> 1) defs.h: #include "gdbarch.h": struct thread_info
>
> 2) defs.h: #include "nm.h":#include <mach.h>:#include <mach/mach_interface.h>
> where the function thread_info() is defined:
>
> extern kern_return_t thread_info
> (
>  mach_port_t target_thread,
>  int flavor,
>  thread_info_t thread_info_out,
>  mach_msg_type_number_t *thread_info_outCnt
> );
>
> The attached patches fixes these issues:
> gdb-PATH_MAX.patch
> gnu-nat.c.patch
> struct-thread_info.patch
>
> Thanks :)
>



-- 
 Héctor Orón  -.. . -... .. .- -.   -.. . ...- . .-.. --- .--. . .-.

Re: Bug#881569: [Fwd: gdb: FTBFS on hurd-i386]

[Svante Signell]

On Tue, 2017-12-26 at 09:40 +0100, Héctor Orón Martínez wrote:
> Hello Svante,
> 
> On Sat, Dec 23, 2017 at 7:41 PM, Svante Signell
> <svante.signell@gmail.com> wrote:
> > Hello,
> > 
> > These patches was submitted to Debian November 13 2017. Nothing has
> > happened so far, so maybe upstream would be interested to consider
> > the
> > patches for next release.
> 
> I would like to have them applied in Debian package for next release,
> however it is taking more time than I thought, then I am going on
> vacations. If you are able to upload to Debian, feel free to NMU the
> package, otherwise, I'll try to have a look in a couple weeks.

Hi again,

Unfortunately I'm not authorized to NMU that package. However, the
reason for submitting the patches upstream is that they should be
applied there. In the meanwhile we could create a Debian package of
8.0.1 (or later). If you don't have time maybe Samuel could help out
here?

Thanks for your reply anyway!

Re: Bug#881569: [Fwd: gdb: FTBFS on hurd-i386]

[Svante Signell]

Ping

On Wed, 2017-12-27 at 23:36 +0100, Svante Signell wrote:
> On Tue, 2017-12-26 at 09:40 +0100, Héctor Orón Martínez wrote:
> > Hello Svante,
> > 
> > On Sat, Dec 23, 2017 at 7:41 PM, Svante Signell
> > <svante.signell@gmail.com> wrote:
> > > Hello,
> > > 
> > > These patches was submitted to Debian November 13 2017. Nothing has
> > > happened so far, so maybe upstream would be interested to consider
> > > the
> > > patches for next release.
> > 
> > I would like to have them applied in Debian package for next release,
> > however it is taking more time than I thought, then I am going on
> > vacations. If you are able to upload to Debian, feel free to NMU the
> > package, otherwise, I'll try to have a look in a couple weeks.
> 
> Hi again,
> 
> Unfortunately I'm not authorized to NMU that package. However, the
> reason for submitting the patches upstream is that they should be
> applied there. In the meanwhile we could create a Debian package of
> 8.0.1 (or later). If you don't have time maybe Samuel could help out
> here?
> 
> Thanks for your reply anyway!