[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Tinycc-devel] Flushing caches before -running a program

From: Thomas Preud'homme
Subject: Re: [Tinycc-devel] Flushing caches before -running a program
Date: Tue, 12 Mar 2013 11:26:15 +0100
User-agent: KMail/1.13.7 (Linux/3.2.0-4-amd64; KDE/4.8.4; x86_64; ; )

Le mardi 12 mars 2013 10:43:11, grischka a écrit :
> +    __clear_cache(prog_main, prog_main + get_code_size(s1));
> "prog_main + get_code_size(s1)" is generally not a meaningful
> expression as prog_main may not be first in code.


> Also this doesn't flush data caches if that is what you want (as
> you wrote). 

Why not? According to [1], it does:

[1] http://blogs.arm.com/software-enablement/141-caches-and-self-modifying-

The code generated by tcc will go through the data caches and this function 
will flush them while at the same time invalidating the corresponding entries 
in the instruction cache to make sure that the instructions will be fetched 
from memory before executing them.

> Also:
>  > if (s->phase)
> Not a good name.  There are more than a few "phases" going on in
> tinycc.

I know. I used this name so that we could distinguish more phases in the 
future without having to change the name.

>  > return text_section->data_offset;
> Why do you need an extra function to return text_section->data_offset?

I wanted to avoid text_section from being public.

> > I then
> > quickly started working on a patch but I needed to know the size of the
> > code that was compiled by tcc. So I added a function to return this in
> > tccgen.c but I'm not sure it's ok. It adds another public function and
> > it's the only function that take a TCCState argument in that file.
> tcc_relocate(s, NULL) already returns the code+data size.
> However I'd suggest not to add another API but instead integrate
> this into tcc_relocate.  There is already
>       set_pages_executable(ptr, length);

Great, that's exactly what I was looking for. I didn't like adding an API 
neither and that's why I sent this email.

> Such if you only want to flush instruction memory, you could just add
>       __clear_cache(ptr, lenght);
> into this function.  Or just flush the entire allocated memory at the
> end of tcc_relocate_ex if you want both data+instructions.

It's only about instructions since data cache itself is consistent. There is 
no problem accessing data that was written previously. The problem is that the 
instruction cache and the data caches are not consistent. If I write an 
instruction in the data cache (which is what happens when you write something 
in memory) and then tries to jump at this address, the instruction cache won't 
load the instruction from the data cache but from memory. Hence you need to 
flush the data cache before. Corresponding entries need to be invalidated from 
instruction cache in case the load was already performed (shouldn't be the 
case for us though).

> --- grischka

Thanks a lot grischka, you answered my questions perfectly.


Attachment: signature.asc
Description: This is a digitally signed message part.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]