This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [lto] PATCH: Add support for referencing types from function bodies


Mark Mitchell wrote:
> Kenneth Zadeck wrote:
>
>> I think that if you want to teach the gimplifier to do this, that is a
>> great way to get rid of them for any downstream part of the compiler.  I
>> have never touched the gimplifier and really do not want to make this
>> yet another learning experience, dwarf and gimple have been enough for
>> this project.
>
> OK, we can cross that bridge as we come to it.
>
> Let's talk about how we're going to wire up the reading side of
> things.     I suggest that you provide this routine:
>
>   void lto_read_function_body (lto_info_fd *fd,
>                                lto_context *context,
>                                tree fn,
>                                const void *data);
>
> Here, FD and CONTEXT are parameters that you will need to pass back to
> the routines that resolve references to global data from within the
> function body.  (These are not global variables because we want to
> support concurrency and/or re-entrancy.)  Otherwise, you won't make
> any use of them.  FN is the FUNCTION_DECL for the function whose body
> you're about to read.  DATA points to the memory-mapped data for the
> function, as you wrote it out to the object file.
>
> So, by the time this function is called, the FUNCTION_DECL will
> already have been set up and mapping/un-mapping the data will be the
> caller's responsibility.  This function's job is to set up
> DECL_SAVED_TREE and DECL_INITIAL for the FUNCTION_DECL, set flags on
> the FUNCTION_DECL, etc.  This function does not need to actually pass
> the function off to the middle-end; this function is just for reading
> data from the object file.
>
> How does that sound?
>
What do you mean by DATA?  Is DATA a pointer to the function info that I
wrote or is data a pointer to the file that contains the function info
and I need to talk to the elf at the beginning of the file myself to
find the offset where my data starts.  I prefer the former since the
piece that I do not understand, is how I am supposed to find the section
for the specific function.  I have not started looking at elf yet so I
do not know if this is easy or hard. 

Obviously I am not supposed to know what is inside context, but I assume
that this is a different context than I am writing for each reference to
the global symbol table. 

But aside from that, this seems like something that I can live with. 

Kenny


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]