Hurd: Make gdb/reply_mig_hack.awk script compatible to "mawk" (was: [RFC] GDB Hurd Fixes)

2016-01-12 Thread Thomas Schwinge
Hi!

On Mon, 6 Jan 2014 17:56:27 +0100, I wrote:
> On Fri, 20 Sep 2013 11:17:08 -0400, David Michael  
> wrote:
> > mig has stopped using the "auto" keyword in its output.[1]
> > Without that keyword, gdb/reply_mig_hack.awk fails to match a
> > necessary pattern and outputs a bad gdb/process_reply_S.c file.

> commit d8131897afba28934ced82c507114123027a40f8
> Author: Thomas Schwinge 
> Date:   Mon Jan 6 15:56:33 2014 +0100
> 
> Hurd: Adapt to changed MIG output.
> 
>   gdb/
>   * reply_mig_hack.awk: Don't expect to see the auto keyword.
> 
> Based on patch by David Michael .
> 
> diff --git gdb/reply_mig_hack.awk gdb/reply_mig_hack.awk
> index 97e080f..e137a27 100644
> --- gdb/reply_mig_hack.awk
> +++ gdb/reply_mig_hack.awk
> @@ -78,9 +78,9 @@ parse_phase == 4 {
>print; next;
>  }
>  
> -parse_phase == 5 && /^[ \t]*(auto|static) const mach_msg_type_t/ {
> +parse_phase == 5 && /^[ \t]*(auto |static |)const mach_msg_type_t/ {
># The type check structure for an argument.
> -  arg_check_name[num_checks] = $4;
> +  arg_check_name[num_checks] = $(NF - 2);
>num_checks++;
>print; next;
>  }

Turns out that the "mawk" AWK implementation doesn't like that regular
expression:

mawk: [...]/gdb/reply_mig_hack.awk: line 98: regular expression compile 
failed (missing operand)

I didn't check it against the AWK language definition, but instead just
made the gdb/reply_mig_hack.awk script compatible to "mawk"; pushed:

commit 5eddd57823971bdb54f957d10c11ff3fc9f97b1e
Author: Thomas Schwinge 
Date:   Tue Jan 12 12:53:09 2016 +0100

Hurd: Make gdb/reply_mig_hack.awk script compatible to "mawk"

The "mawk" AWK implementation did't like that regular expression:

mawk: [...]/gdb/reply_mig_hack.awk: line 98: regular expression compile 
failed (missing operand)

gdb/
* reply_mig_hack.awk: Rewrite one regular expression.
---
 gdb/ChangeLog  | 4 
 gdb/reply_mig_hack.awk | 2 +-
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git gdb/ChangeLog gdb/ChangeLog
index 099a9a9..73b001c 100644
--- gdb/ChangeLog
+++ gdb/ChangeLog
@@ -1,3 +1,7 @@
+2016-01-12  Thomas Schwinge  
+
+   * reply_mig_hack.awk: Rewrite one regular expression.
+
 2016-01-11  Mike Frysinger  
 
* acinclude.m4: Include new warning.m4 file.
diff --git gdb/reply_mig_hack.awk gdb/reply_mig_hack.awk
index 1e2387a..e4c513b 100644
--- gdb/reply_mig_hack.awk
+++ gdb/reply_mig_hack.awk
@@ -95,7 +95,7 @@ parse_phase == 4 {
   print; next;
 }
 
-parse_phase == 5 && /^[ \t]*(auto |static |)const mach_msg_type_t/ {
+parse_phase == 5 && /^[ \t]*(auto |static )?const mach_msg_type_t/ {
   # The type check structure for an argument.
   arg_check_name[num_checks] = $(NF - 2);
   num_checks++;


Grüße
 Thomas


signature.asc
Description: PGP signature


Re: [RFC] GDB Hurd Fixes

2014-05-06 Thread Thomas Schwinge
Hi!

On Mon, 5 May 2014 23:49:33 -0400, Samuel Bronson naes...@gmail.com wrote:
 On 1/6/14, Thomas Schwinge tho...@codesourcery.com wrote:
  Sorry for the delay, and thanks for the patches you posted.  Here are
  three patches, based on yours, that I intend to apply if there are no
  further comments.
 
 What happened to applying these?

They got pushed as commits bae8023e39868ab2065ff05be61e151b3c082492,
d47642c93dda6344af12458e4e26587f3353fb44, and
3398af6aa352b0611bc9d66aed72080a876e42d4.

 (I'd like to cherrypick them for the
 Debian package.)

Thanks!  I think you'll also want to pick commit
c82f56d9d760a9b4034eeaac44f2f0fa5779ff69,
http://news.gmane.org/find-root.php?message_id=%3C8738kyi30l.fsf%40kepler.schwinge.homeip.net%3E.


Grüße,
 Thomas


pgpaZX5JYFYlP.pgp
Description: PGP signature


Re: [RFC] GDB Hurd Fixes

2014-05-05 Thread Samuel Bronson
On 1/6/14, Thomas Schwinge tho...@codesourcery.com wrote:
 Hi!

 Sorry for the delay, and thanks for the patches you posted.  Here are
 three patches, based on yours, that I intend to apply if there are no
 further comments.

What happened to applying these? (I'd like to cherrypick them for the
Debian package.)



Re: [RFC] GDB Hurd Fixes

2013-09-20 Thread Pedro Alves
On 09/20/2013 01:43 AM, David Michael wrote:
 Hi,
 
 (Copying gdb-patches this time.)

But, we're missing all the context on the gdb-patches@ side.

 
 Here is an updated patch to successfully build GDB after today's
 Hurd/mig changes.

-- 
Pedro Alves




Re: [RFC] GDB Hurd Fixes

2013-09-20 Thread Thomas Schwinge
Hi!

On Fri, 20 Sep 2013 09:47:21 +0100, Pedro Alves pal...@redhat.com wrote:
 On 09/20/2013 01:43 AM, David Michael wrote:
  [Hurd/GDB issue]
 
 But, we're missing all the context on the gdb-patches@ side.

I'll have a look.


Grüße,
 Thomas


pgpw8Re4jp6nN.pgp
Description: PGP signature


Re: [RFC] GDB Hurd Fixes

2013-09-20 Thread David Michael
Hi,

On Fri, Sep 20, 2013 at 4:47 AM, Pedro Alves pal...@redhat.com wrote:
 On 09/20/2013 01:43 AM, David Michael wrote:
 (Copying gdb-patches this time.)
 But, we're missing all the context on the gdb-patches@ side.

Sorry about that--here's an explanation of the problems in GDB's build
process with current Hurd:

First, mig has stopped using the auto keyword in its output.[1]
Without that keyword, gdb/reply_mig_hack.awk fails to match a
necessary pattern and outputs a bad gdb/process_reply_S.c file.  The
first change I made adds a new pattern to the script in addition to
the old one, so it should work with both old and new mig binaries.

Next, new function definitions were added (then renamed) in
hurd/process_reply.defs.[2]  In the generated
gdb/process_reply_S.raw, some of the new functions match patterns in
gdb/reply_mig_hack.awk in a different order than expected, producing
bad output again.  The second change I made to the script ensures a
necessary definition is found before writing output.  (It may be
preferable to add a parse_phase = 6 instead.)

Also because of [2], linking fails due to missing some new functions
in gdb/process_reply_S.c.  I just extended the way other unused
functions from process_reply.defs were handled previously in
gdb/gnu-nat.c.

Thanks.

David

[1] 
http://git.savannah.gnu.org/cgit/hurd/mig.git/commit/?id=b53836447df7230cd5665a7ccabd2a6e1a6607e5
[2] 
http://git.savannah.gnu.org/cgit/hurd/hurd.git/commit/?id=e19cc6184fb99394845d56e6e915fea9805e5c28



Re: [RFC] GDB Hurd Fixes

2013-09-19 Thread David Michael
Hi,

(Copying gdb-patches this time.)

Here is an updated patch to successfully build GDB after today's
Hurd/mig changes.

The awk script changes handle the auto keyword being dropped from
mig output, and that an #if TypeCheck line appears before
arg_check_name is defined in some new functions.

The gnu-nat.c changes define functions for the new process_reply.defs entries.

I'd appreciate any feedback or suggestions for getting GDB building on
current Hurd again.

Thanks.

David


--- gdb/reply_mig_hack.awk2013-01-01 01:32:50.0 -0500
+++ gdb/reply_mig_hack.awk2013-01-01 01:32:50.0 -0500
@@ -85,13 +85,20 @@ parse_phase == 5  /^[ \t]*(auto|static
   print; next;
 }

+parse_phase == 5  /^[ \t]*const mach_msg_type_t/ {
+  # The type check structure for an argument.
+  arg_check_name[num_checks] = $3;
+  num_checks++;
+  print; next;
+}
+
 parse_phase == 5  /^[ \t]*mig_external kern_return_t/ {
   # The declaration of the user server function for this rpc.
   user_function_name = $3;
   print; next;
 }

-parse_phase == 5  /^#if[ \t]TypeCheck/ {
+parse_phase == 5  /^#if[ \t]TypeCheck/  num_checks  0 {
   # The first args type checking statement; we need to insert our chunk of
   # code that bypasses all the type checks if this is an error return, after
   # which we're done until we get to the next function.  Handily, the size
--- gdb/gnu-nat.c2013-01-01 01:32:44.0 -0500
+++ gdb/gnu-nat.c2013-01-01 01:32:44.0 -0500
@@ -1902,6 +1902,142 @@ S_proc_getmsgport_reply (mach_port_t rep
   return ill_rpc (S_proc_getmsgport_reply);
 }

+error_t
+S_proc_pid2task_reply (mach_port_t reply, error_t err, mach_port_t task)
+{
+  return ill_rpc (S_proc_pid2task_reply);
+}
+
+error_t
+S_proc_task2pid_reply (mach_port_t reply, error_t err, pid_t pid)
+{
+  return ill_rpc (S_proc_task2pid_reply);
+}
+
+error_t
+S_proc_task2proc_reply (mach_port_t reply, error_t err, mach_port_t proc)
+{
+  return ill_rpc (S_proc_task2proc_reply);
+}
+
+error_t
+S_proc_proc2task_reply (mach_port_t reply, error_t err, mach_port_t task)
+{
+  return ill_rpc (S_proc_proc2task_reply);
+}
+
+error_t
+S_proc_pid2proc_reply (mach_port_t reply, error_t err, mach_port_t proc)
+{
+  return ill_rpc (S_proc_pid2proc_reply);
+}
+
+error_t
+S_proc_getprocinfo_reply (mach_port_t reply, error_t err, int flags,
+  procinfo_t procinfo, mach_msg_type_number_t piCnt,
+  data_t threadwaits, mach_msg_type_number_t twCnt)
+{
+  return ill_rpc (S_proc_getprocinfo_reply);
+}
+
+error_t
+S_proc_getprocargs_reply (mach_port_t reply, error_t err,
+  data_t procargs, mach_msg_type_number_t procargsCnt)
+{
+  return ill_rpc (S_proc_getprocargs_reply);
+}
+
+error_t
+S_proc_getprocenv_reply (mach_port_t reply, error_t err,
+ data_t procenv, mach_msg_type_number_t procenvCnt)
+{
+  return ill_rpc (S_proc_getprocenv_reply);
+}
+
+error_t
+S_proc_getloginid_reply (mach_port_t reply, error_t err, pid_t login_id)
+{
+  return ill_rpc (S_proc_getloginid_reply);
+}
+
+error_t
+S_proc_getloginpids_reply (mach_port_t reply, error_t err,
+   pidarray_t pids, mach_msg_type_number_t pidsCnt)
+{
+  return ill_rpc (S_proc_getloginpids_reply);
+}
+
+error_t
+S_proc_getlogin_reply (mach_port_t reply, error_t err, string_t logname)
+{
+  return ill_rpc (S_proc_getlogin_reply);
+}
+
+error_t
+S_proc_getsid_reply (mach_port_t reply, error_t err, pid_t sid)
+{
+  return ill_rpc (S_proc_getsid_reply);
+}
+
+error_t
+S_proc_getsessionpgids_reply (mach_port_t reply, error_t err,
+  pidarray_t pgidset, mach_msg_type_number_t psCnt)
+{
+  return ill_rpc (S_proc_getsessionpgids_reply);
+}
+
+error_t
+S_proc_getsessionpids_reply (mach_port_t reply, error_t err,
+ pidarray_t pidset, mach_msg_type_number_t psCnt)
+{
+  return ill_rpc (S_proc_getsessionpids_reply);
+}
+
+error_t
+S_proc_getsidport_reply (mach_port_t reply, error_t err, mach_port_t sessport)
+{
+  return ill_rpc (S_proc_getsidport_reply);
+}
+
+error_t
+S_proc_getpgrp_reply (mach_port_t reply, error_t err, pid_t pgrp)
+{
+  return ill_rpc (S_proc_getpgrp_reply);
+}
+
+error_t
+S_proc_getpgrppids_reply (mach_port_t reply, error_t err,
+  pidarray_t pidset, mach_msg_type_number_t pidsetCnt)
+{
+  return ill_rpc (S_proc_getpgrppids_reply);
+}
+
+error_t
+S_proc_get_tty_reply (mach_port_t reply, error_t err, mach_port_t tty)
+{
+  return ill_rpc (S_proc_get_tty_reply);
+}
+
+error_t
+S_proc_getnports_reply (mach_port_t reply, error_t err,
+mach_msg_type_number_t nports)
+{
+  return ill_rpc (S_proc_getnports_reply);
+}
+
+error_t
+S_proc_is_important_reply (mach_port_t reply, error_t err, boolean_t essential)
+{
+  return ill_rpc (S_proc_is_important_reply);
+}
+
+error_t
+S_proc_get_code_reply (mach_port_t reply, error_t err,
+   vm_address_t start_code,