Re: Error with gnumach compilation

[Samuel Thibault]

Almudena Garcia, le ven. 15 févr. 2019 01:48:36 +0100, a ecrit:
> ../i386/i386/cswitch.S:42: Error: carácter inválido '(' en el mnemónico

This looks like the CPU_NUMBER macro missing being defined to put the
CPU number into eax.

Samuel

Error with gnumach compilation

[Almudena Garcia]

Hi all:

I'm doing some experiments with my GNUMach SMP fork, and now I'm trying to
recover old imps files.

But, when I try to compile this, It shows an assembly error in cswitch.S
(attach file)

../i386/i386/cswitch.S: Mensajes del ensamblador:
../i386/i386/cswitch.S:42: Error: carácter inválido '(' en el mnemónico
../i386/i386/cswitch.S:60: Error: carácter inválido '(' en el mnemónico
../i386/i386/cswitch.S:112: Error: carácter inválido '(' en el mnemónico
make: *** [Makefile:4804: i386/i386/cswitch.o] Error 1

My full code is here: https://github.com/AlmuHS/GNUMach_SMP/tree/wip

Can you help me to find the error?

Thanks


error_log
Description: Binary data

Re: [pushed][PATCH v3 1/4] Extended-remote follow exec

[Tom Tromey]

> "Tom" == Tom Tromey  writes:

> "Thomas" == Thomas Schwinge  writes:
Thomas> + struct cleanup *old_chain = make_cleanup (xfree, 
pathname);

Tom> Please don't add new cleanups to gdb.
Tom> We're in the process of removing them all.

Tom> Instead you can use gdb::unique_xmalloc_ptr, or std::string, or a
Tom> std::vector of some flavor.

I went ahead and added a patch to fix this to my series to remove
cleanups, so you don't need to do anything about this one.

Tom

Re: Query on ifconfig

[Almudena Garcia]

Thanks!! Now I know the command



El jue., 14 feb. 2019 a las 22:10, Samuel Thibault ()
escribió:

> Almudena Garcia, le jeu. 14 févr. 2019 22:01:55 +0100, a ecrit:
> >
> > > I have installed this package in my Debian GNU/Hurd installation,
> but
> > ifconfig
> > > appears as "command not found", even as sudo
> >
> > Use inetutils-ifconfig.
> >
> > This package don't exists in my repositories.
>
> I mean the command is called inetutils-ifconfig, not ifconfig.
>
> Samuel
>

Re: Query on ifconfig

[Samuel Thibault]

Almudena Garcia, le jeu. 14 févr. 2019 22:01:55 +0100, a ecrit:
>
> > I have installed this package in my Debian GNU/Hurd installation, but
> ifconfig
> > appears as "command not found", even as sudo
> 
> Use inetutils-ifconfig.
> 
> This package don't exists in my repositories.

I mean the command is called inetutils-ifconfig, not ifconfig.

Samuel

Re: Query on ifconfig

[Almudena Garcia]

>
>
> > I have installed this package in my Debian GNU/Hurd installation, but
> ifconfig
> > appears as "command not found", even as sudo
>
> Use inetutils-ifconfig.
>

This package don't exists in my repositories.



El jue., 14 feb. 2019 a las 21:29, Samuel Thibault ()
escribió:

> Almudena Garcia, le jeu. 14 févr. 2019 21:23:59 +0100, a ecrit:
> > I have installed this package in my Debian GNU/Hurd installation, but
> ifconfig
> > appears as "command not found", even as sudo
>
> Use inetutils-ifconfig.
>
> Samuel
>

Re: Query on ifconfig

[Samuel Thibault]

Almudena Garcia, le jeu. 14 févr. 2019 21:23:59 +0100, a ecrit:
> I have installed this package in my Debian GNU/Hurd installation, but ifconfig
> appears as "command not found", even as sudo

Use inetutils-ifconfig.

Samuel

Re: Query on ifconfig

[Almudena Garcia]

I have installed this package in my Debian GNU/Hurd installation, but
ifconfig appears as "command not found", even as sudo

El jue., 14 feb. 2019 a las 21:19, Samuel Thibault ()
escribió:

> Almudena Garcia, le jeu. 14 févr. 2019 21:14:51 +0100, a ecrit:
> > How did you install ifconfig in GNU/Hurd?
> >
> > This is not available in Debian GNU/Hurd repositories
>
> It is provided by inetutils-tools
>
> Samuel
>
>

Re: Query on ifconfig

[Samuel Thibault]

Almudena Garcia, le jeu. 14 févr. 2019 21:14:51 +0100, a ecrit:
> How did you install ifconfig in GNU/Hurd?
> 
> This is not available in Debian GNU/Hurd repositories

It is provided by inetutils-tools

Samuel

Re: Query on ifconfig

[Almudena Garcia]

How did you install ifconfig in GNU/Hurd?

This is not available in Debian GNU/Hurd repositories

El jue., 14 feb. 2019 a las 19:37, Samuel Thibault ()
escribió:

> Vinay M, le jeu. 14 févr. 2019 23:12:07 +0530, a ecrit:
> > I tried lot of googling but still not able to figure it out.
> >
> > Here is the issue details :
> > Not able to set lo0 in the latest version of "ifconfig"
> >
> > command$ sudo ifconfig lo0 alias 10.0.2.15 up
> > Getting error ->  ifconfig: invalid arguments
>
> Err, setting lo on something else than a 127.0.0.0 network is not
> supposed to work, you can only set non-local addresses on a network
> board.
>
> Samuel
>
>

Re: I would like to contribute with a new favicon for the website

[Samuel Thibault]

jbra...@dismail.de, le jeu. 14 févr. 2019 18:32:49 +, a ecrit:
> Feel free to attach the image, and I'll make the commit for you.

(please make sure of the licensing :) )

Re: Query on ifconfig

[Samuel Thibault]

Vinay M, le jeu. 14 févr. 2019 23:12:07 +0530, a ecrit:
> I tried lot of googling but still not able to figure it out. 
> 
> Here is the issue details : 
> Not able to set lo0 in the latest version of "ifconfig"
> 
> command$         sudo ifconfig lo0 alias 10.0.2.15 up
> Getting error ->  ifconfig: invalid arguments

Err, setting lo on something else than a 127.0.0.0 network is not
supposed to work, you can only set non-local addresses on a network
board.

Samuel

Re: I would like to contribute with a new favicon for the website

[jbranso]

Feel free to attach the image, and I'll make the commit for you.

February 13, 2019 9:20 PM, "Muto"  wrote:

> Hello, bug-hurd mailing list readers,
> 
> I have created a new favicon.ico, which has a cleaner design and a
> smaller filesize than the current one (766 bytes as opposed to 1.1kb).
> It does, however, have the same dimensions of 32x32 pixels.
> 
> It isn't a huge contribution, but it looks better on browser tabs that
> are using a "dark" theme (looks better on the lighter ones, too).
> 
> Is there a way I can make a git commit with this to the web.git? Thanks.
> 
> Regards, -Muto

Query on ifconfig

[Vinay M]

Hi Hurd,

I tried lot of googling but still not able to figure it out.

Here is the issue details :
Not able to set lo0 in the latest version of "ifconfig"

command$ sudo ifconfig lo0 alias 10.0.2.15 up
Getting error ->  ifconfig: invalid arguments

ifconfig -V
ifconfig (GNU inetutils) 1.9.4
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later .
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Appreciate your help.

-- 
Regards,
*Vinay*

Re: [pushed][PATCH v3 1/4] Extended-remote follow exec

[Tom Tromey]

> "Thomas" == Thomas Schwinge  writes:

Thomas> + struct cleanup *old_chain = make_cleanup (xfree, 
pathname);

Please don't add new cleanups to gdb.
We're in the process of removing them all.

Instead you can use gdb::unique_xmalloc_ptr, or std::string, or a
std::vector of some flavor.

thanks,
Tom

[gdb, hurd] Adjust to Hurd "proc" interface changes (was: proc_task2proc prototype change)

[Thomas Schwinge]

Hi!

On Tue, 06 Jun 2017 08:49:16 +0200, Justus Winter  wrote:
> David Michael  writes:
> > On Mon, Jun 5, 2017 at 7:40 AM, Justus Winter  wrote:
> >> [...]

> > The reply
> > functions still have mach_port_poly_t, though, and they are used by
> > GDB.  Is that correct?
> 
> Oh wow, a server for the reply part of a protocol.  Odd.  Well, I
> decided not to revert the change to the reply part so that it is
> consistent with how the reply of a server for the full protocol works.
> 
> > It will require something like the following to get GDB to compile due
> > to the changed generated definitions.
> > [...]
> >  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)

ACK, thanks; I pushed to GDB master the attached commit
8071c5ce78245eff43f9977a7c3ff8328f7486da '[gdb, hurd] Adjust to Hurd
"proc" interface changes'.

> Well, seeing that ILL_RPC is for unused procedures, it would be much
> easier to use MIGs "new" way of creating default server stubs that
> return a fixed value.  This can be done by #defining MIG_EOPNOTSUPP to
> some value while compiling the MIG-generated server stub.  Being a
> simpleroutine it doesn't really matter to what value, but EOPNOTSUPP
> seems to be a better choice than ILL_RPC's 0.

Thanks, we shall look into that later.


Grüße
 Thomas


>From 8071c5ce78245eff43f9977a7c3ff8328f7486da Mon Sep 17 00:00:00 2001
From: David Michael 
Date: Mon, 5 Jun 2017 17:35:11 -0700
Subject: [PATCH] [gdb, hurd] Adjust to Hurd "proc" interface changes

Hurd's commit baf7e5c8ce176aead15c2559952d8bdf0da41ffd "hurd: Use polymorphic
port types to return some rights" causes in the GDB build:

/usr/bin/ld: process_reply_S.o: in function `_Xproc_pid2proc_reply':
[...]/gdb/process_reply_S.c:754: undefined reference to `S_proc_pid2proc_reply'
/usr/bin/ld: [...]/gdb/process_reply_S.c:730: undefined reference to `S_proc_pid2proc_reply'
/usr/bin/ld: process_reply_S.o: in function `_Xproc_task2proc_reply':
[...]/gdb/process_reply_S.c:589: undefined reference to `S_proc_task2proc_reply'
/usr/bin/ld: [...]/gdb/process_reply_S.c:565: undefined reference to `S_proc_task2proc_reply'
/usr/bin/ld: process_reply_S.o: in function `_Xproc_getmsgport_reply':
[...]/gdb/process_reply_S.c:204: undefined reference to `S_proc_getmsgport_reply'
/usr/bin/ld: [...]/gdb/process_reply_S.c:180: undefined reference to `S_proc_getmsgport_reply'
collect2: error: ld returned 1 exit status

	gdb/
	* gnu-nat.c (S_proc_getmsgport_reply, S_proc_task2proc_reply)
	(S_proc_pid2proc_reply): Adjust to Hurd "proc" interface changes.
---
 gdb/ChangeLog | 7 +++
 gdb/gnu-nat.c | 8 +---
 2 files changed, 12 insertions(+), 3 deletions(-)

diff --git a/gdb/ChangeLog b/gdb/ChangeLog
index e427dda8a3..f2bbd77558 100644
--- a/gdb/ChangeLog
+++ b/gdb/ChangeLog
@@ -1,3 +1,10 @@
+2019-02-14  David Michael  
+	Samuel Thibault  
+	Thomas Schwinge  
+
+	* gnu-nat.c (S_proc_getmsgport_reply, S_proc_task2proc_reply)
+	(S_proc_pid2proc_reply): Adjust to Hurd "proc" interface changes.
+
 2019-02-14  Thomas Schwinge  
 
 	* gnu-nat.c (gnu_write_inferior, parse_int_arg, _parse_bool_arg)
diff --git a/gdb/gnu-nat.c b/gdb/gnu-nat.c
index 395b456ad7..53f23068a4 100644
--- a/gdb/gnu-nat.c
+++ b/gdb/gnu-nat.c
@@ -1880,17 +1880,19 @@ ILL_RPC (S_proc_setmsgport_reply,
 	 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,
-- 
2.19.2

Re: [pushed][PATCH v3 1/4] Extended-remote follow exec

[Thomas Schwinge]

Hi!

On Fri, 17 Feb 2017 16:45:01 +, Pedro Alves  wrote:
> Only noticed this patch now.

Heh, and I've only now gotten back to completing this.  ;-)

> > On GNU/Hurd, there is no "#define PATH_MAX", so this fails to build.
> > (I'm aware that there is other PATH_MAX usage in GDB sources, which we
> > ought to fix at some point, for example in gdbserver -- which is not yet
> > enabled for GNU/Hurd.)
> > 
> > OK to push the following?  (Similar to Svante's patch in
> > .)
> 
> 
> > 
> > --- gdb/remote.c
> > +++ gdb/remote.c
> > @@ -6927,7 +6927,6 @@ Packet: '%s'\n"),
> >   else if (strprefix (p, p1, "exec"))
> > {
> >   ULONGEST ignored;
> > - char pathname[PATH_MAX];
> >   int pathlen;
> >  
> >   /* Determine the length of the execd pathname.  */
> > @@ -6936,11 +6935,12 @@ Packet: '%s'\n"),
> >  
> >   /* Save the pathname for event reporting and for
> >  the next run command.  */
> > + char *pathname = (char *) xmalloc (pathlen + 1);
> >   hex2bin (p1, (gdb_byte *) pathname, pathlen);
> >   pathname[pathlen] = '\0';
> 
> 
> hex2bin can throw, so wrap with a cleanup:
> 
>   char *pathname = (char *) xmalloc (pathlen + 1);
>   struct cleanup *old_chain = make_cleanup (xfree, pathname);
> hex2bin (p1, (gdb_byte *) pathname, pathlen);
> pathname[pathlen] = '\0';
>   discard_cleanups (old_chain);
> 
> OK with that change.

Thanks; pushed to master the attached commit
b671c7fb21306ce125717a44c30a71686bd24db1 "[gdb, hurd] Avoid using
'PATH_MAX' in 'gdb/remote.c'".


Grüße
 Thomas


>From b671c7fb21306ce125717a44c30a71686bd24db1 Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Fri, 17 Feb 2017 16:45:01 +
Subject: [PATCH] [gdb, hurd] Avoid using 'PATH_MAX' in 'gdb/remote.c'

..., which is not defined in GNU/Hurd systems, and so commit
94585166dfea8232c248044f9f4b1c217dc4ac2e "Extended-remote follow-exec" caused:

[...]/gdb/remote.c: In member function 'void remote_target::remote_parse_stop_reply(const char*, stop_reply*)':
[...]/gdb/remote.c:7343:22: error: 'PATH_MAX' was not declared in this scope
char pathname[PATH_MAX];
  ^~~~

	gdb/
	* remote.c (remote_target::remote_parse_stop_reply): Avoid using
	'PATH_MAX'.
---
 gdb/ChangeLog | 6 ++
 gdb/remote.c  | 6 --
 2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/gdb/ChangeLog b/gdb/ChangeLog
index f2bbd77558..bb27f74de1 100644
--- a/gdb/ChangeLog
+++ b/gdb/ChangeLog
@@ -1,3 +1,9 @@
+2019-02-14  Thomas Schwinge  
+	Pedro Alves  
+
+	* remote.c (remote_target::remote_parse_stop_reply): Avoid using
+	'PATH_MAX'.
+
 2019-02-14  David Michael  
 	Samuel Thibault  
 	Thomas Schwinge  
diff --git a/gdb/remote.c b/gdb/remote.c
index 18e678d07a..85af01e4b7 100644
--- a/gdb/remote.c
+++ b/gdb/remote.c
@@ -7340,7 +7340,6 @@ Packet: '%s'\n"),
 	  else if (strprefix (p, p1, "exec"))
 	{
 	  ULONGEST ignored;
-	  char pathname[PATH_MAX];
 	  int pathlen;
 
 	  /* Determine the length of the execd pathname.  */
@@ -7349,11 +7348,14 @@ Packet: '%s'\n"),
 
 	  /* Save the pathname for event reporting and for
 		 the next run command.  */
+	  char *pathname = (char *) xmalloc (pathlen + 1);
+	  struct cleanup *old_chain = make_cleanup (xfree, pathname);
 	  hex2bin (p1, (gdb_byte *) pathname, pathlen);
 	  pathname[pathlen] = '\0';
+	  discard_cleanups (old_chain);
 
 	  /* This is freed during event handling.  */
-	  event->ws.value.execd_pathname = xstrdup (pathname);
+	  event->ws.value.execd_pathname = pathname;
 	  event->ws.kind = TARGET_WAITKIND_EXECD;
 
 	  /* Skip the registers included in this packet, since
-- 
2.19.2