tinycc-devel
[Top][All Lists]
Advanced

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

Re: [Tinycc-devel] libtcc API v.s. global state v.s. tcc state


From: egodust
Subject: Re: [Tinycc-devel] libtcc API v.s. global state v.s. tcc state
Date: Sun, 20 Apr 2008 19:33:35 +0100

Heyas,

On Sun, Apr 20, 2008 at 7:10 PM, grischka <address@hidden> wrote:
>
>  Ah, okay. I thought you wanted to copy all the section data into one
>  single piece of flat memory, like:
>
>     |<----text----><--data--><---bss--->|
>
>  This to free is plain easy. It is (moderately) more complex to
>  make, though.

I just wanted the compiler output :) i.e. stop it being free()'d.
>
>  As to your patch, fine, but it still raises a question: Why do we
>  move sections into a new structure TCCBinary plus need an extra
>  destructor, instead to just keep TCCState itself and use tcc_delete
>  as it's meant to work obviously?

That's how I thought it should work, but it does not, because:

1. tcc_new() MUST be matched by a tcc_delete() that share the same
sections, i.e. no mixing of different states, only ONE state is
allowed to exist at a time because of global copies.

2. tcc_delete() frees the created binary.

3. There are too many global copies :)

So imagine you create "foo.c" using tcc_new(), you can not call
tcc_new() again, without calling tcc_delete() and tcc_delete() will
delete your binary! so how can you (a) keep it the binary and (b) free
the compiler?

There are two solutions, 1. fix up all the globals used, or.. 2. just
get the binary that you want and delete the rest.

For example, tcc_new() does:

    symtab_section = new_symtab(s, ".symtab", SHT_SYMTAB, 0,
                                ".strtab",
                                ".hashtab", SHF_PRIVATE);

symtab_section is a global

tcc_delete() does:

 free_section(symtab_section->hash);

So because of globals, tcc_new() and tcc_delete() must MATCH, you
can't call tcc_delete() afterwards, because tcc_new() overrides
globals.

There is also, a "tcc_state" marked by // XXX: must get rid of this ASAP, hah

So to recap, you can only have one compiler state at a time, there is
"output to file" functions, but not "retain in memory and free later"
functions.

>
>  Okay, there is some global data that we must clear before we can
>  do another compilation, and this happens in tcc_delete currently,
>  so we need to call tcc_delete before we can create a new state.
>
>  But I mean, it doesn't need to be like that. We could as well clear
>  the global data from elsewhere, so we can do new compilation, and
>  still can run old states.
>
>  What do you think?

Sure, but libtcc passes around global data that is shared with ONE
state. I only wanted the binary to stay in memory, if you don't like
the APIs (i.e. the extra free), feel free to suggest something else :)

I just didn't want to complicate the design.

>  --- grischka

Kind Regards,
Sam




reply via email to

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