[PATCH gnumach] Remove a.out support for ddb

[Flavio Cruz]

We haven't built gnumach using a.out for a very long time.

---
 Makefrag.am |   2 -
 ddb/db_aout.c   | 505 
 ddb/db_aout.h   |  52 -
 ddb/db_sym.c|   8 +-
 ddb/db_sym.h|   8 +-
 i386/i386at/model_dep.c |  27 ---
 6 files changed, 2 insertions(+), 600 deletions(-)
 delete mode 100644 ddb/db_aout.c
 delete mode 100644 ddb/db_aout.h

diff --git a/Makefrag.am b/Makefrag.am
index 128f7911..9ad3c27a 100644
--- a/Makefrag.am
+++ b/Makefrag.am
@@ -23,8 +23,6 @@ if enable_kdb
 libkernel_a_SOURCES += \
ddb/db_access.c \
ddb/db_access.h \
-   ddb/db_aout.c \
-   ddb/db_aout.h \
ddb/db_elf.c \
ddb/db_elf.h \
ddb/db_break.c \
diff --git a/ddb/db_aout.c b/ddb/db_aout.c
deleted file mode 100644
index 7b769c1c..
--- a/ddb/db_aout.c
+++ /dev/null
@@ -1,505 +0,0 @@
-/*
- * Mach Operating System
- * Copyright (c) 1991,1990 Carnegie Mellon University
- * All Rights Reserved.
- *
- * Permission to use, copy, modify and distribute this software and its
- * documentation is hereby granted, provided that both the copyright
- * notice and this permission notice appear in all copies of the
- * software, derivative works or modified versions, and any portions
- * thereof, and that both notices appear in supporting documentation.
- *
- * CARNEGIE MELLON ALLOWS FREE USE OF THIS SOFTWARE IN ITS "AS IS"
- * CONDITION.  CARNEGIE MELLON DISCLAIMS ANY LIABILITY OF ANY KIND FOR
- * ANY DAMAGES WHATSOEVER RESULTING FROM THE USE OF THIS SOFTWARE.
- *
- * Carnegie Mellon requests users of this software to return to
- *
- *  Software Distribution Coordinator  or  software.distribut...@cs.cmu.edu
- *  School of Computer Science
- *  Carnegie Mellon University
- *  Pittsburgh PA 15213-3890
- *
- * any improvements or extensions that they make and grant Carnegie Mellon
- * the rights to redistribute these changes.
- */
-/*
- * Author: David B. Golub, Carnegie Mellon University
- * Date:   7/90
- */
-
-#if MACH_KDB
-
-/*
- * Symbol table routines for a.out format files.
- */
-
-#include 
-#include 
-#include /* data types */
-#include 
-#include 
-#include 
-
-#ifndefDB_NO_AOUT
-
-#include  /* a.out symbol table */
-#include 
-
-#define private static
-
-/*
- * An a.out symbol table as loaded into the kernel debugger:
- *
- * symtab  -> size of symbol entries, in bytes
- * sp  -> first symbol entry
- *...
- * ep  -> last symbol entry + 1
- * strtab  == start of string table
- *size of string table in bytes,
- *including this word
- * -> strings
- */
-
-/*
- * Find pointers to the start and end of the symbol entries,
- * given a pointer to the start of the symbol table.
- */
-#definedb_get_aout_symtab(symtab, sp, ep) \
-   (sp = (struct nlist *)((vm_offset_t *)(symtab) + 1), \
-ep = (struct nlist *)((char *)sp + *((int*)symtab)))
-
-boolean_t
-aout_db_sym_init(
-   char *  symtab, /* pointer to start of symbol table */
-   char *  esymtab,/* pointer to end of string table,
-  for checking - may be rounded up to
-  integer boundary */
-   const char *name,
-   char *  task_addr)  /* use for this task only */
-{
-   struct nlist*sym_start, *sym_end;
-   struct nlist*sp;
-   char *  strtab;
-   int strlen;
-   char *  estrtab;
-
-   db_get_aout_symtab(symtab, sym_start, sym_end);
-
-   strtab = (char *)sym_end;
-   strlen = *(int *)strtab;
-   estrtab = strtab + strlen;
-
-#defineround_to_size(x) \
-   (((vm_offset_t)(x) + sizeof(vm_size_t) - 1) & ~(sizeof(vm_size_t) - 1))
-
-   if (round_to_size(estrtab) != round_to_size(esymtab)) {
-   db_printf("[ %s symbol table not valid ]\n", name);
-   return (FALSE);
-   }
-
-#undef round_to_size
-
-   for (sp = sym_start; sp < sym_end; sp++) {
-   long strx;
-   strx = sp->n_un.n_strx;
-   if (strx != 0) {
-   if (strx > strlen) {
-   db_printf("Bad string table index (%#x)\n", strx);
-   sp->n_un.n_name = 0;
-   continue;
-   }
-   sp->n_un.n_name = strtab + strx;
-   }
-   }
-
-   if (db_add_symbol_table(SYMTAB_AOUT,
-   (char *)sym_start,
-   (char *)sym_end,
-   name,
-   symtab,
-   task_addr))
-   {
-   /* Successfully added symbol table */
-   db_printf("[ preserving %d bytes of %s symbol table ]\n",
-   esymtab - (char *)symtab, name);
-   return TRUE;
-   }
-   else
-   

[PATCH gnumach] memory_object_create_proxy: avoid casting parameters to 32 bits since the types are correct now

[Flavio Cruz]

---
 vm/memory_object_proxy.c | 7 ---
 1 file changed, 7 deletions(-)

diff --git a/vm/memory_object_proxy.c b/vm/memory_object_proxy.c
index 0f1e75e5..57243497 100644
--- a/vm/memory_object_proxy.c
+++ b/vm/memory_object_proxy.c
@@ -155,13 +155,6 @@ memory_object_create_proxy (ipc_space_t space, vm_prot_t 
max_protection,
   if (!IP_VALID(object[0]))
 return KERN_INVALID_NAME;
 
-#ifdef USER32
-  /* FIXME: simplify RPC, fix mig, or add a new VM data type in message.h */
-  *offset &= 0xU;
-  *start &= 0xU;
-  *len &= 0xU;
-#endif
-
   /* FIXME: Support a different offset from 0.  */
   if (offset[0] != 0)
 return KERN_INVALID_ARGUMENT;
-- 
2.39.0

Re: [PATCH] vm_page.c: add missing object lock

[Samuel Thibault]

Applied, thanks!

Etienne Brateau, le mer. 08 févr. 2023 23:54:36 +0100, a ecrit:
> The documentation of vm_page_insert says that the object must be locked.
> Moreover, the unlock call is here but no call was present.
> ---
>  vm/vm_page.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/vm/vm_page.c b/vm/vm_page.c
> index 707be4bb..50916b74 100644
> --- a/vm/vm_page.c
> +++ b/vm/vm_page.c
> @@ -1034,6 +1034,7 @@ vm_page_seg_balance_page(struct vm_page_seg *seg,
>  simple_unlock(>lock);
>  simple_unlock(_page_queue_free_lock);
>  
> +vm_object_lock(object);
>  vm_page_insert(dest, object, offset);
>  vm_object_unlock(object);
>  
> -- 
> 2.39.1
> 
> 

-- 
Samuel
---
Pour une évaluation indépendante, transparente et rigoureuse !
Je soutiens la Commission d'Évaluation de l'Inria.

[PATCH] vm_page.c: add missing object lock

[Etienne Brateau]

The documentation of vm_page_insert says that the object must be locked.
Moreover, the unlock call is here but no call was present.
---
 vm/vm_page.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/vm/vm_page.c b/vm/vm_page.c
index 707be4bb..50916b74 100644
--- a/vm/vm_page.c
+++ b/vm/vm_page.c
@@ -1034,6 +1034,7 @@ vm_page_seg_balance_page(struct vm_page_seg *seg,
 simple_unlock(>lock);
 simple_unlock(_page_queue_free_lock);
 
+vm_object_lock(object);
 vm_page_insert(dest, object, offset);
 vm_object_unlock(object);
 
-- 
2.39.1

[sr #110199] Cross-building of GNU/Hurd and additional packages

[Svante Signell]

Follow-up Comment #33, sr #110199 (project administration):

Hello, this issue seems to have a Closed status. Can somebody open it again?

Thanks!



___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.nongnu.org/

Re: On SO_PEERCRED & SCM_CREDS

[Sergey Bugaev]

Forgot to mention another interesting possibility:

clearly, the auth_{user,server}_authenticate () API has been designed
with io_reauth in mind. The newport being passed from the server to
the client fits the io_reauth model very well, the newport being a
newly authenticated port to the same peropen. But this doesn't work as
well for the SCM_CREDS case. But if we were to add, say,

simpleroutine auth_user_authenticate_inv (
handle: auth_t;
rendezvous: mach_port_send_t;
refport: mach_port_send_t);

routine auth_server_authenticate_inv (
handle: auth_t;
rendezvous: mach_port_send_t;
out refport: mach_port_t;
out euids: idarray_t;
out auids: idarray_t;
out egids: idarray_t;
out agids: idarray_t);

where 'refport' is passed from the user to the server and not the
other way around -- then this would work out nicely in the SCM_CREDS
case.

The user (the first peer) would pass refport = sockaddr, place the
receive right to the rendezvous port into the socket packet, and be
done with it. The server (the other peer) would read this out, get the
user's IDs, compare the refport to the sockaddr, and proceed if they
match. Neither peer would have to wait for the other one.

I'm not saying we _should_ do this, but it really looks like it would work.

Sergey

Re: [gnu-soc] GNU GSOC 2023 application

[Sergey Bugaev]

On Wed, Feb 8, 2023 at 2:45 PM Samuel Thibault  wrote:
> Actually, no: the rustc compiler itself cross-builds fine, it's libstd
> that needs porting, and the gcc front-end uses the rustc libstd too.

Is planning to use the upstream libstd, rather. Currently GCC Rust
cannot even build libcore yet.

Sergey

Re: [gnu-soc] GNU GSOC 2023 application

[Jose E. Marchesi]

> Jose E. Marchesi, le mer. 08 févr. 2023 12:15:31 +0100, a ecrit:
>> As a side note, have you heard of the GCC Rust front-end (under
>> development) that has been recently added to GCC?
>
> Yes.
>
>> It may be relevant to the Hurd.
>
> Actually, no: the rustc compiler itself cross-builds fine, it's libstd
> that needs porting, and the gcc front-end uses the rustc libstd too.

Oh ok.  The runtime is shared.

Re: [gnu-soc] GNU GSOC 2023 application

[Samuel Thibault]

Jose E. Marchesi, le mer. 08 févr. 2023 12:15:31 +0100, a ecrit:
> As a side note, have you heard of the GCC Rust front-end (under
> development) that has been recently added to GCC?

Yes.

> It may be relevant to the Hurd.

Actually, no: the rustc compiler itself cross-builds fine, it's libstd
that needs porting, and the gcc front-end uses the rustc libstd too.

Samuel

Re: [gnu-soc] GNU GSOC 2023 application

[Jose E. Marchesi]

Hi Samuel.

I added the Hurd idea to the page.  Thank you very much.

As a side note, have you heard of the GCC Rust front-end (under
development) that has been recently added to GCC?  It may be relevant to
the Hurd.

> Hello Jose,
>
> - GNU Hurd
> - The GNU Hurd is the GNU project's replacement for the Unix kernel. It
>   is a collection of servers that run on the Mach microkernel to
>   implement file systems, network protocols, file access control, and
>   other features that are implemented by the Unix kernel or similar
>   kernels (such as Linux).
> - https://www.gnu.org/software/hurd/
> - Porting Rust to GNU/Hurd
>
> - The goal of this project is to make the Rust language
> (https://www.rust-lang.org/) available on GNU/Hurd.
>
> The Rust language is being used more and more widely, and notably in
> rather fundamental libraries such as librsvg or python-cryptography. It
> is thus more and more pressing for GNU/Hurd to have a compiler for Rust.
>
> The Rust compiler itself is quite portable, but its runtime library,
> libstd, needs to be ported to the GNU/Hurd system. This essentially
> consists in telling Rust how the standard C library functions can be
> called.
>
> And example of the main part of such port can be seen for the VxWorks
> port:
> https://github.com/rust-lang/libc/blob/master/src/vxworks/mod.rs
>
> The bulk of such a file can be mostly generated from the libc C
> headers thanks to the bindgen tool, it then needs to be cleaned up and
> integrated into the Rust build infrastructure, some preliminary work had
> already been investigated in that part.
>
> A cross-bootstrap from Linux will then need to be achieved to build
> rustc and cargo, and then it will be self-hosted on GNU/Hurd.
>
> - A good level of C programming will be welcome to understand the
> questions of ABI and the libc C functions being bound.
>
> Knowing the Rust language is not required: it can be learnt along the
> way, this can be a good occasion.
>
> - bug-hurd@gnu.org
> - https://darnassus.sceen.net/~hurd-web/community/gsoc/project_ideas/rust/
> https://www.rust-lang.org/
> https://rustc-dev-guide.rust-lang.org/building/how-to-build-and-run.html
>
> Samuel