mobi phil | 18 Apr 13:17 2014

c extensions

Hi,


I know that this topic was here few times, last time I came with some questions.

The goal of this email is both to purpose some simple tcc "meta" extension and to ask 
some further help to implement what I need. 

My intention is to extend C with some features for object (oriented) programming. 
In my previous email about the topic I mentioned that I wanted to implement those
extensions with macros. Though I invested a lot of time, I realized that it was rather 
a stoic exercise and with the macros will be impossible to implement more powerful
constructs like type checking.

After lot of brainstorming, I have a better understanding of what extensions I would like 
to have and how I want to implement them. 

I will basically need 4 constructs:

1. a struct like construct, "black". This is the blackbox of the object. This will be mainly
defined in the source file and holds private objects/members. So far did not find 
a better name. One candidate would be "implementation", but it is also not really
the implementation etc.

example:

black MyType
{
   type1 member1;
   type2 member2;
   type3 member3;
};

2. a struct like construct, "white". Again, did not find a better name, "interface" could have
been a candidate, but the real interface to the object will be the virtual methods declared
inside the "white" block + the static methods that are defined outside of the block.

white MyType: Object /* inheritance, though there will be no public/private keywoards for the moment */
{
   type1 aVirtualMethod();
   
   type1 member1; /* this is the declaration of on accessor that will be "bound" to the one with 
  same name from the /*black*/
}

3. a method declaration and definiton. This will be similar to the C++ method definition.

/* in the header file */
type1 MyType:.aNonVirtualMethod();

/* later in the implementation file */
type1 MyType:.aNonVirtualMethod();

note here the usage of the ":." instead of "::" as the semantic is a bit different than in C++

4. method call

type1 object;
object..aVirtualMethod();

the token here is ".." instead of "." or "->"
This is again has different semantics. But would not bother with details for the moment. 

Further new constructs are in my mind for fibers, continuations (yes they will be different) and and.
Decided to call this "babel C", so files will probably have extension bh/bc (header/implementation)

The bc file will be translated into pure C by the modified tcc. A construct like 1. will be translated into
a C struct with some additional part etc + some glue code. (Will not go into details, but will publish soon the details). 
Construct 2 will be also translated into a struc + some glue code, the same with 3. and 4.

I studied the tcc parser and compiler bit more in depth. Found more or less where I should patch. I kept things easy,
(you remember wanted to use some special syntax with <at>  etc. etc.), so that my stuff fits easyl
into the parsers logic. 

What I need now and this is the minimum that would be probably nice to see it going upstream. 
My first naiv approach wast to save a pointer in the input buffer and:
-> anything that is normal C syntax, after successful parsing of a declaration or part of a declaration,
send the input to the output
-> anything that is syntax extension, fill in a kind of template and send the result to the output.
This task became though a bit complex for me due to the pre-processing. Got a bit lost with token managemnt,
but probably after further hours could find the solution. Though some hints would be welcome.

I got the suggestion to separate the code from original tcc, keep the parser and implement my code generation.
Not sure that this would make my life easier. Do not think this is a good idea as the assembly code generation 
bits would not disturb me (the part that would be redundant for me).

My own first question seems to be confusing as it is not easy to ask it :)... I am rather expecting some hints..
The second question if you could suggest some basic changes in the parser and supporting code that 
would make life easier to implement such extensions for code generation.

thanks a lot,
mobi phil
<div><div dir="ltr">Hi,<div><br></div>
<div><br></div>
<div>I know that this topic was here few times, last time I came with some questions.</div>
<div><br></div>
<div>The goal of this email is both to purpose some simple tcc "meta" extension and to ask&nbsp;</div>
<div>some further help to implement what I need.&nbsp;</div>
<div><br></div>
<div>My intention is to extend C with some features for object (oriented) programming.&nbsp;<br>
</div>
<div>In my previous email about the topic I mentioned that I wanted to implement those</div>
<div>extensions with macros. Though I invested a lot of time, I realized that it was rather&nbsp;</div>
<div>a stoic exercise and with the macros will be impossible to implement more powerful</div>
<div>constructs like type checking.</div>
<div><br></div>
<div>After lot of brainstorming, I have a better understanding of what extensions I would like&nbsp;</div>
<div>to have and how I want to implement them.&nbsp;</div>
<div><br></div>
<div>I will basically need 4 constructs:</div>
<div><br></div>
<div>1. a struct like construct, "black". This is the blackbox of the object. This will be mainly</div>
<div>defined in the source file and holds private objects/members. So far did not find&nbsp;</div>
<div>a better name. One candidate would be "implementation", but it is also not really</div>
<div>the implementation etc.</div>
<div><br></div>
<div>example:</div>
<div><br></div>
<div>black MyType</div>
<div>{</div>
<div>
&nbsp; &nbsp;type1 member1;</div>
<div>&nbsp; &nbsp;type2 member2;</div>
<div>&nbsp; &nbsp;type3 member3;</div>
<div>};</div>
<div><br></div>
<div>2. a struct like construct, "white". Again, did not find a better name, "interface" could have</div>
<div>been a candidate, but the real interface to the object will be the virtual methods declared</div>
<div>inside the "white" block + the static methods that are defined outside of the block.</div>
<div><br></div>
<div>white MyType: Object /* inheritance, though there will be no public/private keywoards for the moment */</div>
<div>{</div>
<div>&nbsp; &nbsp;type1 aVirtualMethod();</div>
<div>&nbsp; &nbsp;</div>
<div>&nbsp; &nbsp;type1 member1; /* this is the declaration of on accessor that will be "bound" to the one with&nbsp;</div>
<div>&nbsp; same name from the /*black*/</div>
<div>}</div>
<div><br></div>
<div>3. a method declaration and definiton. This will be similar to the C++ method definition.</div>
<div><br></div>
<div>/* in the header file */</div>
<div>
type1 MyType:.aNonVirtualMethod();</div>
<div><br></div>
<div>/* later in the implementation file */</div>
<div>type1 MyType:.aNonVirtualMethod();</div>
<div><br></div>
<div>note here the usage of the ":." instead of "::" as the semantic is a bit different than in C++</div>
<div><br></div>
<div>4. method call</div>
<div><br></div>
<div>type1 object;</div>
<div>object..aVirtualMethod();</div>
<div><br></div>
<div>the token here is ".." instead of "." or "-&gt;"</div>
<div>
This is again has different semantics. But would not bother with details for the moment.&nbsp;</div>
<div><br></div>
<div>Further new constructs are in my mind for fibers, continuations (yes they will be different) and and.</div>
<div>Decided to call this "babel C", so files will probably have extension bh/bc (header/implementation)<br>
</div>
<div><br></div>
<div>The bc file will be translated into pure C by the modified tcc. A construct like 1. will be translated into</div>
<div>a C struct with some additional part etc + some glue code. (Will not go into details, but will publish soon the details).&nbsp;</div>
<div>Construct 2 will be also translated into a struc + some glue code, the same with 3. and 4.</div>
<div><br></div>
<div>I studied the tcc parser and compiler bit more in depth. Found more or less where I should patch. I kept things easy,</div>
<div>(you remember wanted to use some special syntax with  <at>  &nbsp;etc. etc.), so that my stuff fits easyl</div>
<div>into the parsers logic.&nbsp;</div>
<div><br></div>
<div>What I need now and this is the minimum that would be probably nice to see it going upstream.&nbsp;</div>
<div>My first naiv approach wast to save a pointer in the input buffer and:</div>
<div>-&gt; anything that is normal C syntax, after successful parsing of a declaration or part of a declaration,</div>
<div>send the input to the output</div>
<div>-&gt; anything that is syntax extension, fill in a kind of template and send the result to the output.</div>
<div>This task became though a bit complex for me due to the pre-processing. Got a bit lost with token managemnt,<br>
</div>
<div>but probably after further hours could find the solution. Though some hints would be welcome.</div>
<div><br></div>
<div>I got the suggestion to separate the code from original tcc, keep the parser and implement my code generation.</div>
<div>Not sure that this would make my life easier. Do not think this is a good idea as the assembly code generation&nbsp;</div>
<div>bits would not disturb me (the part that would be redundant for me).</div>
<div><br></div>
<div>My own first question seems to be confusing as it is not easy to ask it :)... I am rather expecting some hints..</div>
<div>
The second question if you could suggest some basic changes in the parser and supporting code that&nbsp;</div>
<div>would make life easier to implement such extensions for code generation.</div>
<div><br></div>
<div>thanks a lot,</div>
<div>mobi phil</div>
</div></div>
Josip Habjan | 16 Apr 19:00 2014
Picon

Re: Tinycc-devel Digest, Vol 132, Issue 22

Thanks, this is exactly what I was looking for. It will be nice for the user to be able to deploy a single dll with everything in it for a C scripting inside their .NET applications.

Cheers,
jhabjan


2014-04-16 18:00 GMT+02:00 <tinycc-devel-request <at> nongnu.org>:
Send Tinycc-devel mailing list submissions to
        tinycc-devel-qX2TKyscuCcdnm+yROfE0A@public.gmane.org

To subscribe or unsubscribe via the World Wide Web, visit
        https://lists.nongnu.org/mailman/listinfo/tinycc-devel
or, via email, send a message with subject or body 'help' to
        tinycc-devel-request-qX2TKyscuCcdnm+yROfE0A@public.gmane.org

You can reach the person managing the list at
        tinycc-devel-owner-qX2TKyscuCcdnm+yROfE0A@public.gmane.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Tinycc-devel digest..."


Today's Topics:

   1. Re: dynamic library - embedded header, object,
      library....files (Domingo Alvarez Duarte)
   2. Re: dynamic library - embedded header, object,
      library....files (Jared Maddox)


----------------------------------------------------------------------

Message: 1
Date: Tue, 15 Apr 2014 20:09:16 +0100
From: Domingo Alvarez Duarte <mingodad-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: tinycc-devel-qX2TKyscuCcdnm+yROfE0A@public.gmane.org
Subject: Re: [Tinycc-devel] dynamic library - embedded header, object,
        library....files
Message-ID:
        <CALCTSagXsFDpYHkDxG+6EiJXV84-65Z_gYDFa0WmLyP3BdGAqQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Content-Type: text/plain; charset="utf-8"

That is just what I did here https://github.com/mingodad/tinycc I called it
virtual_io.

If you checkout it and execute the script "mk-it" it will create a self
contained tinycc, the same principle can be used to use it as a library.

Cheers !


On Tue, Apr 15, 2014 at 4:58 PM, Josip Habjan <habjan-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

> Hi,
>
> Is there a chance to add a simple function that will allow users to load
> all required files from memory? For instance: I made a .NET wrapper for
> tcclib and I have all 'lib' and 'include' files compiled in a single .NET
> dll as embedded resources. Now, I don't want to export embedded files out
> from the dll to disk, and then run compiled, instead i would like compiler
> to ask me where he can find requested file. (In my case I want it to be
> read from memory).
>
> What I'm thinking is some function that will allow file redirection. This
> would be easy for non windows systems which supports "fmemopen" function as
> they can easily redirect some file request to the file descriptor from
> memory returned by "fmemopen". For windows users the only option is a
> memory buffer.
>
> What I had in mind is something like:
>
> typedef struct RedirectedFile
> {
> int fd;
> void *buf;
>  unsigned long buflen;
> unsigned char filename[1024];
> } RedirectedFile;
>
> LIBTCCAPI void tcc_set_file_redirection_func(TCCState *s,
> int(*get_file_func)(const char *filename, RedirectedFile *rf),
> void(*release_file_func)(void* buff, int fd));
>
> typedef struct FileOrBuffer
> {
> int state;
> int is_fd;
> int fd;
>  void *buf;
> unsigned long len;
> unsigned long pos;
>  int is_redirect;
> } FileOrBuffer;
>
> typedef struct BufferedFile {
> ...   FileOrBuffer fob;  /* ex: int fd */
>     ...
> } BufferedFile;
>
> and then in tcc_open before opening a file I would simply call
> "get_file_func"...
>
> I know this takes a lot of changes for all file reads and seeks, but..
> actualy, it's not that complicated as I had to replace and add only 2
> functions:
>
> PUB_FUNC int tcc_fobread(FileOrBuffer *fob, void *dest, int size)
> {
> if (fob->is_fd)
> return read(fob->fd, dest, size);
> else {
>  long available = fob->len - fob->pos;
>
> if (size > available) {
> size = available;
>  }
>
> memcpy(dest, (char*)fob->buf + fob->pos, size);
>
> fob->pos += size;
>
> return size;
> }
> }
>
> PUB_FUNC long tcc_foblseek(FileOrBuffer *fob, long offset, int origin)
> {
> if (fob->is_fd)
> return lseek(fob->fd, offset, origin);
> else {
>  long pos;
> switch (origin) {
> case SEEK_SET: {
>  if (offset >= 0) {
> pos = offset;
> }
> else {
>  pos = 0;
> }
> break;
> }
>  case SEEK_CUR: {
> if (offset >= 0 || -offset <= fob->pos) {
> pos = fob->pos + offset;
>  }
> else {
> pos = 0;
> }
>  break;
> }
> case SEEK_END: {
> pos = fob->len + offset;
>  break;
> }
> default:
> return -1;
>  }
>
> if (pos > fob->len) {
> return -1;
>  }
>
> fob->pos = pos;
> return pos;
>  }
> }
>
> C is not really familiar to me, I'm more .NET oriented, but I gave it a
> try and came up with the solution. Here is a complete source code that
> works:
>
> https://www.dropbox.com/s/4y30qrejkmocvqn/tcc-src.zip
>
> Thanks,
> jhabjan
>
> _______________________________________________
> Tinycc-devel mailing list
> Tinycc-devel-qX2TKyscuCcdnm+yROfE0A@public.gmane.org
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nongnu.org/archive/html/tinycc-devel/attachments/20140415/920f86de/attachment.html>

------------------------------

Message: 2
Date: Wed, 16 Apr 2014 00:15:36 -0500
From: Jared Maddox <absinthdraco-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: tinycc-devel-qX2TKyscuCcdnm+yROfE0A@public.gmane.org
Subject: Re: [Tinycc-devel] dynamic library - embedded header, object,
        library....files
Message-ID:
        <CABXS6_=scHoCVQa33qYSG589ePZ6Ca2u2Wu+HBDpvezXzTanoA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Content-Type: text/plain; charset=UTF-8

Happily, it appears that the cat did NOT send this email for me.

> Date: Tue, 15 Apr 2014 17:58:57 +0200
> From: Josip Habjan <habjan <at> gmail.com>
> To: tinycc-devel-qX2TKyscuCcdnm+yROfE0A@public.gmane.org
> Subject: [Tinycc-devel] dynamic library - embedded header, object,
>         library....files
> Message-ID:
>         <CABA7v=uGTSdN9fKTG14kaDDd5iGNHzjm8-d+ufreDcWLCw1wMA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
> Content-Type: text/plain; charset="utf-8"
>
> Hi,
>
> Is there a chance to add a simple function that will allow users to load
> all required files from memory? For instance: I made a .NET wrapper for
> tcclib and I have all 'lib' and 'include' files compiled in a single .NET
> dll as embedded resources. Now, I don't want to export embedded files out
> from the dll to disk, and then run compiled, instead i would like compiler
> to ask me where he can find requested file. (In my case I want it to be
> read from memory).
>
> What I'm thinking is some function that will allow file redirection. This
> would be easy for non windows systems which supports "fmemopen" function as
> they can easily redirect some file request to the file descriptor from
> memory returned by "fmemopen". For windows users the only option is a
> memory buffer.
>

Look up "virtual io tcc", or look at this (
http://lists.nongnu.org/archive/html/tinycc-devel/2013-01/index.html )
page, starting around January 10th. I don't believe such a facility
was ever accepted into a release candidate, but I think it was on a
"not enough requests" basis rather than anything else. Then again, I
didn't review all of those emails.

On a slightly separate note, this is the second question that seemed
relevant to "virtual io" that I REMEMBER from as many weeks (the other
was in a direct email). I think that there really is enough reason to
add this sort of "glue layer" into TCC, though I also wonder if this
should be forcibly delayed until after the "globals removal" work has
been completed and merged, since it would probably be wise to allow
individual states to be associated with individual individual IO
wrappers.



------------------------------

_______________________________________________
Tinycc-devel mailing list
Tinycc-devel-qX2TKyscuCcdnm+yROfE0A@public.gmane.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel


End of Tinycc-devel Digest, Vol 132, Issue 22
*********************************************

<div>
<div dir="ltr">Thanks, this is exactly what I was looking for. It will be nice for the user to be able to deploy a single dll with everything in it for a C scripting inside their .NET applications.<div><br></div>
<div>Cheers,</div>
<div>jhabjan</div>
</div>
<div class="gmail_extra">
<br><br><div class="gmail_quote">2014-04-16 18:00 GMT+02:00  <span dir="ltr">&lt;<a href="mailto:tinycc-devel-request@..." target="_blank">tinycc-devel-request <at> nongnu.org</a>&gt;</span>:<br><blockquote class="gmail_quote">Send Tinycc-devel mailing list submissions to<br>
&nbsp; &nbsp; &nbsp; &nbsp; <a href="mailto:tinycc-devel@...">tinycc-devel@...</a><br><br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
&nbsp; &nbsp; &nbsp; &nbsp; <a href="https://lists.nongnu.org/mailman/listinfo/tinycc-devel" target="_blank">https://lists.nongnu.org/mailman/listinfo/tinycc-devel</a><br>
or, via email, send a message with subject or body 'help' to<br>
&nbsp; &nbsp; &nbsp; &nbsp; <a href="mailto:tinycc-devel-request <at> nongnu.org">tinycc-devel-request@...</a><br><br>
You can reach the person managing the list at<br>
&nbsp; &nbsp; &nbsp; &nbsp; <a href="mailto:tinycc-devel-owner@...">tinycc-devel-owner@...</a><br><br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of Tinycc-devel digest..."<br><br><br>
Today's Topics:<br><br>
&nbsp; &nbsp;1. Re: dynamic library - embedded header, object,<br>
&nbsp; &nbsp; &nbsp; library....files (Domingo Alvarez Duarte)<br>
&nbsp; &nbsp;2. Re: dynamic library - embedded header, object,<br>
&nbsp; &nbsp; &nbsp; library....files (Jared Maddox)<br><br><br>
----------------------------------------------------------------------<br><br>
Message: 1<br>
Date: Tue, 15 Apr 2014 20:09:16 +0100<br>
From: Domingo Alvarez Duarte &lt;<a href="mailto:mingodad@...">mingodad@...</a>&gt;<br>
To: <a href="mailto:tinycc-devel@...">tinycc-devel@...</a><br>
Subject: Re: [Tinycc-devel] dynamic library - embedded header, object,<br>
&nbsp; &nbsp; &nbsp; &nbsp; library....files<br>
Message-ID:<br>
&nbsp; &nbsp; &nbsp; &nbsp; &lt;<a href="mailto:CALCTSagXsFDpYHkDxG%2B6EiJXV84-65Z_gYDFa0WmLyP3BdGAqQ@...">CALCTSagXsFDpYHkDxG+6EiJXV84-65Z_gYDFa0WmLyP3BdGAqQ@...</a>&gt;<br>
Content-Type: text/plain; charset="utf-8"<br><br>
That is just what I did here <a href="https://github.com/mingodad/tinycc" target="_blank">https://github.com/mingodad/tinycc</a> I called it<br>
virtual_io.<br><br>
If you checkout it and execute the script "mk-it" it will create a self<br>
contained tinycc, the same principle can be used to use it as a library.<br><br>
Cheers !<br><br><br>
On Tue, Apr 15, 2014 at 4:58 PM, Josip Habjan &lt;<a href="mailto:habjan <at> gmail.com">habjan@...</a>&gt; wrote:<br><br>
&gt; Hi,<br>
&gt;<br>
&gt; Is there a chance to add a simple function that will allow users to load<br>
&gt; all required files from memory? For instance: I made a .NET wrapper for<br>
&gt; tcclib and I have all 'lib' and 'include' files compiled in a single .NET<br>
&gt; dll as embedded resources. Now, I don't want to export embedded files out<br>
&gt; from the dll to disk, and then run compiled, instead i would like compiler<br>
&gt; to ask me where he can find requested file. (In my case I want it to be<br>
&gt; read from memory).<br>
&gt;<br>
&gt; What I'm thinking is some function that will allow file redirection. This<br>
&gt; would be easy for non windows systems which supports "fmemopen" function as<br>
&gt; they can easily redirect some file request to the file descriptor from<br>
&gt; memory returned by "fmemopen". For windows users the only option is a<br>
&gt; memory buffer.<br>
&gt;<br>
&gt; What I had in mind is something like:<br>
&gt;<br>
&gt; typedef struct RedirectedFile<br>
&gt; {<br>
&gt; int fd;<br>
&gt; void *buf;<br>
&gt; &nbsp;unsigned long buflen;<br>
&gt; unsigned char filename[1024];<br>
&gt; } RedirectedFile;<br>
&gt;<br>
&gt; LIBTCCAPI void tcc_set_file_redirection_func(TCCState *s,<br>
&gt; int(*get_file_func)(const char *filename, RedirectedFile *rf),<br>
&gt; void(*release_file_func)(void* buff, int fd));<br>
&gt;<br>
&gt; typedef struct FileOrBuffer<br>
&gt; {<br>
&gt; int state;<br>
&gt; int is_fd;<br>
&gt; int fd;<br>
&gt; &nbsp;void *buf;<br>
&gt; unsigned long len;<br>
&gt; unsigned long pos;<br>
&gt; &nbsp;int is_redirect;<br>
&gt; } FileOrBuffer;<br>
&gt;<br>
&gt; typedef struct BufferedFile {<br>
&gt; ... &nbsp; FileOrBuffer fob; &nbsp;/* ex: int fd */<br>
&gt; &nbsp; &nbsp; ...<br>
&gt; } BufferedFile;<br>
&gt;<br>
&gt; and then in tcc_open before opening a file I would simply call<br>
&gt; "get_file_func"...<br>
&gt;<br>
&gt; I know this takes a lot of changes for all file reads and seeks, but..<br>
&gt; actualy, it's not that complicated as I had to replace and add only 2<br>
&gt; functions:<br>
&gt;<br>
&gt; PUB_FUNC int tcc_fobread(FileOrBuffer *fob, void *dest, int size)<br>
&gt; {<br>
&gt; if (fob-&gt;is_fd)<br>
&gt; return read(fob-&gt;fd, dest, size);<br>
&gt; else {<br>
&gt; &nbsp;long available = fob-&gt;len - fob-&gt;pos;<br>
&gt;<br>
&gt; if (size &gt; available) {<br>
&gt; size = available;<br>
&gt; &nbsp;}<br>
&gt;<br>
&gt; memcpy(dest, (char*)fob-&gt;buf + fob-&gt;pos, size);<br>
&gt;<br>
&gt; fob-&gt;pos += size;<br>
&gt;<br>
&gt; return size;<br>
&gt; }<br>
&gt; }<br>
&gt;<br>
&gt; PUB_FUNC long tcc_foblseek(FileOrBuffer *fob, long offset, int origin)<br>
&gt; {<br>
&gt; if (fob-&gt;is_fd)<br>
&gt; return lseek(fob-&gt;fd, offset, origin);<br>
&gt; else {<br>
&gt; &nbsp;long pos;<br>
&gt; switch (origin) {<br>
&gt; case SEEK_SET: {<br>
&gt; &nbsp;if (offset &gt;= 0) {<br>
&gt; pos = offset;<br>
&gt; }<br>
&gt; else {<br>
&gt; &nbsp;pos = 0;<br>
&gt; }<br>
&gt; break;<br>
&gt; }<br>
&gt; &nbsp;case SEEK_CUR: {<br>
&gt; if (offset &gt;= 0 || -offset &lt;= fob-&gt;pos) {<br>
&gt; pos = fob-&gt;pos + offset;<br>
&gt; &nbsp;}<br>
&gt; else {<br>
&gt; pos = 0;<br>
&gt; }<br>
&gt; &nbsp;break;<br>
&gt; }<br>
&gt; case SEEK_END: {<br>
&gt; pos = fob-&gt;len + offset;<br>
&gt; &nbsp;break;<br>
&gt; }<br>
&gt; default:<br>
&gt; return -1;<br>
&gt; &nbsp;}<br>
&gt;<br>
&gt; if (pos &gt; fob-&gt;len) {<br>
&gt; return -1;<br>
&gt; &nbsp;}<br>
&gt;<br>
&gt; fob-&gt;pos = pos;<br>
&gt; return pos;<br>
&gt; &nbsp;}<br>
&gt; }<br>
&gt;<br>
&gt; C is not really familiar to me, I'm more .NET oriented, but I gave it a<br>
&gt; try and came up with the solution. Here is a complete source code that<br>
&gt; works:<br>
&gt;<br>
&gt; <a href="https://www.dropbox.com/s/4y30qrejkmocvqn/tcc-src.zip" target="_blank">https://www.dropbox.com/s/4y30qrejkmocvqn/tcc-src.zip</a><br>
&gt;<br>
&gt; Thanks,<br>
&gt; jhabjan<br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; Tinycc-devel mailing list<br>
&gt; <a href="mailto:Tinycc-devel@...">Tinycc-devel@...</a><br>
&gt; <a href="https://lists.nongnu.org/mailman/listinfo/tinycc-devel" target="_blank">https://lists.nongnu.org/mailman/listinfo/tinycc-devel</a><br>
&gt;<br>
&gt;<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: &lt;<a href="http://lists.nongnu.org/archive/html/tinycc-devel/attachments/20140415/920f86de/attachment.html" target="_blank">http://lists.nongnu.org/archive/html/tinycc-devel/attachments/20140415/920f86de/attachment.html</a>&gt;<br><br>
------------------------------<br><br>
Message: 2<br>
Date: Wed, 16 Apr 2014 00:15:36 -0500<br>
From: Jared Maddox &lt;<a href="mailto:absinthdraco@...">absinthdraco@...</a>&gt;<br>
To: <a href="mailto:tinycc-devel@...">tinycc-devel@...</a><br>
Subject: Re: [Tinycc-devel] dynamic library - embedded header, object,<br>
&nbsp; &nbsp; &nbsp; &nbsp; library....files<br>
Message-ID:<br>
&nbsp; &nbsp; &nbsp; &nbsp; &lt;CABXS6_=<a href="mailto:scHoCVQa33qYSG589ePZ6Ca2u2Wu%2BHBDpvezXzTanoA@...">scHoCVQa33qYSG589ePZ6Ca2u2Wu+HBDpvezXzTanoA@...</a>&gt;<br>
Content-Type: text/plain; charset=UTF-8<br><br>
Happily, it appears that the cat did NOT send this email for me.<br><br>
&gt; Date: Tue, 15 Apr 2014 17:58:57 +0200<br>
&gt; From: Josip Habjan &lt;<a href="mailto:habjan@...">habjan <at> gmail.com</a>&gt;<br>
&gt; To: <a href="mailto:tinycc-devel@...">tinycc-devel@...</a><br>
&gt; Subject: [Tinycc-devel] dynamic library - embedded header, object,<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; library....files<br>
&gt; Message-ID:<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; &lt;CABA7v=<a href="mailto:uGTSdN9fKTG14kaDDd5iGNHzjm8-d%2BufreDcWLCw1wMA@...">uGTSdN9fKTG14kaDDd5iGNHzjm8-d+ufreDcWLCw1wMA@...</a>&gt;<br>
&gt; Content-Type: text/plain; charset="utf-8"<br>
&gt;<br>
&gt; Hi,<br>
&gt;<br>
&gt; Is there a chance to add a simple function that will allow users to load<br>
&gt; all required files from memory? For instance: I made a .NET wrapper for<br>
&gt; tcclib and I have all 'lib' and 'include' files compiled in a single .NET<br>
&gt; dll as embedded resources. Now, I don't want to export embedded files out<br>
&gt; from the dll to disk, and then run compiled, instead i would like compiler<br>
&gt; to ask me where he can find requested file. (In my case I want it to be<br>
&gt; read from memory).<br>
&gt;<br>
&gt; What I'm thinking is some function that will allow file redirection. This<br>
&gt; would be easy for non windows systems which supports "fmemopen" function as<br>
&gt; they can easily redirect some file request to the file descriptor from<br>
&gt; memory returned by "fmemopen". For windows users the only option is a<br>
&gt; memory buffer.<br>
&gt;<br><br>
Look up "virtual io tcc", or look at this (<br><a href="http://lists.nongnu.org/archive/html/tinycc-devel/2013-01/index.html" target="_blank">http://lists.nongnu.org/archive/html/tinycc-devel/2013-01/index.html</a> )<br>
page, starting around January 10th. I don't believe such a facility<br>
was ever accepted into a release candidate, but I think it was on a<br>
"not enough requests" basis rather than anything else. Then again, I<br>
didn't review all of those emails.<br><br>
On a slightly separate note, this is the second question that seemed<br>
relevant to "virtual io" that I REMEMBER from as many weeks (the other<br>
was in a direct email). I think that there really is enough reason to<br>
add this sort of "glue layer" into TCC, though I also wonder if this<br>
should be forcibly delayed until after the "globals removal" work has<br>
been completed and merged, since it would probably be wise to allow<br>
individual states to be associated with individual individual IO<br>
wrappers.<br><br><br><br>
------------------------------<br><br>
_______________________________________________<br>
Tinycc-devel mailing list<br><a href="mailto:Tinycc-devel@...">Tinycc-devel@...</a><br><a href="https://lists.nongnu.org/mailman/listinfo/tinycc-devel" target="_blank">https://lists.nongnu.org/mailman/listinfo/tinycc-devel</a><br><br><br>
End of Tinycc-devel Digest, Vol 132, Issue 22<br>
*********************************************<br>
</blockquote>
</div>
<br>
</div>
</div>
Josip Habjan | 15 Apr 17:58 2014
Picon

dynamic library - embedded header, object, library....files

Hi,

Is there a chance to add a simple function that will allow users to load all required files from memory? For instance: I made a .NET wrapper for tcclib and I have all 'lib' and 'include' files compiled in a single .NET dll as embedded resources. Now, I don't want to export embedded files out from the dll to disk, and then run compiled, instead i would like compiler to ask me where he can find requested file. (In my case I want it to be read from memory).

What I'm thinking is some function that will allow file redirection. This would be easy for non windows systems which supports "fmemopen" function as they can easily redirect some file request to the file descriptor from memory returned by "fmemopen". For windows users the only option is a memory buffer.

What I had in mind is something like:

typedef struct RedirectedFile
{
int fd;
void *buf;
unsigned long buflen;
unsigned char filename[1024];
} RedirectedFile;

LIBTCCAPI void tcc_set_file_redirection_func(TCCState *s,
int(*get_file_func)(const char *filename, RedirectedFile *rf),
void(*release_file_func)(void* buff, int fd));

typedef struct FileOrBuffer
{
int state;
int is_fd;
int fd;
void *buf;
unsigned long len;
unsigned long pos;
int is_redirect;
} FileOrBuffer;

typedef struct BufferedFile {
...   FileOrBuffer fob;  /* ex: int fd */
    ...
} BufferedFile;

and then in tcc_open before opening a file I would simply call "get_file_func"...

I know this takes a lot of changes for all file reads and seeks, but.. actualy, it's not that complicated as I had to replace and add only 2 functions:

PUB_FUNC int tcc_fobread(FileOrBuffer *fob, void *dest, int size)
{
if (fob->is_fd)
return read(fob->fd, dest, size);
else {
long available = fob->len - fob->pos;

if (size > available) {
size = available;
}

memcpy(dest, (char*)fob->buf + fob->pos, size);

fob->pos += size;

return size;
}
}

PUB_FUNC long tcc_foblseek(FileOrBuffer *fob, long offset, int origin)
{
if (fob->is_fd)
return lseek(fob->fd, offset, origin);
else {
long pos;
switch (origin) {
case SEEK_SET: {
if (offset >= 0) {
pos = offset;
}
else {
pos = 0;
}
break;
}
case SEEK_CUR: {
if (offset >= 0 || -offset <= fob->pos) {
pos = fob->pos + offset;
}
else {
pos = 0;
}
break;
}
case SEEK_END: {
pos = fob->len + offset; 
break;
}
default: 
return -1;
}

if (pos > fob->len) {
return -1;
}

fob->pos = pos;
return pos;
}
}

C is not really familiar to me, I'm more .NET oriented, but I gave it a try and came up with the solution. Here is a complete source code that works:

https://www.dropbox.com/s/4y30qrejkmocvqn/tcc-src.zip

Thanks,
jhabjan
<div><div dir="ltr">
<div>Hi,<br>
</div>
<div><br></div>
<div>Is there a chance to add a simple function that will allow users to load all required files from memory? For instance: I made a .NET wrapper for tcclib and I have all 'lib' and 'include' files compiled in a single .NET dll as embedded resources. Now, I don't want to export embedded files out from the dll to disk, and then run compiled, instead i would like compiler to ask me where he can find requested file. (In my case I want it to be read from memory).</div>
<div><br></div>
<div>What I'm thinking is some function that will allow file redirection. This would be easy for non windows systems which supports "fmemopen" function as they can easily redirect some file request to the file descriptor from memory returned by "fmemopen". For windows users the only option is a memory buffer.</div>
<div><br></div>
<div>What I had in mind is something like:</div>
<div><br></div>
<div>
<div>typedef struct RedirectedFile<br>
</div>
<div>
<div>{</div>
<div>
<span class="">	</span>int fd;</div>
<div>
<span class="">	</span>void *buf;</div>
<div>
<span class="">	</span>unsigned long buflen;</div>
<div>
<span class="">	</span>unsigned char filename[1024];</div>
<div>} RedirectedFile;</div>
</div>
</div>
<div><br></div>
<div>
<div>LIBTCCAPI void tcc_set_file_redirection_func(TCCState *s,</div>
<div>
<span class="">	</span>int(*get_file_func)(const char *filename, RedirectedFile *rf),</div>
<div>
<span class="">	</span>void(*release_file_func)(void* buff, int fd));</div>
</div>
<div><br></div>
<div>
<div>typedef struct FileOrBuffer</div>
<div>{</div>
<div>
<span class="">	</span>int state;</div>
<div>
<span class="">	</span>int is_fd;</div>
<div>
<span class="">	</span>int fd;</div>
<div>
<span class="">	</span>void *buf;</div>
<div>
<span class="">	</span>unsigned long len;</div>
<div>
<span class="">	</span>unsigned long pos;</div>
<div>
<span class="">	</span>int is_redirect;</div>
<div>} FileOrBuffer;</div>
</div>
<div><br></div>
<div>
<div>typedef struct BufferedFile {</div>
<div>
<span>    ...
&nbsp;   </span>FileOrBuffer fob; &nbsp;/* ex: int fd */<br>&nbsp; &nbsp; ...</div>
<div>} BufferedFile;<br>
</div>
</div>
<div><br></div>
<div>and then in tcc_open before opening a file I would simply call "get_file_func"...</div>
<div>
<br>
</div>
<div>I know this takes a lot of changes for all file reads and seeks, but.. actualy, it's not that complicated as I had to replace and add only 2 functions:</div>
<div><br></div>
<div>
<div>PUB_FUNC int tcc_fobread(FileOrBuffer *fob, void *dest, int size)</div>
<div>{</div>
<div>
<span class="">	</span>if (fob-&gt;is_fd)</div>
<div>
<span class="">		</span>return read(fob-&gt;fd, dest, size);</div>
<div>
<span class="">	</span>else {</div>
<div>
<span class="">		</span>long available = fob-&gt;len - fob-&gt;pos;</div>
<div><br></div>
<div>
<span class="">		</span>if (size &gt; available) {</div>
<div>
<span class="">			</span>size = available;</div>
<div>
<span class="">		</span>}</div>
<div><br></div>
<div>
<span class="">		</span>memcpy(dest, (char*)fob-&gt;buf + fob-&gt;pos, size);</div>
<div><br></div>
<div>
<span class="">		</span>fob-&gt;pos += size;</div>
<div><br></div>
<div>
<span class="">		</span>return size;</div>
<div>
<span class="">	</span>}</div>
<div>}</div>
<div><br></div>
<div>PUB_FUNC long tcc_foblseek(FileOrBuffer *fob, long offset, int origin)</div>
<div>{</div>
<div>
<span class="">	</span>if (fob-&gt;is_fd)</div>
<div>
<span class="">		</span>return lseek(fob-&gt;fd, offset, origin);</div>
<div>
<span class="">	</span>else {</div>
<div>
<span class="">		</span>long pos;</div>
<div>
<span class="">		</span>switch (origin) {</div>
<div>
<span class="">			</span>case SEEK_SET: {</div>
<div>
<span class="">				</span>if (offset &gt;= 0) {</div>
<div>
<span class="">					</span>pos = offset;</div>
<div>
<span class="">				</span>}</div>
<div>
<span class="">				</span>else {</div>
<div>
<span class="">					</span>pos = 0;</div>
<div>
<span class="">				</span>}</div>
<div>
<span class="">				</span>break;</div>
<div>
<span class="">			</span>}</div>
<div>
<span class="">			</span>case SEEK_CUR: {</div>
<div>
<span class="">				</span>if (offset &gt;= 0 || -offset &lt;= fob-&gt;pos) {</div>
<div>
<span class="">					</span>pos = fob-&gt;pos + offset;</div>
<div>
<span class="">				</span>}</div>
<div>
<span class="">				</span>else {</div>
<div>
<span class="">					</span>pos = 0;</div>
<div>
<span class="">				</span>}</div>
<div>
<span class="">				</span>break;</div>
<div>
<span class="">			</span>}</div>
<div>
<span class="">			</span>case SEEK_END: {</div>
<div>
<span class="">				</span>pos = fob-&gt;len + offset;&nbsp;</div>
<div>
<span class="">				</span>break;</div>
<div>
<span class="">			</span>}</div>
<div>
<span class="">			</span>default:&nbsp;</div>
<div>
<span class="">				</span>return -1;</div>
<div>
<span class="">		</span>}</div>
<div><br></div>
<div>
<span class="">		</span>if (pos &gt; fob-&gt;len) {</div>
<div>
<span class="">			</span>return -1;</div>
<div>
<span class="">		</span>}</div>
<div><br></div>
<div>
<span class="">		</span>fob-&gt;pos = pos;</div>
<div>
<span class="">		</span>return pos;</div>
<div>
<span class="">	</span>}</div>
<div>}</div>
</div>
<div><br></div>
<div>C is not really familiar to me, I'm more .NET oriented, but I gave it a try and came up with the solution. Here is a complete source code that works:</div>
<div><br></div>
<a href="https://www.dropbox.com/s/4y30qrejkmocvqn/tcc-src.zip">https://www.dropbox.com/s/4y30qrejkmocvqn/tcc-src.zip</a><br><div><br></div>
<div>Thanks,</div>
<div>jhabjan</div>
</div></div>
Austin English | 13 Apr 02:40 2014
Picon

Support for hidden symbols?

Howdy,

I recently revisited compiling Wine with TinyCC. I've got some patches for wine for that, but my current blocker is a lack of support for hidden symbols on tcc:
make[1]: Entering directory `/home/austin/src/wine-tcc/dlls/acledit'
/home/austin/tcc/bin/i386-linux-gnu-tcc -m32 -c -I. -I. -I../../include -I../../include  -D__WINESRC__  -D_REENTRANT -fPIC   -g  -o main.o main.c
../../tools/winegcc/winegcc -m32 -B../../tools/winebuild --sysroot=../..  -shared ./acledit.spec main.o           -o acledit.dll.so    ../../libs/port/libwine_port.a  
acledit.pEPjUb.s:14: error: unknown assembler directive '.hidden'
winebuild: /home/austin/tcc/bin/i386-linux-gnu-tcc failed with status 1
winegcc: ../../tools/winebuild/winebuild failed
make[1]: *** [acledit.dll.so] Error 2
make[1]: Leaving directory `/home/austin/src/wine-tcc/dlls/acledit'
make: *** [dlls/acledit] Error 2

relevant Wine code (tools/winebuild/utils.c):

/* return a global symbol declaration for an assembly symbol */
const char *asm_globl( const char *func )
{
    static char *buffer;

    free( buffer );
    switch (target_platform)
    {
    case PLATFORM_APPLE:
        buffer = strmake( "\t.globl _%s\n\t.private_extern _%s\n_%s:", func, func, func );
        break;
    case PLATFORM_WINDOWS:
        buffer = strmake( "\t.globl _%s\n_%s:", func, func );
        break;
    default:
        buffer = strmake( "\t.globl %s\n\t.hidden %s\n%s:", func, func, func );
        break;
    }
    return buffer;
}

is there any plan for supporting this?

--
-Austin
<div><div dir="ltr">
<div>
<div>Howdy,<br><br>I recently revisited compiling Wine with TinyCC. I've got some patches for wine for that, but my current blocker is a lack of support for hidden symbols on tcc:<br>make[1]: Entering directory `/home/austin/src/wine-tcc/dlls/acledit'<br>

/home/austin/tcc/bin/i386-linux-gnu-tcc -m32 -c -I. -I. -I../../include -I../../include&nbsp; -D__WINESRC__&nbsp; -D_REENTRANT -fPIC&nbsp;&nbsp; -g&nbsp; -o main.o main.c<br>../../tools/winegcc/winegcc -m32 -B../../tools/winebuild --sysroot=../..&nbsp; -shared ./acledit.spec main.o&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -o <a href="http://acledit.dll.so">acledit.dll.so</a>&nbsp;&nbsp;&nbsp; ../../libs/port/libwine_port.a&nbsp;&nbsp; <br>

acledit.pEPjUb.s:14: error: unknown assembler directive '.hidden'<br>winebuild: /home/austin/tcc/bin/i386-linux-gnu-tcc failed with status 1<br>winegcc: ../../tools/winebuild/winebuild failed<br>make[1]: *** [<a href="http://acledit.dll.so">acledit.dll.so</a>] Error 2<br>

make[1]: Leaving directory `/home/austin/src/wine-tcc/dlls/acledit'<br>make: *** [dlls/acledit] Error 2<br><br>
</div>relevant Wine code (tools/winebuild/utils.c):<br><br>/* return a global symbol declaration for an assembly symbol */<br>

const char *asm_globl( const char *func )<br>{<br>&nbsp;&nbsp;&nbsp; static char *buffer;<br><br>&nbsp;&nbsp;&nbsp; free( buffer );<br>&nbsp;&nbsp;&nbsp; switch (target_platform)<br>&nbsp;&nbsp;&nbsp; {<br>&nbsp;&nbsp;&nbsp; case PLATFORM_APPLE:<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; buffer = strmake( "\t.globl _%s\n\t.private_extern _%s\n_%s:", func, func, func );<br>

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; break;<br>&nbsp;&nbsp;&nbsp; case PLATFORM_WINDOWS:<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; buffer = strmake( "\t.globl _%s\n_%s:", func, func );<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; break;<br>&nbsp;&nbsp;&nbsp; default:<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; buffer = strmake( "\t.globl %s\n\t.hidden %s\n%s:", func, func, func );<br>

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; break;<br>&nbsp;&nbsp;&nbsp; }<br>&nbsp;&nbsp;&nbsp; return buffer;<br>}<br>
</div>
<div><br></div>
<div>is there any plan for supporting this?<br><br>
</div>
<div>-- <br><div><div>-Austin
</div></div>
</div>
</div></div>
Thomas Preud'homme | 9 Apr 14:43 2014
Picon

Building a single cross-compiler: please test new configure

I have a patch to build a single cross-compiler by using --targetcpu but given 
the potential of breakage of the build script I prefer to post it here for now 
and ask you to try building tcc with it, either natively or all the cross 
compilers to see if anything break.

You can also try building a single compiler to see if it works for you or take 
a look at the patch. Any feedback welcome.

Best regards,

Thomas
Attachment (crosstcc.diff): text/x-patch, 14 KiB
I have a patch to build a single cross-compiler by using --targetcpu but given 
the potential of breakage of the build script I prefer to post it here for now 
and ask you to try building tcc with it, either natively or all the cross 
compilers to see if anything break.

You can also try building a single compiler to see if it works for you or take 
a look at the patch. Any feedback welcome.

Best regards,

Thomas
Steve Kemp | 8 Apr 17:17 2014
Picon

Compiling tcc for use in a static environment

  I'm in the middle of building a rescue-system, and I would
 like to be able to include a simple compiler within that
 environment.

  Ideally I'd like to see tcc compiled against uclibc, or
 musl, however despite coming across prior art I've been
 unsuccessful at making the thing work.

  For example this link:
    http://pts-mini-gpl.googlecode.com/svn/trunk/pts-tcc/

  Contains a small diff, and a recipe, but for me that fails
 to link.

  Using musl I got as far as compiling tcc, but the generated
 binaries themselves fail to link:

$ /opt/tcc/bin/tcc t.c
tcc: error: file 'crt1.o' not found
tcc: error: file 'crti.o' not found

  At this point I'm taking a step back and asking if there
 are any existing recipes for building a static compiler
 that can be used in a static-only environment (with no ldd
 or linker present).

    
Steve
-- 
  I'm in the middle of building a rescue-system, and I would
 like to be able to include a simple compiler within that
 environment.

  Ideally I'd like to see tcc compiled against uclibc, or
 musl, however despite coming across prior art I've been
 unsuccessful at making the thing work.

  For example this link:
    http://pts-mini-gpl.googlecode.com/svn/trunk/pts-tcc/

  Contains a small diff, and a recipe, but for me that fails
 to link.

  Using musl I got as far as compiling tcc, but the generated
 binaries themselves fail to link:

$ /opt/tcc/bin/tcc t.c
tcc: error: file 'crt1.o' not found
tcc: error: file 'crti.o' not found

  At this point I'm taking a step back and asking if there
 are any existing recipes for building a static compiler
 that can be used in a static-only environment (with no ldd
 or linker present).

    
Steve
--

-- 
Christian JULLIEN | 7 Apr 16:30 2014
Picon

New warning on ARM since few commits

Hi all,

My RPi protests with:

libtcc1.c:588:26: warning: 'dl1.l.upper' may be used uninitialized in this function [-Wuninitialized]

Since this morning, culprit is:

   if (dl1.l.lower == 0 && dl1.l.upper == 0)                                                                                                                 
        return (0);             

/* only for x86 */                                                                                                                                            
union ldouble_long {                                                                                                                                          
    long double ld;                                                                                                                                           
    struct {                                                                                                                                                  
        unsigned long long lower;                                                                                                                             
        unsigned short upper;                                                                                                                                 
    } l;                                                                                                                                                      
};     

On RPi (ARM)
    printf("%d\n", sizeof(long double));
    printf("%d\n", sizeof(long long));

print
8
8

So, upper is not initialized

<div><p>Hi all,<br><br>My RPi protests with:<br><br>libtcc1.c:588:26: warning: 'dl1.l.upper' may be used uninitialized in this function [-Wuninitialized]<br><br>Since this morning, culprit is:<br><br>&nbsp;&nbsp; if (dl1.l.lower == 0 &amp;&amp; dl1.l.upper == 0)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; return (0);&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br><br>/* only for x86 */&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>union ldouble_long {&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>&nbsp;&nbsp;&nbsp; long double ld;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>&nbsp;&nbsp;&nbsp; struct {&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; unsigned long long lower;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; unsigned short upper;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>&nbsp;&nbsp;&nbsp; } l;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>};&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br><br>On RPi (ARM)<br>&nbsp;&nbsp;&nbsp; printf("%d\n", sizeof(long double));<br>&nbsp;&nbsp;&nbsp; printf("%d\n", sizeof(long long));<br><br>print<br>8<br>8<br><br>So, upper is not initialized<br></p></div>
Domingo Alvarez Duarte | 6 Apr 12:19 2014
Picon

Is this ok on commit "Use proper PLT/GOT for -run"

Hello !

When applying this commit to my fork, I'm not sure if it's correct:

------------

diff --git a/tcc.h b/tcc.h
index 76f25bd..5033b19 100644 (file)
--- a/tcc.h
+++ b/tcc.h
<at> <at> -712,7 +712,7 <at> <at>  struct TCCState {
     void *write_mem;
     unsigned long mem_size;
 # endif
-# if !defined TCC_TARGET_PE && (defined TCC_TARGET_ARM)
+# if !defined TCC_TARGET_PE && (0) ////<<<<<<<<<<<<<<<< is this correct ?????
     /* write PLT and GOT here */
     char *runtime_plt_and_got;
     unsigned runtime_plt_and_got_offset;
<div><div dir="ltr">
<div class="">Hello !
</div>
<div class=""><br></div>
<div class="">When applying this commit to my fork, I'm not sure if it's correct:</div>
<div class=""><br></div>
<div class="">------------</div>
<div class=""><br></div>
<div class="">
<span class=""><a class="" href="http://repo.or.cz/w/tinycc.git/commit/01c041923474750a236da02561f0f8835445848b">arm: Use proper PLT/GOT for -run.</a><a class="" href="http://repo.or.cz/w/tinycc.git/commit/01c041923474750a236da02561f0f8835445848b"></a></span>
</div>
<div class="">
<a title="tree root" href="http://repo.or.cz/w/tinycc.git/tree/01c041923474750a236da02561f0f8835445848b">[tinycc.git]</a> / <a title="tcc.h" href="http://repo.or.cz/w/tinycc.git/blob_plain/01c041923474750a236da02561f0f8835445848b:/tcc.h">tcc.h</a><br>
</div>
<div class="">
<div class="">
<div class="">
<div class="">diff --git <a class="" href="http://repo.or.cz/w/tinycc.git/blob/76f25bd5e7950f470b3d7bcafa8a0dc467a0ed9d:/tcc.h">a/tcc.h</a> <a class="" href="http://repo.or.cz/w/tinycc.git/blob/5033b19bd6a285df2988843fe03c99b479dafc9e:/tcc.h">b/tcc.h</a>
</div>

<div class="">
index <a class="" href="http://repo.or.cz/w/tinycc.git/blob/76f25bd5e7950f470b3d7bcafa8a0dc467a0ed9d:/tcc.h">76f25bd</a>..<a class="" href="http://repo.or.cz/w/tinycc.git/blob/5033b19bd6a285df2988843fe03c99b479dafc9e:/tcc.h">5033b19</a> 100644<span class=""> (file)</span><br>
</div>
<div class="">--- a/<a class="" href="http://repo.or.cz/w/tinycc.git/blob/76f25bd5e7950f470b3d7bcafa8a0dc467a0ed9d:/tcc.h">tcc.h</a>
</div>
<div class="">+++ b/<a class="" href="http://repo.or.cz/w/tinycc.git/blob/5033b19bd6a285df2988843fe03c99b479dafc9e:/tcc.h">tcc.h</a>
</div>
<div class="">
<span class=""> <at>  <at>  <a class="" href="http://repo.or.cz/w/tinycc.git/blob/76f25bd5e7950f470b3d7bcafa8a0dc467a0ed9d:/tcc.h#l712">-712,7</a> <a class="" href="http://repo.or.cz/w/tinycc.git/blob/5033b19bd6a285df2988843fe03c99b479dafc9e:/tcc.h#l712">+712,7</a>  <at>  <at> </span><span class="">&nbsp;struct&nbsp;TCCState&nbsp;{</span>
</div>

<div class="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;void&nbsp;*write_mem;</div>
<div class="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;unsigned&nbsp;long&nbsp;mem_size;</div>
<div class="">&nbsp;#&nbsp;endif</div>
<div class="">-#&nbsp;if&nbsp;!defined&nbsp;TCC_TARGET_PE&nbsp;&amp;&amp;&nbsp;(defined&nbsp;TCC_TARGET_ARM)</div>
<div class="">+#&nbsp;if&nbsp;!defined&nbsp;TCC_TARGET_PE&nbsp;&amp;&amp;&nbsp;(0) ////&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt; is this correct ?????</div>
<div class="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;/*&nbsp;write&nbsp;PLT&nbsp;and&nbsp;GOT&nbsp;here&nbsp;*/</div>
<div class="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;char&nbsp;*runtime_plt_and_got;</div>
<div class="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;unsigned&nbsp;runtime_plt_and_got_offset;</div>
</div>
</div>
</div>
</div></div>
lifenjoiner | 5 Apr 15:54 2014

how to make symbol '_SymLoadModuleEx <at> 36' match its defination of 8 argv

Hi there,

Sorry for the previous incomplete email.

I'm on windows, and used the dbghelp.dll's function SymLoadModuleEx and
SymLoadModule64.
The problem is that they will get 9 argv when compiled! You can debug to
confirm.

As dbghelp.chm says:
DWORD64 WINAPI SymLoadModuleEx(
  __in          HANDLE hProcess,
  __in          HANDLE hFile,
  __in          PCTSTR ImageName,
  __in          PCTSTR ModuleName,
  __in          DWORD64 BaseOfDll,
  __in          DWORD DllSize,
  __in          PMODLOAD_DATA Data,
  __in          DWORD Flags
);

DWORD64 WINAPI SymLoadModule64(
  __in          HANDLE hProcess,
  __in          HANDLE hFile,
  __in          PCSTR ImageName,
  __in          PCSTR ModuleName,
  __in          DWORD64 BaseOfDll,
  __in          DWORD SizeOfDll
);

They both have the DWORD64 format argv.

Can any body help?

lifenjoiner | 5 Apr 15:31 2014

(no subject)


DWORD64 WINAPI SymLoadModuleEx(
  __in          HANDLE hProcess,
  __in          HANDLE hFile,
  __in          PCTSTR ImageName,
  __in          PCTSTR ModuleName,
  __in          DWORD64 BaseOfDll,
  __in          DWORD DllSize,
  __in          PMODLOAD_DATA Data,
  __in          DWORD Flags
);

Aharon Robbins | 4 Apr 10:49 2014

Building a 32 bit cross compiler on x86_64 Linux?

Hi All.

What is the magic incantation to build an i386 version of tcc running
on x86_64 Linux?  It looks like 'make i386-tcc' builds the compiler itself.
After installing that, though, tcc -m32 hello.c fails to find the C
runtime start off and library files.

I'm on Ubuntu 12.04, and I have all the i386 libraries and stuff installed;
gcc -m32 works just fine. Same for clang.

Much thanks!

Arnold


Gmane