public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Martin Jambor <mjambor@suse.cz>
To: Juan Scerri <juan.scerri.21@um.edu.mt>
Cc: gcc@gcc.gnu.org
Subject: Re: GSoC (Make cp-demangle non-recursive)
Date: Thu, 07 Apr 2022 17:24:14 +0200	[thread overview]
Message-ID: <ri6mtgwkjc1.fsf@suse.cz> (raw)
In-Reply-To: <CACJSivuQz69tJ_h6uzm85261Yyr8hiQegCLo_5czV1rfEqKWqg@mail.gmail.com>

Hello,

sorry for a late reply.

On Sun, Mar 27 2022, Juan Scerri wrote:
> Hello,
>
> Lately, I have been working on a way to implement recursion on the
> heap to deal with the limits associated with recursion on the
> stack. If a good implementation is reached that should allow us to
> convert the code.
>
> I have implemented the data structure and I have written a simple
> factorial function using the data structure. Currently, no error
> handling is being done.

Good.  Generally something quite similar to what you implemented for the
factorial computation will be needed.  I think that having a function
pointer instead of an enum for work type would make implementation
easier and cleaner (though theoretically less "safe," I guess, so maybe
there is a reason to have enums).  Similarly, I think that rather than
void pointers for "frames", we can use an inheritance-in-C approach,
i.e. to have different kinds of frames all have the first field of the
same type that will specify what kind of "frame" the rest are - very
much like all tree_<something> structures in gcc/tree-core.h have
tree_base as the first field, which specifies what the rest of the big
structure looks like.  But those are implementation details that are
easy to change.

>
> Any guidance on what is expected with regards to error handling and
> how errors should be dealt with (push up the call stack or terminate
> the program?) would be greatly appreciated.

In case of error you need to deallocate all allocated memory and
d_demangle will then report error as specified in the function
description and return.  You do not want to terminate the program for
non-catastrophic reasons because the demangler can be called as a library.

Deallocating memory will probably be easier if you do not call malloc
for every "frame" but rather allocate them from some bigger continuous
buffers.  But an initial implementation can definitely just go over the
stack and free everything manually, these are things that can be tweaked
after the core work is done.

>
> Moreover, any feedback on the current way the data structure
> is implemented and the code used to implement the simple factorial function
> would be appreciated.
>
> The current issue I have with this method is that it is really complex to
> write a
> function using the data structure to implement recursion on the heap. Plus
> it requires
> dealing and understanding the control flow of the function very well.

Right, code re-structuring might sometimes get ugly.  I do not think it
can be completely avoided but with consistent style, intelligent
division of code to different functions and good naming and comments, I
believe the issue can be mitigated to a reasonable level.

I think you understand the core issue of the project, you may now want
to look at the demangler and think about how to incrementally.  In the
past, we though that the first function to look at could be d_parmlist
to break the recursive cycle of:

d_parmlist -> cplus_demangle_type -> d_function_type -> d_parmlist.

d_parmlist would use the new scheme, but would recursively call into the
not-yet-converted other functions.  But that is just a suggestion.

Good luck and sorry for the late response again,

Martin

  reply	other threads:[~2022-04-07 15:24 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-27 12:21 Juan Scerri
2022-04-07 15:24 ` Martin Jambor [this message]
  -- strict thread matches above, loose matches on Subject: below --
2022-02-26 10:34 Juan Scerri
2022-02-26 16:31 ` Juan Scerri
2022-03-02 18:37 ` Martin Jambor
     [not found]   ` <CACJSivvYgNG+C2Y5ph=4yv5y0iaV+Ak7=vh3FGD7W6eQADxk9w@mail.gmail.com>
2022-03-09 16:15     ` Martin Jambor

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=ri6mtgwkjc1.fsf@suse.cz \
    --to=mjambor@suse.cz \
    --cc=gcc@gcc.gnu.org \
    --cc=juan.scerri.21@um.edu.mt \
    /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).