public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Andre Groenewald <adres.is.gevat@gmail.com>
To: Andre Groenewald <adres.is.gevat@gmail.com>, gcc@gcc.gnu.org
Subject: Re: Fwd: GCC front end and GCC internals
Date: Fri, 31 Mar 2017 06:56:00 -0000	[thread overview]
Message-ID: <CAHDABsepWkCPwGDowEDAAwFSbx4b3rb8p_s86BbeuLu3Dco4GA@mail.gmail.com> (raw)
In-Reply-To: <20170330140310.d3b4rigu23qz7xyn@virgil.suse.cz>

Sorry about the fwd in the description.

This is my implementation:

fnDeclType = build_function_type_array(integer_type_node,
argVect.NumOfItems, parmTypes);
tree fnDecl = build_fn_decl(identifier->Str, fnDeclType);
DECL_EXTERNAL(fnDecl) = 1;
fnAddr = build1(ADDR_EXPR, build_pointer_type(fnDeclType), fnDecl);
funcStmt = build_call_array_loc(identifier->Locus, integer_type_node,
fnAddr, argVect.NumOfItems, parms);

It works perfectly for calling functions. Not sure if it is the
preferred way to do it, but gets the job done.

> ...calling conventions (and anything defied in an Application Binary
> Interface) is of course dependant on the architecture and operating
> system you are compiling for, so you need to tell us that.

I am not really that interested in calling convention. It only gets me
to realise that methods (non static) and functions are not the same,
even on a binary level.
If I do it "correctly" on generic level GCC will be taking care of everything.
But for what it's worth here is my specs: Intel x86_64, Ubuntu 16.04
LTS 64bit, gcc 5.2, compiled with g++

> type of the function being called is METHOD_TYPE and not FUNCTION_TYPE
> (but that is actually good for consistency on any platform).  Except
> for static methods, those are functions in gcc internals.

My implementation generates a FUNCTION_TYPE, is there an easy way to
turn it into a METHOD_TYPE, like a single tree call.
That will take care of consistency.

Regards,
André


On Thu, Mar 30, 2017 at 4:03 PM, Martin Jambor <mjambor@suse.cz> wrote:
> Hello,
>
> I am not sure if I can help you but...
>
> On Thu, Mar 30, 2017 at 08:05:07AM +0200, Andre Groenewald wrote:
>> I am discovering the awesome world of GCC internals. I managed to
>> develop a basic front end. It can call internal and external functions
>> and link with standard libraries. All is good.
>>
>> The hunger for more does not end. I want to call c++ libraries and
>> interact with c++ objects.
>>
>> My starting point was to call a test c++ method. I created a test c++
>> class with a test method/function. It was compiled into a library. The
>> library was tested with c++ program and it worked. I manage to call it
>> from my front end, but the parameter I passed was messed up. It was
>> some random value every time I called the method.
>>
>> I disassembled my program and the test c++ program, then compared the
>> two. I found that it uses a different register as in the case when
>> calling a standard c style function.
>>
>> It seems that methods are different in the calling convention than
>> normal functions, which is fine. All that I need to do is set correct
>> tree property and every will work, right? The question is what tree
>> property should I set, which macro should I use to set that property?
>>
>
> ...calling conventions (and anything defied in an Application Binary
> Interface) is of course dependant on the architecture and operating
> system you are compiling for, so you need to tell us that.
>
> Having said that, the only target that I know about that uses
> different argument passing for methods and for functions is
> i686-mingw32 (MS Windows).  If that is your case, make sure that the
> type of the function being called is METHOD_TYPE and not FUNCTION_TYPE
> (but that is actually good for consistency on any platform).  Except
> for static methods, those are functions in gcc internals.
>
> If this does not help, you'll need to provide much more details about
> your whole setup.
>
> Martin
>

  reply	other threads:[~2017-03-31  6:56 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CAHDABscuC-y=FS6SPJ1L3LG2oasHP-NCqFpwGKaUNUBMg6aTDw@mail.gmail.com>
2017-03-30  6:05 ` Andre Groenewald
2017-03-30 14:03   ` Martin Jambor
2017-03-31  6:56     ` Andre Groenewald [this message]
2017-03-31  8:00       ` Martin Jambor
2017-03-31 14:40         ` Andre Groenewald

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=CAHDABsepWkCPwGDowEDAAwFSbx4b3rb8p_s86BbeuLu3Dco4GA@mail.gmail.com \
    --to=adres.is.gevat@gmail.com \
    --cc=gcc@gcc.gnu.org \
    /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).