public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Simon Marchi <simon.marchi@polymtl.ca>
To: Bartosz Nitka <niteria@gmail.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH v3 1/1] Don't rewind PC for GHC generated frames
Date: Mon, 12 Feb 2018 15:44:00 -0000	[thread overview]
Message-ID: <8c6e36c70ca0ce3f0980971bfa50c160@polymtl.ca> (raw)
In-Reply-To: <20180204000647.19188-2-niteria@gmail.com>

Hi Bartosz,

Thanks for the additional info in the commit message, it's very useful.

I hoped there would be some comments from others.  In particular, is 
anybody able to tell if adding a call to find_pc_compunit_symtab in 
get_frame_address_in_block is a performance concern?  How frequently is 
get_frame_address_in_block called, and how costly is 
find_pc_compunit_symtab to call?

I noted two small comments, no need to submit another version just for 
that, we can fix it before pushing.  However, please tell me if you are 
fine with my suggestion below.

> diff --git a/gdb/frame.c b/gdb/frame.c
> index 1384ecca4f..9ff0dcb130 100644
> --- a/gdb/frame.c
> +++ b/gdb/frame.c
> @@ -2458,7 +2458,14 @@ get_frame_address_in_block (struct frame_info
> *this_frame)
>        && (get_frame_type (this_frame) == NORMAL_FRAME
>  	  || get_frame_type (this_frame) == TAILCALL_FRAME
>  	  || get_frame_type (this_frame) == INLINE_FRAME))
> -    return pc - 1;
> +    {
> +      /* GHC intermixes metadata (info tables) with code, going back 
> is
> +         guaranteed to land us in the metadata.  */

I think the main reason why we don't want to subtract one is that the 
compiler generates return addresses that refer to the jump instruction 
that made the "call", and not to the instruction after, as with the call 
instruction.  I think the comment should reflect that.  What about:

/* GHC (Glasgow Haskell Compiler) uses jump and manages its own stack 
rather than
    using the call instruction.  The return address it generates is that 
of the
    jump instruction, not the following instruction.  It is therefore not
    necessary to go back one byte.  It would not be desirable anyway, 
because it
    intermixes metadat (info tables) with code, so going back would land 
us in the
    metadata.  */

> +      struct compunit_symtab *cust = find_pc_compunit_symtab (pc);
> +      if (cust != NULL && cust->producer_is_ghc)
> +        return pc;
> +      return pc - 1;
> +    }
> 
>    return pc;
>  }
> diff --git a/gdb/symtab.h b/gdb/symtab.h
> index f9d52e7697..c164e5ba5f 100644
> --- a/gdb/symtab.h
> +++ b/gdb/symtab.h
> @@ -1432,6 +1432,9 @@ struct compunit_symtab
>       instruction).  This is supported by GCC since 4.5.0.  */
>    unsigned int epilogue_unwind_valid : 1;
> 
> +  /* This CU was produced by Glasgow Haskell Compiler */

The comment should end with a period and two spaces.

Thanks,

Simon

  parent reply	other threads:[~2018-02-12 15:44 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-04  0:07 [PATCH v3 0/1] " Bartosz Nitka
2018-02-04  0:07 ` [PATCH v3 1/1] " Bartosz Nitka
2018-02-12 12:35   ` Bartosz Nitka
2018-02-12 15:44   ` Simon Marchi [this message]
2018-02-19 13:10     ` Bartosz Nitka
2018-02-19 17:02       ` Simon Marchi
2018-02-12 13:50 ` [PATCH v3 0/1] " Yao Qi
2018-02-12 14:14   ` Bartosz Nitka
2018-02-12 14:42     ` Yao Qi
2018-02-19 13:27       ` Bartosz Nitka

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8c6e36c70ca0ce3f0980971bfa50c160@polymtl.ca \
    --to=simon.marchi@polymtl.ca \
    --cc=gdb-patches@sourceware.org \
    --cc=niteria@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).