Re: [Tinycc-devel] trying to make absolute jump

[grischka via Tinycc-devel]

On 22.04.2024 06:16, Paul Moore wrote:

Weird processor. It only supports absolute jumps. So this is something that 
needs to be fixed up during link time. I do not know the elf details well 
enough to be able to work out how to do it

Seems like I need the jmp instruction to be a have reloc that refers to a 
symbol that matches the jump destination, say “dest1”. So I need a reference to 
Symbol “dest1” at the jump site and a definition generated later (by 
gsym_addr). Can I even do that , have a reference to a symbol that I export but 
want resolved at link time and not have ELF go “well I know that symbol, its 
right here”


Hi,

certainly it's easily possible, however assuming this 16-bit 'hack'
computer/processor doesn't really have an operating system capable
to load ELF files and hence assuming that you probably want to go
with the -Wl,-oformat=binary option, you can get away without relocation
at all.

You'd simply replace the relative patch in gsym_addr()
write32le(ptr, a - t - 4);
by an absolute one, for example
write16le(ptr, a + LOAD_ADDRESS);

where LOAD_ADDRESS obviously is where the program is supposed to be
loaded.

By the way, if you prefer to start hacking with something more
simple, maybe you want to have a look at tinycc's initial revision

https://repo.or.cz/tinycc.git/commitdiff/initial

which already can compile itself, almost at least. (IIRC parsing
for 0x... hex numbers needs to be added and the #ifdefs need to
be removed.  It can handle "#define SYM VAL" though.  Also the
vac and/or vat table should be initialized with '0', IIRC)

-- gr



I thought that maybe computed goto offered a way to prise the lid off this, but 
no , that doesn’t not work the same way.




___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] TinyCC on Windows & some suggestions

[grischka via Tinycc-devel]

On 11.03.2024 20:38, Robert Schlicht wrote:
> Yes, it is. But it’s really primitive, basically just a text editor that has 
the compiler integrated, and calling it an IDE may be an exaggeration. It’s the 
thing that is intended to make writing a “Hello, World!” program (and slightly 
more interesting stuff) as painless as possible for beginners.

But still really sleek, how it's "self-hosted", in a surprising way...

I pushed some changes based on your suggestions:
https://repo.or.cz/tinycc.git/commitdiff/2b0a663df9236763c3967575e2c0fb89a9e58566

-- gr

>

Robert


Jake Anderson (2024-03-11 15:10):

Is the IDE open source? An IDE that is packaged separately and uses the TCC
compiler could be useful.

On Sun, Mar 10, 2024 at 1:01 PM Robert Schlicht  wrote:


At our university we offer a course where we program simple spatial
simulations in various programming languages, one of them being C, for
illustrating close-to-the-machine programming concepts. We here need a C
implementation that is small (since it’s accessed over a network), works
out of the box on Windows computers (since our students are beginners) and
runs fast (so compiler errors are available instantaneously). We do not
need advanced developer tools, and code running three times slower is
acceptable because that is still faster than scripting languages.

TCC is obviously a good option here, and for our course starting in April
of this year, I put together a package https://rschlicht.eu/tc-ide.zip
that includes a minimalist IDE running TCC and a very basic form of a C
standard library, all contained in a standalone executable tc-ide.exe. The
library is just headers that directly access the Windows API (no runtime
needed) and should satisfy the requirements of a conforming freestanding
implementation, while also including common memory, file, math and the
printf family of functions. (If anyone finds this useful, I’ll gladly
contribute it to the TCC project.)

The executable is compiled by itself, although this currently requires a
few hacks and workarounds to get it working as desired. I list these here
as suggestions for improving TCC:

(1) For using TCC as a library, it would be nice if it did a more thorough
cleanup:
– In a few places exit() is called in case of failure, but terminating the
program is not very user-friendly; cleanly propagating failure or even some
longjmp hacks might provide a better solution. [tc-ide does the latter,
while patching function calls to keep track of memory and open files.]
– Another problem I encountered is that TCC does not always properly
restore the state of the global variables; compiling the following code
fragment the first time produces an error message (as it should), but the
second time it causes an exception (which I assume is a bug):
 void nothing(void) {for ( ; ; ) break;}  void garbage(void) {switch
[The workaround in tc-ide is ugly but straightforward: Make a copy of the
memory block containing all global variables, and restore this block after
TCC returns.]

(2) I really appreciate that TCC can directly link to functions in Windows
DLLs with no auxiliary .lib file and that it even supports directives like
#pragma comment(lib,"kernel32"). The current implementation of the DLL
lookup with a huge number of lseek & read calls (via read_mem() in tccpe.c)
may be inefficient on some file systems. [tc-ide avoids this issue by
creating file mappings in memory and redirecting lseek and read to those
memory buffers, which it has to deal with anyway to access the embedded
headers.]

(3) The C23 preprocessor directive #embed would be of help for embedding
headers and other files as byte arrays in the program. [tc-ide currently
does this by providing a non-standard feature with a custom notation like
#include "stdlib.h#".]

(4) TCC uses fixed buffer sizes for file paths in certain places. For
example, libtcc.c has 260(=MAX_PATH) in config_tccdir_w32() and
_fullpath(), 1000 in tcc_add_systemdir() and 1024 in
tcc_add_library_internal(), while tccelf.c has 1024 in getcwd(). Windows
has been supporting long file paths for quite a while now, so it might be
better to allocate those buffers dynamically:
https://learn.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation

(5) Some rarely used C library functions could perhaps be replaced to make
the code less dependent on such features. Examples are the single use of
alloca() in libtcc.c to set up a buffer and the use of scanf() in tccpp.c
to convert the TCC version string into a number. [tc-ide here provides
stubs.]

(6) It would be useful to allow the user to set the entry point symbol
(either the one called by the OS or the one called by the startup code),
like other compilers do. [tc-ide provides its own version of _start(),
which simply calls main().]

(7) Additional observations:
– In tcc_new() (tcclib.c), checking the return value of tcc_mallocz is
probably redundant.
– In tcc_close() (tcclib.c), I do not understand why the test is ">0"

Re: [Tinycc-devel] Minimizing libtcc memory use

[grischka via Tinycc-devel]

On 08.03.2024 07:30, Eric Raible wrote:

I guess that I just want the numbers to add up.
Using your example:

1) -DMEM_DEBUG -DCONFIG_RUNMEM_RO=0
2) your test.c
3) but I added an early return to tcc_delete() to no-op it

Running: valgrind tcc -nostdlib -vv -bench -run test.c
produced:

tcc version 0.9.28rc 2024-03-03 mob@9d2068c6* (AArch64 Linux)
-> test.c
-
0: .text0x4ccb000  len 00020  align 1000
1: .data.ro 0x4ccb020  len 4  align 0008
2: .data0x4ccb028  len 4  align 0008
2: .bss 0x4ccb030  len 4  align 0008
-
protect rwx 0x4ccb000  len 01000
-
# 3030 idents, 4 lines, 92 bytes
# 0.463 s, 8 lines/s, 0.0 MB/s
# text 32, data.rw  4, data.ro  4, bss 4 bytes
# memory usage: 8192 to run, 649 symbols, 2901 other, 1639290 max (bytes)
mem_cur_size=11742 (bytes)



So tcc_print_stats() says 11742, but then displays values totaling 11786.


What 11786 ?

8192 + 649 + 2901 = 11742

> ==2188==
> ==2188== HEAP SUMMARY:
> ==2188== in use at exit: 14,814 bytes in 32 blocks
>
> And valgrind reports 14814.  I have never seen valgrind wrong about this,
> and especially so b.c. my (luckily-correct) allocator reported 14814 as well.

There is nothing wrong here:  11742 + 32 blocks * 96 = 14814
Where 96 is the size of tcc's mem_debug extra header.

If you want to see the 11742 from valgrind then you just need to
run the same example with a normal tcc compiled without MEM_DEBUG.

Which makes sense I would think.

But when showing the example with MEM_DEBUG and -bench -vv  I
did not expect you to doubt the numbers in the first place.

Rather I just was trying to show how you could get some numbers
for your own real case instead.  Which as you suspect could be
minimized from 29kB down to 1-2 kB.  Most likely impossible but
if we had some numbers we could tell also why.

-- gr


___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Minimizing libtcc memory use

[grischka via Tinycc-devel]

On 03.03.2024 21:26, Eric Raible wrote:

 > isn't there a garbage collecting done at the end to remove all the unused 
stuff
 > to produce a binary that contains only the necessary parts ?

That very well might be the case, but given that tcc_get_symbol()
can be used at any time between tcc_relocate() and tcc_delete(),
it follows that _at least_ symbols are resident in the TCCState.
What I'm wondering about is the feasibility of keeping just code and
data, and flushing everything else.  This would require a new API -
something like tcc_finalize(TCCState *) or perhaps
tcc_finalize(TCCState *, flags), where flags specify what to flush.


Me thinks this discussion is going around in circles.

Your tcc_finalize() subject of obsession was what we already had
all the time since 0.9.25, that is the option to allocate the
executable code separately from the state and therefor the option
to delete (finalize) the state and still keep the code.

It just happened that at some point people found that tcc not only
should allow them to have the cake for their own, but that they
also want tcc to provision them with some extra convenience to
cleanup with it (including unprotect and release of the unwind
table on win64).

At which point I found that maintaining two options for running
code might not be to the best for both sides, neither for tcc wrt.
maintainability nor for users wrt. avoidance of inconvenience.

Of course now that we have that simpler API, it was clear that
soon someone would come up suspecting some benefit if it were not
only simple but complicated too, optionally of course.

Where simple plus complicated is more complicated than just
complicated btw.

And while it's completely unclear what such benefit could be,
under what scenario.


I don't know enough about the internals, but if I'm willing to run with
CONFIG_RUNMEM_RO, it seems like the per TCCState memory use in my case
could be decreased from something like 29K to 1K or 2K.

I should mention that the memory usage in my case is 29K regardless
of whether CONFIG_RUNMEM_RO is 0 or 1.


How do you know this?

Some output from tcc -nostlib -vv -bench -run test.c
(tcc compiled with -DMEM_DEBUG -DCONFIG_RUNMEM_RO=0)

  int x = 1; //.data
  int y; // .bss
  const int z; // .rdata
  int _start() { return 0; } //.text

tcc version 0.9.28rc 2024-03-04 mob@d4f7fcbb* (i386 Windows)
-> test.c
-
memory  007B6390  len 02000
-
0: .text007B7000  len 00018  align 1000
1: .rdata   007B7040  len 4  align 0040
2: .data007B7044  len 4  align 0004
2: .bss 007B7048  len 4  align 0004
-
protect rwx 007B7000  len 01000
-
# 1074 idents, 6980 lines, 137488 bytes
# 0.001 s, 698 lines/s, 137.5 MB/s
# text 17, data.rw 4, data.ro 4, bss 4 bytes
# memory usage: 10250 bytes (8192 to run, 499 for 14 symbols, 1559 for state 
etc)

Which is 8kB to run and 2kB extra.

Same for -run tcc.c
-
memory  00E159D8  len 63000
-
0: .text00E16000  len 43418  align 1000
1: .rdata   00E59440  len 08c00  align 0040
2: .data00E62040  len 00311  align 0004
2: .bss 00E62358  len 15938  align 0008
-
protect rwx 00E16000  len 44000
-
# 29262 idents, 99132 lines, 3377368 bytes
# 0.202 s, 490752 lines/s, 16.7 MB/s
# text 270677, data.rw 4, data.ro 35789, bss 88112 bytes
# memory usage: 413204 bytes (405504 to run, 6030 for 158 symbols, 1670 for 
state etc)

Where the 4 bytes initialized data.rw btw. is Eric Raible's
static void *(*reallocator)(void*, unsigned long) = default_reallocator;

-- gr



Thanks - Eric



___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] TCC compiling TCC

[grischka via Tinycc-devel]

On 02.03.2024 20:15, Jake Anderson wrote:

When compiling TCC using TCC, there is an error about missing _strtoui64 in 
msvcrt.dll on Windows 2000 and older. This does not occur when using old 
versions of GCC to compile TCC.


Maybe you want to replace
in tcc.h
#  define strtoull _strtoui64
by
#  define strtoull strtoul

You just cannot use 64-bit numbers in the assembler then.

-- gr

___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] tcc assembler emits wrong pc-relative symbol difference reloctions in immediates

[grischka via Tinycc-devel]

On 01.03.2024 17:32, Rich Felker wrote:

The relocation emitted is the pc-relative address based on the
beginning of the add opcode, but it needs to be based on the beginning
of the immediate operand in the add opcode.


I just moved the addition of (ind + 4)

https://repo.or.cz/tinycc.git/commitdiff/ca061f3a96216f85f6fe72868083208aa0a740b9#patch2
to where the operand is put.

https://repo.or.cz/tinycc.git/commitdiff/ca061f3a96216f85f6fe72868083208aa0a740b9#patch1
thanks, -- gr



diff --git a/i386-asm.c b/i386-asm.c
index e134d804..63cfbf6b 100644
--- a/i386-asm.c
+++ b/i386-asm.c
@@ -738,6 +738,8 @@ ST_FUNC void asm_opcode(TCCState *s1, int opcode)

  s = 0; /* avoid warning */

+int ind0 = ind;
+
  again:
  /* optimize matching by using a lookup table (no hashing is needed
 !) */
@@ -1153,6 +1155,7 @@ again:
} else if (pa->op_type[i] == OPT_DISP || pa->op_type[i] == 
OPT_DISP8) {
  gen_disp32([i].e);
  } else {
+if (ops[i].e.pcrel) ops[i].e.v += ind-ind0;
  gen_expr32([i].e);
  }
  }

Please CC me on replies, as I'm not subscribed.

Rich

___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel




___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] problem on win64 with latest commit

[grischka via Tinycc-devel]

On 01.03.2024 07:49, Herman ten Brugge via Tinycc-devel wrote:

On 2/29/24 23:17, grischka wrote:

On 29.02.2024 07:26, Herman ten Brugge via Tinycc-devel wrote:

Setting CONFIG_RUNMEM_RO=0 looks incorrect to me because it sets write in 
executables.
Apple has implemented W^X (Writes can not occur in executables) for security 
reasons.
This may also be implemented in in future linux/bsd releases.


Using CONFIG_RUNMEM_RO=1 may be the right thing to do in
future, however there was a severe off-bounds problem with
the un-mprotect call which I just fixed.  Maybe that was
the reason?


This did not work. We still use 'PROT_READ | PROT_WRITE | PROT_EXEC'.
Apple does not support that for security reasons.


Last time you mentioned "Apple W^X", which according to
   
https://developer.apple.com/documentation/apple-silicon/porting-just-in-time-compilers-to-apple-silicon
would require mmap(), MAP_JIT, and some pthread_jit_write_protect_np()
to work around.

Since that is not what tcc has I was concluding that something else
must be at work.


Why do you want CONFIG_RUNMEM_RO=0? It was allways set to 1 before
and that worked fine on all targets I can test (about 20).
You changed it in "tccrun: resign from "advanced" system calls 
(memaligh/gettid)" on feb 25.
Why?


Some things have been simplified lately, the second argument to
tcc_relocate() was removed, memalign was removed, etc. So in the
course of going back to more simplicity, I did change that in
order to see whether it still would work.

Now it seems that it would work in most cases,  except that it doesn't
on "Apple Silicon M1 arm64". If that is what you're saying.

Btw. I've seem some Apple arm64 related patches in
   https://github.com/frida/tinycc/commits/main/
such as
   
https://github.com/frida/tinycc/commit/263232e8cf53991f195d7f7c028488cbd6f6b117

Anyway, I have no problem setting CONFIG_RUNMEM_RO=1 at all, we just
need to be aware that it increases run-memory size by additional two
pages.  Since we also dropped memalign,  the minimum run-memory size
with CONFIG_RUNMEM_RO=1 now is 3 pages plus one for alignment, that is
minimum 16 kB (4 x 4096 bytes).

-- grischka



 Herman

___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel



___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] problem on win64 with latest commit

[grischka via Tinycc-devel]

On 29.02.2024 07:26, Herman ten Brugge via Tinycc-devel wrote:

Setting CONFIG_RUNMEM_RO=0 looks incorrect to me because it sets write in 
executables.
Apple has implemented W^X (Writes can not occur in executables) for security 
reasons.
This may also be implemented in in future linux/bsd releases.


Using CONFIG_RUNMEM_RO=1 may be the right thing to do in
future, however there was a severe off-bounds problem with
the un-mprotect call which I just fixed.  Maybe that was
the reason?

-- grischka



Can I revert the change and set CONFIG_RUNMEM_RO=1 for all targets as before?

 Herman


___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel




___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] problem on win64 with latest commit

[grischka via Tinycc-devel]

On 26.02.2024 19:55, Herman ten Brugge via Tinycc-devel wrote:

I commited a change to lib/runmain.c to silence a warning from gcc.
After that testcase 112 did not work any more on 64 bits windows (tested with 
wine).

I can fix this with fix1 (see below) or fix2 (see below).
I do not know enough about windows to make the correct fix.
Both fix1/fix2 look not correct to me.


Hi Herman,

well, first we'd need to know what problem we want to fix.  Maybe
the problem is not in tinycc at all.

Also, the obvious to avoid that gcc warning IMO would be using:

__attribute__((noreturn)) void __rt_exit(rt_frame *, int);

Also, while at it:

# ifdef _WIN32
#   define CONFIG_RUNMEM_RO 0
# else
#   define CONFIG_RUNMEM_RO 1
# endif

would suggest a special case needed for windows.  However that is not
the case.  Whereas according to your comment, the exception is APPLE
actually.  So we'd better say #ifdef __APPLE__ or just use '1' for all
and leave a comment that it's needed for APPLE.

Although tests on github actions did not show such problem, at least
not on macos-11.  Note that CONFIG_RUNMEM_RO was first introduced with
.rodata sections in commit 72f1dea5372ed551d203311e4f2ab769a54de9bd
from 2021-02,  and it seems that tcc already did work on MacOS even
before that commit.  If those previous commits still work then the
problem now might be elsewhere.

Anyway, we cannot disable the runtime-function-unwind table because
without it longjmp() would crash on (a real) _WIN64.

Also obviously, if __rt_exit doesn't return, then any code after it
cannot have any effect:


  __rt_exit(, code);
+abort (); // avoid noreturn warning


I'd assume something weird going on with set/longjmp of WINE and/or
the mingw-gcc that you use.  In any case it is important that
setjmp/longjmp/jmp_buf implementations do match each other.

Which is why I made it so that tcc_setjmp records the longjmp
function pointer too because otherwise it could end up using the
longjmp from libtcc.dll/so and the setjmp from the application
that links to it, with possibly different concepts each. (Not
sure if/where it really can happen though).

-- grischka



 Herman

fix1:
diff --git a/lib/runmain.c b/lib/runmain.c
index 1cbf6dd..307bf45 100644
--- a/lib/runmain.c
+++ b/lib/runmain.c
@@ -60,6 +60,7 @@ typedef struct rt_frame {
  } rt_frame;

  void __rt_exit(rt_frame *, int);
+void abort(void);

  void exit(int code)
  {
@@ -69,7 +70,7 @@ void exit(int code)
  f.fp = 0;
  f.ip = exit;
  __rt_exit(, code);
-for (;;); // avoid noreturn warning
+abort (); // avoid noreturn warning



  }

  #ifndef _WIN32

fix2:
diff --git a/tccrun.c b/tccrun.c
index b27ccc5..5ea271e 100644
--- a/tccrun.c
+++ b/tccrun.c
@@ -456,7 +456,7 @@ static int protect_pages(void *ptr, unsigned long length, 
int mode)
  static void *win64_add_function_table(TCCState *s1)
  {
  void *p = NULL;
-if (s1->uw_pdata) {
+if (0&>uw_pdata) {
  p = (void*)s1->uw_pdata->sh_addr;
  RtlAddFunctionTable(
  (RUNTIME_FUNCTION*)p,


___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel



___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Newest TCC builds broken on legacy Windows versions on GCC 4.5.2

[grischka via Tinycc-devel]

On 25.02.2024 11:02, Eric Raible wrote:

If build with:
-DCONFIG_RUNMEM_ALIGNED=0
I'm hoping you'd be good to go.


Don't mind, I reverted the usage of those "more recent" system
features (as in memalign() & gettid()).  Simpler code, less
problems ...

-- grischka



On linux one would:
./configure --extra-cflags=-DCONFIG_RUNMEM_ALIGNED=0

On windows I'm not sure, but perhaps augmenting the lines in
win32/build-tcc.bat to look like this would do the same:

set D32=-DTCC_TARGET_PE -DTCC_TARGET_I386 -DCONFIG_RUNMEM_ALIGNED=0
set D64=-DTCC_TARGET_PE -DTCC_TARGET_X86_64 -DCONFIG_RUNMEM_ALIGNED=0

- Eric


On Sat, Feb 24, 2024 at 7:29 AM Dog Dog mailto:andreywilliamsjeff...@gmail.com>> wrote:

I get an error about missing entry point _aligned_free in msvcrt.dll. Since 
the newest builds are labeled as TCC version 0.9.28 RC one could wait until 
after an official TCC version 0.9.28 to break compatibility with legacy Windows 
versions.

The newest builds of TCC are broken on Windows 2000, Windows NT 4.0, 
Windows NT 3.51, Windows Me, Windows 98 and Windows 95. I realize that old 
versions of Windows can't be supported forever and that is an amazing level of 
compatibility for builds prior to recent builds.

The problem started with this build:

https://repo.or.cz/tinycc.git/commit/7b9f19eaab7e568a7c7a42725da812377a588f50
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org <mailto:Tinycc-devel@nongnu.org>
https://lists.nongnu.org/mailman/listinfo/tinycc-devel



___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel




___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] A couple of questions

[grischka via Tinycc-devel]

On 12.02.2024 15:35, George Sedov wrote:

Hi all,

First of all, I noticed that throughout the codebase there is a mix of spaces 
and tabs. This makes it very difficult to produce out-of-tree patches, since 
most of the editors will replace tabs with spaces. Is there a reason behind it?


Obviously then the reason must be that most people here did not
use "most of the editors" ... ;)



The second question is about the bounds check. In the current implementation it 
is common to first access the provided pointer, and only after that check if it 
is valid or not (e.g. the __bound_str* functions). Doesn't it defy the whole 
purpose of the functions? What is the intended usecase of this feature?


I guess the intention is to warn you about potential problems,
rather than about problems that you already have (crashes or
sume such).

-- gr



BW,
George



___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Question about in-memory compilation, target

[grischka via Tinycc-devel]

On 11.02.2024 11:08, draco via Tinycc-devel wrote:

You're right, I didn't verify closely, but the ABI is still intact. Sorry...


To be nice I've made tcc_relocate() abort with a notice
when it's called with the former two-step method ;)

-- gr



Am 10.02.24 um 22:12 schrieb Eric Raible:

> This means, that not only the public API changes, but also the
> libtcc.dll/so ABI, making all programs using libtcc crash without warning.
>
> Is this intended?
>
> Michael
I just tried it.  It looks like only programs that _don't_ use
TCC_RELOCATE_AUTO would be affected (at least on my x86_64 debian box).
Looks like the breakage would only be in a program uses manual memory 
management,
that uses the system tcc (instead of a private  version), and where the system 
tcc is
updated w/out rebuilding the application.  Anyone out there who would be in 
that situation?
- Eric



___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel




___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Question about in-memory compilation target

[grischka via Tinycc-devel]

On 09.02.2024 01:44, Eric Raible wrote:

 > Then, instead of adding a new API to support the
 >  "run without state"
 > option better (as you suggest), we could just as well remove that
 > option entirely, and have a simpler and more "lovely" API then ...
 >
 > What do you think?
 >
I think removing that option entirely would be fine.  Others might disagree.
But if we _keep_ that option, then we should have tcc_unprotect().
With respect to "tweak the state a bit", that sounds risky if we're really
trying to stabilize for a release.


Ok, I like it to remove stuff:
https://repo.or.cz/tinycc.git/blob/b671fc0594625eb5ac147ec83be6d0c1fc1a6ad5:/libtcc.h


On an unrelated note, there was a commit a while back that proposed putting 
more into
TCCState, such that no global state at all exists.  I am in favor of that 
proposal, which
kind of implies an even bigger TCCState.


Yeah, answer is always the same:
- eyes would hurt from seeing "s1->" all over the place
- finger would hurt for those who'd like to contribute
- not to mention what if you'd try to rebase some patch that you already have
See also
https://repo.or.cz/tinycc.git/commitdiff/af686a796bda94dc92fc3ad140ef438dafa08950

--- grischka

___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Question about in-memory compilation target

[grischka via Tinycc-devel]

On 07.02.2024 09:38, Eric Raible wrote:
> The alternative is having to know about messy system-dependent details,
> which seems very much against the spirit of the (lovely) libtcc API.

Well, if it's "lovely" then maybe because it's still small and
fairly easily to read.

In any case, there is always a conflict between simplicity
and any new addition, even if they may come very convenient
in some case.

Maybe you (or other people) could tell a bit more why now that
tcc_set_realloc()
can be useful enough that tcc should have it, more exactly?

And if so, why then do we need
tcc_get_realloc()
too?  Is that just an exercise about "setters" and "getters" or
is it really useful?

While at it, why do we need these ones
tcc_get_error_func()
tcc_get_error_opaque()
seen that people should be able to remember what they have set,
in their own code too?

As to "tcc_relocate()" and "tcc_unprotect(mem)", that would
probably good to have.  On the other hand it's already built-in
into tcc_delete().

Maybe it is not worth to keep up that option to compile into
memory provided by the user at all.  If we'd tweak the state
data a bit to keep only the minimum required instead,

for example with "tcc -run tcc.c -v"

code size:
- 421047 bytes

state data sizes:
- 1088 bytes : struct TCCState itself (on i386)
- 5649 bytes : public symbols (= 160 public symbols ~= 35 bytes each)
-  546 bytes : file names, include paths, defines, etc.
-
  7283 bytes total

Which means that in this case the state data is less than 2% of
the total memory usage.

Then, instead of adding a new API to support the
 "run without state"
option better (as you suggest), we could just as well remove that
option entirely, and have a simpler and more "lovely" API then ...

What do you think?

-- grischka


When using

void *mem = malloc(tcc_relocate(s, NULL));
tcc_relocate(s, mem);

wouldn't it make sense for tcc to export a function to safely
restore the pages to R/W in a platform independent way?

I haven't been able to untangle tcc_relocate() -> tcc_relocate_ex() ->
set_pages_executable(), but it seems to me that since tcc sizes and then
populates the 'mem' from above, it could certainly add metadata to allow
a helper could undo the page protection and any other platform-specific
actions that are required before free()-ing the memory.

Perhaps something like tcc_unprotect(mem), which would only be allowed
when one is done with the memory passed to tcc_relocate().

The alternative is having to know about messy system-dependent details,
which seems very much against the spirit of the (lovely) libtcc API.

Comments?




___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Variable declaration as first statement in a 'case' block gives error.

[grischka via Tinycc-devel]

On 19.01.2024 07:18, Herman ten Brugge via Tinycc-devel wrote:

I wanted to avoid an extra check for ';' because I found code like:

 case xxx: ; }

Instead of writing 'break;' they used ';'.
Without checking for ';' a warning was printed:


Always same problem: we want something and do something else.

Anyway, what you told tcc is to accept declarations instead of
an expression, alternatively:

-} else {
+} else if (!decl(VT_JMP)) {
 gexpr();
 vpop();


Which is what happens.  Current tcc accepts:

if (x)
int y;
else
int z;


So how about the next patch:
C23: Implement declaration after label (see attached patch)


block_after_label:
...
if (tok != ':')
decl(VT_LOCAL);
if (tok != '}')
goto again;
/* we accept this, but it is a mistake */
tcc_warning_c(warn_all)("deprecated use of label...

Yes, I'd read this as "accept declarations after a label", too.
So it might be what you want, but is it C23?

Because then, to have a declaration where it was not possible
previously, we'd now just need to put a label in front:

Not accepted
  if (x)
  int n;
  for (n = 0; n < x; ++n)
   ;
  else ...

Accepted:
  if (x)
  decl_please: int n;
  for (n = 0; n < x; ++n)
   ;
   else ...

I'd think that feels a bit strange, because the label would not
serve any purpose other than to support the declaration.

And of course, if that is C23, then people then will start to
write this.

-- gr

___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] looking for documentation for porting

[grischka via Tinycc-devel]

On 16.01.2024 00:38, Michael Larson wrote:

Hello,

I have been tinkering around with TCC porting to a RISC cpu of my own
design, I have my own C simulator and verilog targeted for a FPGA.. I
have a lot of tests for functionality, but I need more so TCC looked
like a good option to generate code for.

I have been following some of the code samples given like the C67 and
MIPS source, I have about half of it done but documentation on how
this works seems to be really missing.

I did a normal port, I copied all the functions out of the header
files required and built a C file for them. This worked well... but..
there are a lot of questions.

Like

int gjmp_cond(int op, int t)

I look around the source and see a bunch of different implementations
of this, but there is no documentation on how it's supposed to work? I
am sure I could dig into it a bit more.. but it's time to ask where
the documentation is, maybe I am missing something.. is there
documentation out there?


No, because it's really so simple ;)

It's simply supposed to put the conditional jump opcode
as given in 'op', fill its address field with 't', and
return the offset of that field (ind - 4 after it was put).

There is also

 void gsym_addr(int t, int a)

which then is supposed to replace the field at offset 't'
with address 'a', and continue to do so with the former
contents of that field unless it's zero.

As you can see to write this little documentation already
was much more effort than it ever was or would be just to
write or read those functions. ;)

Other than that, the maybe as simple as possible single file
implementation of that stuff may be found in the first revision
of the repo here

   https://repo.or.cz/tinycc.git/blob/27f6e16b:/tcc.c

You'll find that for example the 'if' statement code in block()
is still almost identical to how it is now.

   https://repo.or.cz/tinycc.git/blob/27f6e16b:/tcc.c#l780

--- gr


I only have a few functions left so I am not going to give up at this point.

Thanks ahead of time,

Mike



ST_FUNC int gjmp_append(int n, int t)
{
printf("%s:%s unimplemented\n", __FUNCTION__, __FILE__);
return 0;
}

ST_FUNC void gen_opi(int op)
{
printf("%s:%s unimplemented\n", __FUNCTION__, __FILE__);
}

ST_FUNC void gen_opf(int op)
{
printf("%s:%s unimplemented\n", __FUNCTION__, __FILE__);
}

ST_FUNC void gen_cvt_ftoi(int t)
{
printf("%s:%s unimplemented\n", __FUNCTION__, __FILE__);
}

ST_FUNC void gen_cvt_itof(int t)
{
printf("%s:%s unimplemented\n", __FUNCTION__, __FILE__);
}

ST_FUNC void gen_cvt_ftof(int t)
{
printf("%s:%s unimplemented\n", __FUNCTION__, __FILE__);
}

ST_FUNC void ggoto(void)
{
printf("%s:%s unimplemented\n", __FUNCTION__, __FILE__);
}

ST_FUNC void gen_vla_sp_save(int addr)
{
printf("%s:%s unimplemented\n", __FUNCTION__, __FILE__);
}

ST_FUNC void gen_vla_sp_restore(int addr)
{
printf("%s:%s unimplemented\n", __FUNCTION__, __FILE__);
}

ST_FUNC void gen_vla_alloc(CType *type, int align)
{
printf("%s:%s unimplemented\n", __FUNCTION__, __FILE__);
}

___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel




___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Question about in-memory compilation target

[grischka via Tinycc-devel]

On 15.01.2024 00:51, Brad Robinson via Tinycc-devel wrote:

Questions:

1. Is it possible to keep, use and then release the compiled code after the 
initial compiler instance has been deleted


FYI below some version of libtcc_test.c to run without state.

Note the LoadDll is needed only when the exe itself was not
linked with msvcrt, i.e. to prevent it from being unloaded
in tccelf_delete.

-- gr

void *mem; int size; HANDLE dll; DWORD xxx;

if ((size = tcc_relocate(s, NULL)) < 0)
return 1;
tcc_relocate(s, mem = malloc(size));
if (!(func = tcc_get_symbol(s, "foo")))
return 1;
dll = LoadLibrary("msvcrt.dll");
tcc_delete(s);

func(32);

FreeLibrary(dll);
VirtualProtect(mem, size, PAGE_READWRITE, );
#if _WIN64
RtlDeleteFunctionTable(*(RUNTIME_FUNCTION**)mem);
#endif
free(mem);
return 0;

___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Variable declaration as first statement in a 'case' block gives error.

[grischka via Tinycc-devel]

On 18.01.2024 17:38, Herman ten Brugge via Tinycc-devel wrote:

That depends on the version of gcc / clang.
Gcc 13.2.1 prints no error.
Clang 17.0.6 prints "error: expected expression"
Clang 18.0.0(not released yet) prints "warning: label followed by a declaration is a 
C23 extension [-Wc23-extensions]"

I probably should have mentioned it when committing the fix.


Maybe yes.

Plus mention that it's not a fix, but an experiment
with undocumented non-standard syntax.

Plus mention the benefit and the price too, please.

Plus while at it, spend some thoughts first:

-} else {
+} else if (!decl(VT_JMP)) {
 gexpr();
 vpop();


Hm... just one line changed.  But wait, does not tcc look
for decl before expression already?  Sure it does because
it supports C99.  Why now look twice ?  And why skip parsing
the expression if where was a declaration?  What's the point?
Who wrote that?

Let's maybe try to use the tcov for tcc (which as we know was
you who wrote it and is really not bad btw):

$ tcc -ftest-coverage ../tcc.c -o tcc1.exe && tcc1.exe ../tcc.c -o tcc2.exe

tcc1.exe.tcov:
   -: 0:Function:decl 68.67%
Before:
  10701: 8417: int v, has_init, r, oldint;
After:
  18408: 8417: int v, has_init, r, oldint;

We note 7707 additional (+72%) calls for decl(),

  183: 7247:block_after_label:
 1006: 7248:  {

and that however only 1006 labels/cases/defaults were seen
at all.

Also we note no "label: decl" in tcc anywhere and also in
noone elses code we've seen so far (the OP's doesn't count
because it's generated C IIUC)

Now back to the "benefit vs. price" question ...

-- gr



 Herman



___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel



___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Variable declaration as first statement in a 'case' block gives error.

[grischka via Tinycc-devel]

On 15.01.2024 00:34, Brad Robinson via Tinycc-devel wrote:

Hey All,

First post here.  Firstly, thank you all for your work on this project.  I 
discovered tcc just a month or so ago and really enjoying using it as a 
back-end code generator for a custom scripting language I'm working on.

Anyway, I noticed this small bug:

A variable declaration as the first statement in a switch case block fails when 
it shouldn't:

 case 1:
 int z = 123;// This fails with "identifier expected"
 break;


Hi,

well, yes, no.  As a fact, a variable declaration is not a
statement.


There's a pretty easy workaround, just insert an empty statement before.

 case 1:
 ;   // This fixes it
 int z = 123;
 break;



Yes, label before statement is allowed, also label before empty
statement, just not label before no statement.

As for example "label: }" is not allowed either (in the theory).

See also what gcc has to say:

test.c: In function 'main':
test.c:7:23: error: a label can only be part of a statement and a declaration 
is not a statement
switch(a) case 1: int z;
  ^~~

Which of course if a lot better than just "identifier expected"
I would agree that far.

-- gr


(this was build of the mob repo on github - not sure if that affects things).

Brad


___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Outdated tcc: Major bug in the pow function resulting in: 0.993013 = 0.860892

[grischka via Tinycc-devel]

On 06.01.2024 01:10, Detlef Riekenberg via Tinycc-devel wrote:


Of course, there might be more issues in 0.9.28rc
As example, "i386-tcc" on a x86_64 linux machine
is missing additional search dirs:


Can we see the output of "i386-tcc -vv" ?


include: "/usr/i686-linux-gnu/include"
lib: "/usr/i686-linux-gnu/lib"
crt: "/usr/i686-linux-gnu/lib"

(there are no "crt*.o" files, "libc*" files and similar
in "/usr/lib/i386-linux-gnu")





Please do a release.
Please 
Please .



___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] [PATCH] Add support for reading thin archive files.

[grischka]

On 30.10.2023 08:41, Reimar Döffinger wrote:

+if (0 == memcmp(h, "!\n", 8))
+return AFF_BINTYPE_AR;
"!\n" looks like a candidate for a symbolic name not unlike ARMAG ?)


It seemed overkill at first since it was only used in one place,
but now that it's used in 2 places, yes.


Hi,  well, it probably shouldn't be used in two places.  You could
return AFF_BINTYPE_AR_THIN for example to avoid the redundant extra
check.

Is it that in your code I do notice some general tendency to
duplications?  Like
if (is_thin) size = 0;
if (is_thin && tcc_add_ar_thin_file(s1, filename, hdr.ar_name, 
fnames, fnames_size) != 0) {
...
Plus 2 locations where it reads the "//" long names.
Also in
"support for codesigning command"- Seem to recall that it already did exist ?!?
"-MP option" - quite some copy & paste (and a very big comment to my taste).
"delete created ar file on error" - "created_file": 'fh' already
means the file was created and argv[i_lib] has the name.

Anyway, as we know, providing two (or more) things to do (almost) the
same is a well proven method to cause confusion.  Try to get rid of that.

Also, not necessarily was tcc written with any not yet existing
features already in mind.  If you can organize existing stuff differently
to make the new feature fit more nicely, then why not ... ;)

-- grischka


Best regards,
Reimar


___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Do not load all referenced libraries, when linking a library

[grischka]

On 11.10.2023 11:34, Herman ten Brugge via Tinycc-devel wrote:

On 10/10/23 17:37, Michael Matz wrote:


Only runtime loaders are required to follow DT_NEEDED.  link editors aren't.  
There's no distinction between emitting a shared lib or an executable.  (And 
for OUTPUT_MEMORY, which might be said to make tcc behave like a runtime 
loader, it's actually dlopen which does the necessary DT_NEEDED following).


I understand. The original patch is ok.


I'd probably prefer just an "#if 0" around (also including the
DT_RPATH addition above btw), plus some comment why that
following DT_NEEDED tags is no longer relevant.

If that is what the conclusion from the discussion is ;)

Because as Detlef suggested, just the comment

+/* do not load all referenced DLLs */
+/* recursive loading can break linking of libraries */

with the code that it could refer to deleted doesn't make much sense
either, IMO.

-- grischka



 Herman



___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Minor error-reporting bug

[grischka]

On 02.10.2023 05:45, Eric Raible wrote:

It seems to me that "ST_FUNC void skip(int c)" needs to be smarter
about handling 'c',
perhaps formatting it into a string before calling tcc_error().  I
could (in theory) fix this,
but it looks like it would require refactoring get_tok_str() to not
use the global cstr_buf).

> A bit above my pay grade.

I guess in tinycc one would just use a local temporary buffer for one
of the two get_tok_str(c) results, as in

char tmp[40];
pstrcpy(tmp, sizeof tmp, get_tok_str(c));
tcc_error("%s ... %s\n", tmp, get_tok_str(tok, ));

-- gr



Anyway, this is not a show stopper by any means, but it is an ugly and
initially confusing message.

___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel




___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] rc testing with netbsd-curses: build break

[grischka]

On 22.09.2023 21:17, Detlef Riekenberg wrote:


Obviously when loading a .so library,
tcc additionally is loads its dependencies too.


That would be correct, when the target is TCC_OUTPUT_MEMORY
but i think, in all other cases, tcc should not do that.


I'd suggest to use "grep -nrw tcc_load_dll ." for example.  There is
only one place from where tcc_load_dll() is called:

in libtcc.c:tcc_add_file_internal():

case AFF_BINTYPE_DYN:
if (s1->output_type == TCC_OUTPUT_MEMORY) {
#ifdef TCC_IS_NATIVE
void* dl = dlopen(filename, RTLD_GLOBAL | RTLD_LAZY);
if (dl)
tcc_add_dllref(s1, filename, 0)->handle = dl, ret = 0;
#endif
} else
ret = tcc_load_dll(s1, fd, filename, (flags & 
AFF_REFERENCED_DLL) != 0);
break;

So, for TCC_OUTPUT_MEMORY, tcc does not use tcc_load_dll(),  It calls
"dlopen()" instead.  Where dlopen() would invoke the dynamic linker
(ld.so) and that one then would take care to load any dependencies
(DT_NEEDED tags).

-- gr


___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] rc testing with netbsd-curses: build break

[grischka]

On 16.09.2023 12:01, Detlef Riekenberg wrote:

libcurses/libcurses.so: error: referenced dll 'libterminfo.so' not found
make: *** [GNUmakefile:529: libpanel/libpanel.so] Fehler 1
Command exited with non-zero status 2

Analyse results so far:
* libpanel/libpanel.so depends on libcurses/libcurses.so
* libcurses/libcurses.so depends on libterminfo/libterminfo.so
* tcc searches for libterminfo.so, but fails
* from the failure message, the code is in tccelf.c:3659


That happened to get into my way too at some point. Obviously when
loading a .so library, tcc additionally is loads its dependencies
too.  It's rather early code, at tccelf.c:3653

/* load all referenced DLLs */
for(i = 0, dt = dynamic; i < nb_dts; i++, dt++) {
switch(dt->d_tag) {
case DT_NEEDED:
 ...

What's the point isn't entirely clear to me.  Normally if one
wants to use symbols from say libterminfo too one could just
write -lcurses -lterminfo.

There may be three options:  1) downgrade the error to a
warning, 2) disable loading of referenced DLLs completely,
3) have some switch to choose behavior (if such exists in gcc
for example)

-- gr


Bye bye ... Detlef



___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Re : Re: Re : Re: win32: -Wl,-nostdlib: undefined symbol 'memset'

[grischka]

On 12.09.2023 11:01, avih via Tinycc-devel wrote:

Tcc does not guarantee to compile pure C code into pure machine code,
and any pure-C implementation which the user provides might end up
depending on those functions involuntarily. The user has no control..


How do you define "pure C code"?  printf is pure (ANSI) C, no?

And were did you get that that a compiler should be able to produce
runnable binaries from such "pure C" without calling into any library
functions?

Also, what is "pure machine code"?  With neither input nor output it
couldn't do anything but waste instruction cycles.

-- gr



- avih




___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Re : Re: win32: -Wl,-nostdlib: undefined symbol 'memset'

[grischka]

On 11.09.2023 14:41, avih via Tinycc-devel wrote:

But in the case of tcc, it's not documented, and seems to go
quite a bit further than what gcc requires


libgcc.a from mingw-gcc-6.3.0 is 6218 kB, all full with according
to your standards "undocumented" stuff that however gcc surely
will require under certain circumstances and will miss when
-nostdlib given.  List follows:

_chkstk.o___chkstk
_chkstk.o__alloca
_chkstk_ms.o___chkstk_ms
_muldi3.o___muldi3
_negdi2.o___negdi2
_lshrdi3.o___lshrdi3
_ashldi3.o___ashldi3
_ashrdi3.o___ashrdi3
_cmpdi2.o___cmpdi2
_ucmpdi2.o___ucmpdi2
_clear_cache.o___clear_cache
_trampoline.o_getpagesize
_trampoline.o_mprotect
__main.o___do_global_dtors
__main.o___do_global_ctors
__main.o___main
_absvsi2.o___absvsi2
_absvdi2.o___absvdi2
_addvsi3.o___addvsi3
_addvdi3.o___addvdi3
_subvsi3.o___subvsi3
_subvdi3.o___subvdi3
_mulvsi3.o___mulvsi3
_mulvdi3.o___mulvdi3
_negvsi2.o___negvsi2
_negvdi2.o___negvdi2
_ctors.o___DTOR_LIST__
_ctors.o___CTOR_LIST__
_ffssi2.o___ffssi2
_ffsdi2.o___ffsdi2
_clz.o___clz_tab
_clzsi2.o___clzsi2
_clzdi2.o___clzdi2
_ctzsi2.o___ctzsi2
_ctzdi2.o___ctzdi2
_popcount_tab.o___popcount_tab
_popcountsi2.o___popcountsi2
_popcountdi2.o___popcountdi2
_paritysi2.o___paritysi2
_paritydi2.o___paritydi2
_powisf2.o___powisf2
_powidf2.o___powidf2
_powixf2.o___powixf2
_powitf2.o___powitf2
_mulsc3.o___mulsc3
_muldc3.o___muldc3
_mulxc3.o___mulxc3
_multc3.o___multc3
_divsc3.o___divsc3
_divdc3.o___divdc3
_divxc3.o___divxc3
_divtc3.o___divtc3
_bswapsi2.o___bswapsi2
_bswapdi2.o___bswapdi2
_clrsbsi2.o___clrsbsi2
_clrsbdi2.o___clrsbdi2
_fixunssfsi.o___fixunssfsi
_fixunsdfsi.o___fixunsdfsi
_fixunsxfsi.o___fixunsxfsi
_fixsfdi.o___fixsfdi
_fixdfdi.o___fixdfdi
_fixxfdi.o___fixxfdi
_fixunssfdi.o___fixunssfdi
_fixunsdfdi.o___fixunsdfdi
_fixunsxfdi.o___fixunsxfdi
_floatdisf.o___floatdisf
_floatdidf.o___floatdidf
_floatdixf.o___floatdixf
_floatundisf.o___floatundisf
_floatundidf.o___floatundidf
_floatundixf.o___floatundixf
_eprintf.o___eprintf
__gcc_bcmp.o___gcc_bcmp
_divdi3.o___divdi3
_moddi3.o___moddi3
_udivdi3.o___udivdi3
_umoddi3.o___umoddi3
_udiv_w_sdiv.o___udiv_w_sdiv
_udivmoddi4.o___udivmoddi4
bid_decimal_globals.o___dfp_set_round
bid_decimal_globals.o___dfp_get_round
bid_decimal_globals.o___dfp_clear_except
bid_decimal_globals.o___dfp_test_except
bid_decimal_globals.o___dfp_raise_except
bid_decimal_globals.o___bid_IDEC_glbround
bid_decimal_globals.o___bid_IDEC_glbflags
bid_decimal_data.o___bid_power10_index_binexp_128
bid_decimal_data.o___bid_reciprocals10_64
bid_decimal_data.o___bid_short_recip_scale
bid_decimal_data.o___bid_power10_index_binexp
bid_decimal_data.o___bid_estimate_bin_expon
bid_decimal_data.o___bid_power10_table_128
bid_decimal_data.o___bid_estimate_decimal_digits
bid_decimal_data.o___bid_recip_scale
bid_decimal_data.o___bid_reciprocals10_128
bid_decimal_data.o___bid_round_const_table_128
bid_decimal_data.o___bid_round_const_table
bid_binarydecimal.o___bid32_to_binary32
bid_binarydecimal.o___bid64_to_binary32
bid_binarydecimal.o___bid128_to_binary32
bid_binarydecimal.o___bid32_to_binary64
bid_binarydecimal.o___bid64_to_binary64
bid_binarydecimal.o___bid128_to_binary64
bid_binarydecimal.o___bid32_to_binary80
bid_binarydecimal.o___bid64_to_binary80
bid_binarydecimal.o___bid128_to_binary80
bid_binarydecimal.o___bid32_to_binary128
bid_binarydecimal.o___bid64_to_binary128
bid_binarydecimal.o___bid128_to_binary128
bid_binarydecimal.o___binary32_to_bid32
bid_binarydecimal.o___binary64_to_bid32
bid_binarydecimal.o___binary80_to_bid32
bid_binarydecimal.o___binary128_to_bid32
bid_binarydecimal.o___binary32_to_bid64
bid_binarydecimal.o___binary64_to_bid64
bid_binarydecimal.o___binary80_to_bid64
bid_binarydecimal.o___binary128_to_bid64
bid_binarydecimal.o___binary32_to_bid128
bid_binarydecimal.o___binary64_to_bid128
bid_binarydecimal.o___binary80_to_bid128
bid_binarydecimal.o___binary128_to_bid128
bid_convert_data.o___bid_factors
bid_convert_data.o___bid_packed_1_zeros
bid_convert_data.o___bid_convert_table
_isinfd32.o_isinfd32
_isinfd64.o_isinfd64
_isinfd128.o_isinfd128
bid64_noncomp.o___bid64_isSigned
bid64_noncomp.o___bid64_isNormal
bid64_noncomp.o___bid64_isSubnormal
bid64_noncomp.o___bid64_isFinite
bid64_noncomp.o___bid64_isZero
bid64_noncomp.o___bid64_isInf
bid64_noncomp.o___bid64_isSignaling
bid64_noncomp.o___bid64_isCanonical
bid64_noncomp.o___bid64_isNaN
bid64_noncomp.o___bid64_copy
bid64_noncomp.o___bid64_negate

Re: [Tinycc-devel] Question about adding new instruction

[grischka]

On 18.08.2023 12:41, Jens Nyberg wrote:

Hi!

I have two questions really:

1, I am thinking of adding the "ltrw" instuction to i386. I see there is 
already an ltr instruction so there might be good reason you don't have the w-variant? In 
any case how would I add it properly? Would adding a line like this be ok or do I need to 
do something else as well?

DEF_ASM_OP1(ltrw, 0x0f00, 3, OPC_MODRM, OPT_EA | OPT_REG)


IIRC there is some mechanism to handle b/w/l suffixes more or less
automatically.  You need to see whether you could use that or better
just add a separate instruction.



2. Is there a reason why the .extern keyword is not recognized by the assembler?


According to the gnu as docs it is ignored, so no,  I don't see a reason
why tcc couldn't just ignore it too.

-- gr



Thank you!

  / Jens


___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel




___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] A double-to-float conversion bug

[grischka]

On 31.07.2023 13:42, Herman ten Brugge via Tinycc-devel wrote:

I agree with your comments above. The size is incorrect.
I could change gfunc_sret in x86_64-gen.c and then calculate the size in 
tccgen.c
as you suggested. But I am not sure regsize is set correctly all the time.

I like this better:
--- a/tccgen.c
+++ b/tccgen.c
@@ -6142,7 +6142,7 @@ special_math_val:
 space.  Assume register size is power of 2. */
  if (regsize > align)
align = regsize;
-   loc &= -align;
+   size = (size + regsize - 1) & -regsize;
  loc = (loc - size) & -align;
  addr = loc;
  offset = 0;

The size should be a multiple of regsize.
What is your opinion?


Hi,

yes, that seems to make sense.  Then again I think that align should
additionally depend on just 'ret_align', as in

  if (ret_align > align)
   align = ret_align;



I was working on a better fix for riscv and reverted the patch from Yao Zi by 
accident.
I will reapply that change.


Well, as I was trying to say, that change wasn't a good one either.

Anyway, I just applied some more extensive fix for both.  Hope it does work
now.  Also yet another pragma_once_normalize patch (which you may or may
not want to comment ;)

-- gr



 Herman



___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] -__inf__ and -__nan__ are not constant

[grischka]

On 23.07.2023 16:11, wizzwizz4 via Tinycc-devel wrote:

I tried compiling QuickJS with tcc.
After setting `-DEMSCRIPTEN -DCONFIG_VERSION=""`, I get:

quickjs.c:2664: warning: function might return no value: 'JS_AtomGetKind'
quickjs.c:39834: error: initializer element is not constant

I'm guessing the error has something to do with this:


See tccgen.c:2491:

/* NOTE: we only do constant propagation if finite number (not
   NaN or infinity) (ANSI spec) */

Not necessarily saying that this is what tcc is actually doing and/or
should do

-- gr



$ tcc -run -
a = { 1e1000 };
b = { -1e54 };
c = { __inf__ };
d = { +__inf__ };
e = { -1.0 / 0.0 };
f = { -__inf__ };
-:6: error: initializer element is not constant

For some reason, -__inf__ isn't considered a constexpr.
Neither is -1e320, or -__nan__.
Negating other float values, or not negating these ones, is fine.

(Reader note: __inf__ and __nan__ are TCC implementation details;
  in real programs, INFINITY and NAN from  should be used
  instead.)

___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel




___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Error in latest mob on aarch64-musl build

[grischka]

On 24.07.2023 21:23, Sagar Acharya via Tinycc-devel wrote:

I'm building tcc on voidlinux with gcc as below

./configure --config-musl
make

On 'make test'

+In file included from 124_atomic_counter.c:3:
+In file included from /usr/include/stdlib.h:19:
+/usr/include/bits/alltypes.h:18: error: incompatible redefinition of 'wchar_t'
make[3]: *** [Makefile:131: 124_atomic_counter.test] Error 1


wchar_t of TCC is from stddef.h:
typedef __WCHAR_TYPE__ wchar_t;
and
__WCHAR_TYPE__
is defined for platforms in tccdefs.h.

Maybe need to tweak that for your platform.

Look at the alltypes.h...

-- gr


Thanking you
Sagar Acharya
https://humaaraartha.in



___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Ported tcc to Solaris/Illumos x86

[grischka]

On 14.07.23 15:30, Brian Callahan wrote:

* __start_crt_compiler: referenced symbol not found
   Seems you'd need to provide this function, for example in libtcc1.a.
   Google has some info about it.



This symbol is provided in the Solaris C runtime startup files, and it
is linked into the binary. Which is why I think the relocation error is
the real problem, and this is one is a red herring.


Why start "thinking" when it takes one minute to lookup the docs
https://docs.oracle.com/cd/E88353_01/html/E37853/u--start-crt-compiler-7.html
and another minute to try with a hello.c that includes that function.


* relocation R_AMD64_COPY offset invalid: _DYNAMIC: offset=0xa00a08 lies
   outside memory image;

   Don't know.  COPY relocs normally are generated only by the tcc linker
   itself for bss symbols.  Is "_DYNAMIC" the symbol name?  Does it have
   a "symbol size" (esym->st_size) ?  Try objdump -R,  See also
tccelf.c:1941



Started on this but nothing conclusive yet.


According to
https://docs.oracle.com/cd/E26502_01/html/E26507/chapter6-42444.html
"_DYNAMIC" seems to be a section symbol that the linker should provide.
Maybe as in tccelf.c:tcc_add_linker_symbols()

-- gr



~Brian



___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Ported tcc to Solaris/Illumos x86

[grischka]

On 11.07.2023 07:22, Brian Callahan wrote:

Hi all --

Attached for review/testing is a diff that enables TCC to work on
Solaris/Illumos x86. Tested on an OpenIndiana (Illumos distro) machine,
where all tests pass when running TCC as an i386 compiler.
Solaris/Illumos is a multiarch environment. Modern Illumos is a 64-bit
kernel only, but 32-bit binaries work just fine; the Illumos people care
a lot about backwards compatibility.


Hi,

that sounds good.  For the people who might want to try this but do
not necessarily have the same insight as you do have by now, I'd suggest
to at least try to tackle the remaining issues in the sense of an out
of the box experience:

* configure:  maybe it is possible to let configure detect this
 "not smart enough" shell and if so print some informative message
  (such as "Better use bash configure on this system") or maybe even
  re-execute itself using bash then.

* path to diff etc. tools:  it might be possible to set the "Path"
  variable in the (top section of the top level-) Makefile, conditionally

* gcc build cross tcc on i386:  Maybe it's still possible one way or
  the other to detect that we're compiling for i386 even under gcc.
  The logic in tcc.h is

  # if defined __i386__ && defined TCC_TARGET_I386
  #  define TCC_IS_NATIVE

  For example MSVC defines just _x86_, which is why there is

  #  ifdef _X86_
  #   define __i386__ 1
  #  endif

* __start_crt_compiler: referenced symbol not found
  Seems you'd need to provide this function, for example in libtcc1.a.
  Google has some info about it.

* relocation R_AMD64_COPY offset invalid: _DYNAMIC: offset=0xa00a08 lies
  outside memory image;

  Don't know.  COPY relocs normally are generated only by the tcc linker
  itself for bss symbols.  Is "_DYNAMIC" the symbol name?  Does it have
  a "symbol size" (esym->st_size) ?  Try objdump -R,  See also tccelf.c:1941

-- gr


Illumos is interesting because it is a variant of early Solaris 11, with
about a decade of divergence from Oracle. The way I set up support is to
declare Illumos effectively a sub TARGETOS of Solaris.

To build and test, you will want to ensure that the GNU tools are found
first in your PATH. This is because TCC assumes GNU install and GNU
diff, but on Illumos Sun install and Sun diff are found first with the
default PATH. You can fix this by running `export
PATH=/usr/gnu/bin:/usr/bin:/usr/sbin:/sbin` before building TCC. You'll
also need to run the configure script with `bash configure` as /bin/sh
on Illumos is not smart enough to run the configure script.

As mentioned, all tests pass on Illumos i386. In order to run the tests,
you need to rebuild TCC with itself. This is because GCC on Illumos
unconditionally declares itself to be amd64, even when in i386 mode. As
such, TCC built with GCC fails the tests because TCC thinks it's a cross
compiler and the -run test errors out because of this. Once you rebuild
TCC with itself, it'll correctly think it's a native compiler and run
all the tests.

I believe all the bits for amd64 support are there and good to go.
However, there is a linker issue that prevents binaries from working
correctly. The message you receive is:
ld.so.1: : fatal: relocation error: file : symbol
__start_crt_compiler: referenced symbol not found

However, you get what I think is the real problem if you run `ldd -d` on
the binary:
relocation R_AMD64_COPY offset invalid: _DYNAMIC: offset=0xa00a08 lies
outside memory image; relocation discarded

If you can help fix this, that would be great. With that said, the i386
version of TCC ought to be enough for the vast majority of use cases for
TCC on Solaris/Illumos, so I am sharing the diff now.

Is it worth waiting around for testing or should I just go ahead and
push this to mob?

Thanks.

~Brian



___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel




___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Relative paths of include files are not normalised, which can break #pragma once

[grischka]

On 07.07.2023 20:09, Herman ten Brugge via Tinycc-devel wrote:

I did a benchmark on linux and it is about 2% slower on my machine.


Well, and how much in comparison is the gain from the ifndef_cache,
in your benchmark?  I mean just in case to make sure the cache won't
be slower than no cache after we tried to fix it ;)


I created a new patch where I removed the stat call.
I now calculate the full path name on linux and windows.
This means that soft/hard links do not work any more.
There is still a small slowdown because we create/compare the full path name 
now.
But it is about 0.1% on my 64 bits x86_64 machine. Hard to measure correct.


I'd think this would look a lot better if your tiny real/fullpath
replacement were put into its own function.

Plus such thing almost never works right on the first attempt.
(For example tcc might want to try the combination of "-I /include"
with "../../x.h", why not. Rather use the real realpath() then ;)

Anyway, thanks for having showed some options already.  What we havn't
seen yet is whether we could maybe handle #pragma once specifically
different as opposed to the #ifndef FOO_H cache.  For example there is
no need to check normalized paths at all against files that didn't
have #pragma once (e->once not set).

Obviously similar issues have been seen before elsewhere:

"Bug 58770 - GCC very slow compiling with #pragma once"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58770

-- gr



 Herman


___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Questions about commit 5b28165: Fix test 131 for 32 bits targets

[grischka]

On 07.07.2023 18:15, Ziyao via Tinycc-devel wrote:

Hi,

I noticed that test 131 (authored by me) has been modified
in commit 5b28165: Fix test 131 for 32 bits targets:
struct with two long int members are replaced by long long
int ones.

Test 131 (return struct in registers) is intended to test
whether functions return small structs (maybe passed in
registers in some ABIs) are handled properly.

long long int on 32bit targets seem to be 8 bytes, right?
And AFAIK, many ABIs only pass structs with 2 * WORDLENGTH
size in registers (for 32-bit architectures, it is 8-bytes
and is equal to the size of a struct with two long int
members.)

Is this fix necessary?


Hi,

well, problem is simply that with 32-bit longs your data
   0x1234567890abcd
would be truncated to
   0x7890abcd
and the output from %lx would not match the .expect file.

Btw is your fix incorrect.  The code that you "fixed" is about
alignment but there was no alignment problem in your case.

The real problem is below at "vtop->c.i += regsize;" which can
advance the location to load the 2nd register only for local or
global/static memory.

For pointers it would need to emit an 'add r, regsize' instruction
You can see such code in gv():

gaddrof();
vpushs(PTR_SIZE);
gen_op('+');
vtop->r |= VT_LVAL;

-- gr


___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Relative paths of include files are not normalised, which can break #pragma once

[grischka]

On 07.07.2023 07:45, draco wrote:

Hermann,

I tested your patch a bit, seems to work as expected and brings tcc
win32 back to it's normal speed.


It might be too slow on linux too ...

Basically the "#ifndef cache" is meant to make it faster,
while the #pragma once also needs to detect path aliases.

That is two different goals in the first place.

Another goal in tinycc is simple code.  For example to have
a common solution for platforms.

-- gr


Can you upload it to the mob?

Thank you!

Michael



___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Relative paths of include files are not normalised, which can break #pragma once

[grischka]

On 30.06.2023 01:14, Detlef Riekenberg wrote:

Hi Herman


On 25.06.2023 20:30, Herman ten Brugge via Tinycc-devel wrote:


I just pushed a patch to fix this.


Hi Hermann,

some numbers from Win32:

before:
   # 6.334 s, 85768 lines/s, 27.9 MB/s
after first patch:
   # 11.825 s, 45941 lines/s, 14.9 MB/s
after second patch:
   # 10.406 s, 52206 lines/s, 17.0 MB/s

Hm ...


I do not think, that we really need a 64bit hash (with 64bit multiply)
for the complete file content.


Actually it hasn't yet to do with the hash at all.  Also not #pragma once
is not used.  Here is some more data:

# 25401 idents, 4838227 lines, 176764178 bytes (168.6 MB)
# 10.405 s, 52211 lines/s, 17.0 MB/s
# text 4705836, data.rw 3084, data.ro 483724, bss 524940 bytes

# 172 files compiled, 13771 included, 5087 skipped, 43749 not found
# 72308 files stat'ed, 0 hashed

Which means tcc compiled 172 files on one command line, each of them
including on average ~110 headers, from which ~30 are skipped by the
include cache mechanism (checking the #ifndef _XXX_H_ around the file).

The result now is that the new stat() is called 72308 times, mostly
failing (due to include path search).  Which means that at least on
Windows just those stat() calls are taking about the same time as
tcc parsing ~169MB of source code, and that the cache makes tcc
much slower than no cache at all.

(If you step a bit into what that stat() from msvcr90.dll does, then
it's no surprise really.)


In addition to the filename and the filesize, i suggest to use "st_mtime":
  much cheaper and available for free.


gcc, at least 3.4.6, checks st_size and st_mtime, and then does a plain
memcmp() over the entire buffers (cppfiles.c:should_stack_file()).

BUT: tinycc does have a mission that gcc does not have, which is to be
fast and simple.  So I guess it will have to make some restrictions
to the feature as to what extend it can be supported sensibly.

For example tinycc could require at least same basenames (as in the reported
case).  Which would reduce drastically the number of possible candidates
and still would work for all purposes of #pragma once except when 'b.h' is
a link to 'a.h' and both are used in the same translation unit.

-- grischka


I tested this also before committing. I could not find a problem.
I only have an x86_64 machine on redhat linux and a raspberry pi with 32
and 64 bits.
I also have no Windows any more and my i386 machine died about 10 years ago.



So I did the measurement with wine (32/64 bits) and saw no difference
before and after commit.


Your machine is too recent / too fast / has too much memory.
* Multiplications on recent processors are much faster than on older processors.
* A SSD is so fast, that loading many includes many times has no resonable 
delay.
* With a huge amount of system memory, your include directory entries and many 
include files are cached.

For speed tests comparsion, a low resource VM or an old system with fewer RAM 
and a HDD will show the slowdown.
(disable kernel VM support / force JIT mode to make the emulated processor 
slower)


I cannot currently think of a better solution for pragma once. Maybe you
can?


* replace the hash with "st_mtime"





___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Relative paths of include files are not normalised, which can break #pragma once

[grischka]

On 25.06.2023 20:30, Herman ten Brugge via Tinycc-devel wrote:


I just pushed a patch to fix this.


Hi Hermann,

some numbers from Win32:

before:
  # 6.334 s, 85768 lines/s, 27.9 MB/s
after first patch:
  # 11.825 s, 45941 lines/s, 14.9 MB/s
after second patch:
  # 10.406 s, 52206 lines/s, 17.0 MB/s

Hm ...

-- gr

___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] patch for tcc (and question)

[grischka]

On 27.05.2023 02:28, Fred van Kempen via Tinycc-devel wrote:

Herman:

 >> Based on the 0.9.27 release code, I added a patch to tcc.c to let it "find" 
itself and its
 >> support directories (include, lib etc) even it is not located in the root 
of that setup. I
 >> normally have stuff organized under "bin/" to keep it clean, and because my 
systems
 >> require several platforms, it is usually like

 >  the mob branch?
 > I am missing the patch?
Submitted with ID da3a763.


I'd say that this patch looks more like someone's personal easter egg,
or at least you missed to explain why you would recommend other people
to use an install structure as you do as well, what the benefit is over
the one that they already have, and how they are supposed to create it,
preferably automatically I'd assume...

Other than that it is already possible to install the tcc executable(s)
in a custom separate location, for example like

./configure --tccdir=... --bindir=...

which is supposed to set CONFIG_TCCDIR explicitly and thus override the
run-time automatism under libtcc.c:98: #ifndef CONFIG_TCCDIR.

By the way, from
https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project

"As a general rule, your messages should start with a single line
 that’s no more than about 50 characters and that describes the
 changeset concisely, followed by a blank line, followed by a more
 detailed explanation."

 (with also no more than about 50-70 characters each line)

-- gr



--Fred


___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Implementation of '--' argument

[grischka]

On 18.04.2023 07:41, certanan via Tinycc-devel wrote:

I couldn't find any specific reasons as to why '--' was replaced by '-run' 
(other than '-run' being implicitly more coherent than '--'). Since there is a 
possibility that older scripts still depend on '--', would it be a bad idea to 
re-implement it for the sake of backward compatibility, and state its 
deprecated status in documentation?


What about the possibility that the "older" script that you found

   https://github.com/qemacs/qemacs/blob/master/qe.tcc

still exists there unchanged because nobody did even try it with
a more recent version of tcc since then?

Did you check how well it would work at all?

-- gr


- certanan

--- Original Message ---
On Monday, April 17th, 2023 at 8:18 AM, grischka  wrote:



On 17.04.2023 07:59, avih via Tinycc-devel wrote:


What some random script tries or doesn't try to do is irrelevant.



In a case however where the script and the tcc to be used with it
were written by the same author at the same time, we probably better
assume that it actually did work.

As it seems the purpose was different though, i.e. the '--' once
was used with instant execution to separate tcc args from the
program's args.

See commit here (from almost exactly 20 years ago) where "--" then
was replaced by "-run" as it still exists.

https://repo.or.cz/tinycc.git/commitdiff/40987541dc683a13cef764aa33f5da21b2660817


tcc should follow the spec and common practices.



... provided that these do make sense in tcc's own context. In cases
it better shouldn't.

For example, not to support compilation of files such as -c.c is
not a problem as long as we assume that such files do not exist.

Other than that tcc currently does support these forms with -run:
tcc options [files less one] -run last_file arguments
and also
tcc "-run options" file arguments (for usage with "#!", see ex4.c)
and also
tcc options files -run @ arguments

I'd consider the latter form still rather "unofficial" so we could
still replace it by

tcc options files -run -- arguments

which might (or might not) look better, in some sense.

What do people think?

-- grischka


___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel


___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel




___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Implementation of '--' argument

[grischka]

On 17.04.2023 07:59, avih via Tinycc-devel wrote:


What some random script tries or doesn't try to do is irrelevant.


In a case however where the script and the tcc to be used with it
were written by the same author at the same time, we probably better
assume that it actually did work.

As it seems the purpose was different though, i.e. the '--' once
was used with instant execution to separate tcc args from the
program's args.

See commit here (from almost exactly 20 years ago) where "--" then
was replaced by "-run" as it still exists.

https://repo.or.cz/tinycc.git/commitdiff/40987541dc683a13cef764aa33f5da21b2660817


tcc should follow the spec and common practices.


... provided that these do make sense in tcc's own context.  In cases
it better shouldn't.

For example, not to support compilation of files such as -c.c is
not a problem as long as we assume that such files do not exist.

Other than that tcc currently does support these forms with -run:
   tcc options [files less one] -run last_file arguments
and also
   tcc "-run options" file arguments (for usage with "#!", see ex4.c)
and also
   tcc options files -run @ arguments

I'd consider the latter form still rather "unofficial" so we could
still replace it by

   tcc options files -run -- arguments

which might (or might not) look better, in some sense.

What do people think?

-- grischka


Generally speaking, applications which respect the POSIX syntax
guidelines should treat non-option-argument "--" as an indication
that all further arguments are operands:
- https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap12.html

It's important to note that according to these guidelines, the
options always come before the operands. I.e. mixing of options and
operands (like GNU getopt does with permutations) is not allowed.

Therefore, the use of "--" is to indicate where the options end and
the operands start, especially for the case where the first operand
begins with "-".

"grep" should indeed respect these guidelines, and "--":
- https://pubs.opengroup.org/onlinepubs/9699919799/utilities/grep.html

However, there are exceptions, for instance "echo" should not
respect these guidelines and instead treat all arguments as operands:
- https://pubs.opengroup.org/onlinepubs/9699919799/utilities/echo.html

(the fact that some implementations of "echo" deviate from the spec
and allow options such as "-e" or "-n" is the reason for echo being
considered non portable, and why "printf" is recommended instead)

The "c99" utility, which should probably be considered the spec for
tcc, has some exceptions with regards to the syntax guidelines:
- https://pubs.opengroup.org/onlinepubs/9699919799/utilities/c99.html

While it does not specifically mention "--", it does say that
options and operands can be mixed, and some options should appear
after [c-files] operands, such as the "-l" and "-L" options
(check the synopsis).

For that reason, allowing "--" to be used before c-filenames
is a footgun, because then it's not possible to add "-l" or "-L"
options as needed by the spec.

The fact that gcc also doesn't recognize "--" is existing common
practice as well.

However, clang does recognize "--", and indeed, it rejects "-l"
or "-L" if they appear after "--" and some c-filenames.

As far as I can tell that's inconsistent with the "c99" POSIX spec.

So there you go. The main point of this is that it's not obvious
that tcc should respect "--" the same as some other utilities.

- avih

On Sunday, April 16, 2023, 11:44:24 PM GMT+3, certanan via Tinycc-devel 
 wrote:


I understand. But then what role does the flag fulfil in this script?
https://github.com/qemacs/qemacs/blob/master/qe.tcc

- certanan

 > I tried: gcc -- a.c
 > and got:
 > gcc: error: unrecognized command-line option '--'
 >
 > This is with prerelease of gcc 13.
 > So gcc does not support this. Why would this be needed for tcc?
 >
 > Herman
 >
 > ___
 > Tinycc-devel mailing list
 > Tinycc-devel@nongnu.org <mailto:Tinycc-devel@nongnu.org>
 > https://lists.nongnu.org/mailman/listinfo/tinycc-devel


___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org <mailto:Tinycc-devel@nongnu.org>
https://lists.nongnu.org/mailman/listinfo/tinycc-devel


___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel




___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Implementation of '--' argument

[grischka]

On 15.04.2023 22:38, certanan via Tinycc-devel wrote:

 From what it seems to me, even Bellard's QEmacs seems to be relying on this, 
rather, standard feature since at least 19 years ago, as referenced in its 
official GitHub repository.
Am I missing something cardinal, or is there, indeed, no valid reason for this 
seemingly not being implemented in tcc? Should the former be the case, I would 
appreciate if someone informed me of it. Otherwise, I have a patch on standby, 
ready to push the feature to mob.


Sorry, what this "the feature"?  Mind do add a little more information
what you're talking about, how it's supposed to be used, examples... ?

-- gr


Thanks.
- certanan

___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel




___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Please do a 0.9.28 release.

[grischka]

On 29.03.2023 23:10, Detlef Riekenberg wrote:

Hi Grishka.

Please create a 0.9.28 release.

Afterwards, we can work towards a 1.0.0 release, probably in this year.


Why does it need 1.x.x releases when it can still have a lot of 0.9.xx?

Anyway, I think it's good that we've seen some more extensive testing
lately, it might help to have a solid next release to stay for a while
again.

I got distracted though by the (_)_unaligned thingy, is that not a
MS-C extension, and is there not a (currently conflicting) definition
already in tcc's windows headers?  As to "still present in code from
> 15 years ago" ... I mean some people have some problems with some
software always but the question is (as always) whether tinycc is the
best place to fix them (and if so, what is the best place in tinycc).

Also, what's TAP and what's the benefit for the rest when "tcc -bench"
output is compatible with it?

-- grischka



I hope, that we get more attention with a 0.9.28 release
and maybe also new contributions/testers.


Thanks for your effort.



___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] 'make install' omitting binaries

[grischka]

On 09.03.2023 16:02, Herman ten Brugge via Tinycc-devel wrote:

On 3/9/23 08:53, certanan wrote:

Binaries do not get built - and are omitted from the installation process, in 
turn - when running 'make install' before 'make'. Is this a feature, or a bug?


Just pushed a fix.

 Herman


I'm no install expert but I think that "sudo make install" when
it would implicitly create files as "root" in the local directories
(such as *.o) did already cause unexpected complications to me.

Also, in tinycc so far one could make and install just a cross-compiler
for example:

./configure
make cross-arm-eabi
sudo make install

which is not so bad at least for developers.

-- grischka

___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] another yarpgen_v1 problem

[grischka]

On 10.03.2023 21:00, Herman ten Brugge via Tinycc-devel wrote:

On 3/10/23 09:28, Herman ten Brugge wrote:

The attached program is a reduced version of yarpgen v1 code.

The code works with gcc.
The code has a floating point exception with tcc.

Maybe another nocode_wanted problem?


I tried the attached patch and now yarpgen runs without problems for 30 minutes.

I am not familiair with the code. I just noticed that nocode_wanted was 
different on
entry and exit.



Is it just me or are there more commits on mob since lately where
the first word is "Fix" than it used to be? ;)

-- grischka



 Herman


___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel



___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] make test fail in termux/aarch64 Android 11?

[grischka]

On 01.03.2023 14:58, Andrew Randrianasulu wrote:

I tried to make tcc from commit

29ae3ed4d5b83eec43598d6cd7949bccb41c8083

it makes itself fine, just 'make test' result in

~/tinycc $ make test
make[1]: Entering directory '/data/data/com.termux/files/home/tinycc/tests'
 hello-exe 
Hello World
 hello-run 
Hello World
 libtest 
Hello World!
fib(32) = 2178309
add(32, 64) = 96
 libtest_mt 
   running fib with mixed calls
   1 2 3 5 8 13 21 34 55 89 144 233 377 610 987 1597 2584 4181 6765 10946
  (60 ms)   
running fib in threads
   1 2 5 1597 8 13 3 34 2584 144 21 377 89 55 987 4181 233 610 10946 6765
  (77 ms)
running tcc.c in threads to run fib
   1 5 144 1597 6765 3 21 377 10946 8 233 610 2584 34 89 987 4181 2 13 55
  (5492 ms)
compiling tcc.c 10 times
   1 2 3 4 5 6 7 8 9 10
  (2125 ms)
 test3 
--- test.ref2023-03-01 16:48:38.688180575 +0300
+++ test.out3   2023-03-01 16:48:40.140180574 +0300
@@ -827,7 +827,7 @@
  *rel1=2   
 *rel2=3
  in getmyaddress
-pa_symbol=0x0
+pa_symbol=0x

   old_style_function_test 
  a=1 b=2 b=3.00
make[2]: *** [Makefile:125: test3] Error 1
make[1]: *** [Makefile:80: all] Error 2
make[1]: Leaving directory '/data/data/com.termux/files/home/tinycc/tests'
make: *** [Makefile:451: test] Error 2


I wonder if this error real or simply result from old test?


Hi,

that test is rather new however might show up with some shortcoming if
global addresses are in the above 2GB range (which may or may not be the
case with -run memory on android aarch64). See comment at tcctest.c:2862.

Probably you're fine to ignore that error for now.  In any case you can
use
$ make test -k
to see more results from the other tests.

-- gr


___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel




___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] TCC seems to be confused by a structure field: how should I fix this?

[grischka]

On 22.12.2022 09:20, Harry Yan wrote:

Hello,

I am trying to build the SQLite3 command-line tool with TCC.

It works well with GCC:


$ gcc -c shell.c dirent.c
(no complaints)


However, TCC seems to be confused by a structure field:


Hi, yes, seems, but is not in that case.

Instead in that 'shell.c' we can find this:
   149: #  define DIRENT dirent
and
   1421: #  define DIRENT dirent
and
   4737: #  define dirent DIRENT

which now looks more like a good reason for us to be confused.

Using the compiler to help out
   $ tcc -E -P shell.c -o shell.i
at 1250 we find:
struct DIRENT *pEntry = readdir(pLvl->pDir);
if( pEntry ){
  if( pEntry->d_name[0]=='.' ){

So, tcc saying
"error: field not found: d_name"

is a correct statement because a 'struct DIRENT' or any members
of it were not defined anywhere.

I would agree however that a better message would be something more
similar to gcc in such case, for example:
"error: dereferencing incomplete type 'DIRENT'

As to your problem, it looks like that you need to make some decision
to the effect that either 'DIRENT' gets defined or that 'dirent' stays
undefined, as you may find appropriate.

-- gr


$ tcc -c shell.c dirent.c
shell.c:5359: error: field not found: d_name


Where line 5359 refers a d->name field from a dirent structure, which should be 
the problem.

  5355   while( pCur->iLvl>=0 ){
  5356 FsdirLevel *pLvl = >aLvl[pCur->iLvl];
  5357 struct dirent *pEntry = readdir(pLvl->pDir);
  5358 if( pEntry ){
  5359   if( pEntry->d_name[0]=='.' ){
  5360if( pEntry->d_name[1]=='.' && pEntry->d_name[2]=='\0' ) continue;
  5361if( pEntry->d_name[1]=='\0' ) continue;
  5362   }
  5363   sqlite3_free(pCur->zPath);
  5364   pCur->zPath = sqlite3_mprintf("%s/%s", pLvl->zDir, pEntry->d_name);
  5365   if( pCur->zPath==0 ) return SQLITE_NOMEM;
  5366   if( fileLinkStat(pCur->zPath, >sStat) ){
  5367 fsdirSetErrmsg(pCur, "cannot stat file: %s", pCur->zPath);
  5368 return SQLITE_ERROR;
  5369   }
  5370   return SQLITE_OK;
  5371 }

My TCC version is 0.9.27, which should be the latest. I am on the Windows 
system.

I have attached the files in a zip so that it would be easy to test.

Thank you all for the help,
Harry




___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel




___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Non PIC-code and TCC's GOT strategy for TCC_OUTPUT_MEMORY

[grischka]

On 05.12.2022 22:10, Macoy Madson wrote:

Hi,

I'm working on using TCC as the core of run-time modifiable applications. I am 
using TCC as a library, and compiling/linking straight to memory, i.e. 
tcc_set_output_type(state, TCC_OUTPUT_MEMORY). I have mob c03d59e.

I was having issues with static linking SDL2 with TCC, where SDL2 was built 
with GCC -O3. SDL2 would segmentation fault as soon as I tried to initialize 
it. I tracked it down to the log function using stderr, which was a bogus 
address.

I found the issue:

- GCC generates R_X86_64_PC32 relocations to unknown symbols like stderr in 
SDL2.

- TCC, while relocating, sees that the PC32 reference is undefined, so creates an 
"AUTO_GOTPLT_ENTRY" and updates the relocation to go to "stderr@plt" instead of 
"stderr".

* Note that the final address of stderr is a dynamic symbol, because the TCC 
"environment" itself is linked to GNU libc.


Hi,

I think the conclusion is that "tcc -run" using .o/.a from gcc (without -fPIC)
is not well supported.

Of course redirecting to a jump-slot "stderr@plt" is wrong because "stderr"
is not a function.  Thing is that R_X86_64_PC32 can occur for both functions
and data.

But in order to know whether the symbol is STT_FUNC or STT_OBJECT, tcc would
need to actually load libc.so (via tcc_load_dll()) and to scan its tables
which it (traditionally) doesn't for tcc -run.  See build_got_entries():
if (s1->dynsym) {
/* dynsym isn't set for -run :-/  */
If tcc would have that information, then it could create a PLT slot or
a R_COPY entry respectively, for -run too.

Reason why it mostly works is that TCC itself never uses R_X86_64_PC32 for
data (except for static data which is never SHN_UNDEF).

Such I guess your options probably are:
- use gcc -fPIC
- use tcc to compile SDL (more like -FPIC but not optimized)
- provide SDL as a shared library
- link SDL into the host application and provide its symbols via tcc_add_symbol
- work on tcc to fix the problem

-- grischka



This ends in disaster, because it appears TCC assumes that the relocation can 
safely become a GOT/PLT relocation in build_got_entries()--gotplt_entry_type() 
returns AUTO_GOTPLT_ENTRY for the R_X86_64_PC32 relocations.

Now, I'm not well-practiced at reading assembly so I may be wrong here, but 
here's an example of the code that is breaking (objdump --disassemble --reloc 
build/SDL.o):

0020 :
 20:f3 0f 1e fa  endbr64
 24:48 8b 05 00 00 00 00 mov0x0(%rip),%rax # 2b 

   27: R_X86_64_PC32stderr-0x4
 2b:48 89 05 00 00 00 00 mov%rax,0x0(%rip) # 32 

   2e: R_X86_64_PC32MyStderr-0x4
 32:48 8d 05 00 00 00 00 lea0x0(%rip),%rax # 39 

   35: R_X86_64_PC32stderr-0x4
 39:48 89 05 00 00 00 00 mov%rax,0x0(%rip) # 40 

   3c: R_X86_64_PC32MyStderrAddr-0x4
 40:b8 ff ff ff ff   mov$0x,%eax
 45:c3   retq
 46:66 2e 0f 1f 84 00 00 nopw   %cs:0x0(%rax,%rax,1)
 4d:00 00 00

And here's the working GOT version:

0020 :
 20:f3 0f 1e fa  endbr64
 24:48 8b 05 00 00 00 00 mov0x0(%rip),%rax # 2b 

   27: R_X86_64_REX_GOTPCRELXstderr-0x4
 2b:48 8b 15 00 00 00 00 mov0x0(%rip),%rdx # 32 

   2e: R_X86_64_REX_GOTPCRELXMyStderr-0x4
 32:48 8b 08 mov(%rax),%rcx
 35:48 89 0a mov%rcx,(%rdx)
 38:48 8b 15 00 00 00 00 mov0x0(%rip),%rdx # 3f 

   3b: R_X86_64_REX_GOTPCRELXMyStderrAddr-0x4
 3f:48 89 02 mov%rax,(%rdx)
 42:b8 ff ff ff ff   mov$0x,%eax
 47:c3   retq
 48:0f 1f 84 00 00 00 00 nopl   0x0(%rax,%rax,1)

The (modified) source is the following:

void* MyStderr = NULL;
void* MyStderrAddr = NULL;

SDL_InitSubSystem(Uint32 flags)
{
 Uint32 flags_initialized = 0;

 MyStderr = stderr;
 MyStderrAddr = (void*)
 return -1;

}

I use those My* variables outside SDL2 to print the address of stderr, for 
debugging. I am able to print in the other compilation unit because it uses the 
GOTPCRELX relocations to find stderr instead of the faulty PC32 ones.

It appears to me that the PC32 version could not safely use the GOT, because it 
doesn't do the extra dereference necessary due to the indirection.

I can fix this by compiling SDL2 files with -fPIC, which generates 
R_X86_64_REX_GOTPCRELX relocations, and TCC handles those perfectly.

I can also go the 100% static linked approach by compiling in static musl libC or 
something so that all the symbols are defined at relocation time. This has implications 
on how many hoops the "user" needs to jump t

Re: [Tinycc-devel] mob-stuff branch?

[grischka]

On 25.10.2022 00:08, Bernhard Reutner-Fischer wrote:

AFAICS the "warn about incorrect use of output_*" by using an enum did
never end up on mob.


Just because features often come with more complexity does not mean
that more complexity already is a feature.

Much more often the contrary is true:  the simpler the better.

"int output_type;" is simple.

"output_t output_type;" is "output_t(ype)" twice.  Honestly, I still
fail to see the point, even 13 years later ... ;)

-- gr



We seem to have --{no-,}whole-archive by now, so that's obsolete i
guess. And the elf-interpreter toggle is in there, too, so that's fine.

Not sure what you would think about the idea i toyed with in "add
--enable-shared, part1". IIRC the idea was to cut down on memory usage
when running many tcc processes or something along those lines.

thanks!

$ git log -n7 origin/mob-stuff
commit bfa394dab88cb417bb540c32647f04d08e9838af (origin/mob-stuff)
Author: Bernhard Reutner-Fischer 
Date:   Wed Sep 2 15:55:48 2009 +0200

  Move bounds-checking code to a bcheck.a

  ... to avoid undefined references to __bound_new_region()
  (when using a libtcc1_s.so instead of libtcc1.a) on i386.



That's an open question I think.



  Signed-off-by: aldot 

commit a39d055d0e666b152df87b4a603c670c3af37d68
Author: Bernhard Reutner-Fischer 
Date:   Wed Sep 2 15:55:48 2009 +0200

  Handle --whole-archive

  Support and document -Wl,--{no-,}whole-archive.


done.
Didn't check if what's in there actually works.



  Signed-off-by: aldot 

commit f0e8b23d02a4c06789b4b8876c65866a237ce570
Author: Bernhard Reutner-Fischer 
Date:   Tue Sep 1 13:32:34 2009 +0200

  Implement -m{uclibc,glibc} to choose elf_interp

Support -muclibc and -mglibc (default) to choose between the elf
interpreter like gcc does.

$ ./tcc -o hi-glibc hello.c
$ ./tcc -muclibc -o hi-uclibc hello.c
$ readelf -l hi-* | egrep "(^File: | interpreter)"
  File: hi-glibc
[Requesting program interpreter: /lib/ld-linux.so.2]
  File: hi-uclibc
[Requesting program interpreter: /lib/ld-uClibc.so.0]


Presumably done.
Didn't check how it's implemented though.



  Signed-off-by: aldot 

commit 83cb1364a606fa9fbff450a65ab68e09a5bb4e42
Author: Bernhard Reutner-Fischer 
Date:   Wed Sep 2 12:03:51 2009 +0200

  Revert "add --enable-shared, part1"

  This reverts commit 9257c5221ea4f095d813082716f786c6c5d23321.

  Signed-off-by: aldot 

commit d90eb2008b62d19f70bdd14bdf9d784b8789da5d
Author: Bernhard Reutner-Fischer 
Date:   Tue Sep 1 17:04:42 2009 +0200

  add --enable-shared, part1

Build a libtcc.so and link the tcc binary against it.


That area is, i believe, not dealt with yet, is it?

It would serve 2 purposes:
- Runtime mem consumption reduction.
- Would help establish an improved interface to the "backend".

I'd encourage discussion around that area.
Mainly to cleanup an streamline internal interfaces TBH.



  Signed-off-by: aldot 

commit 8a555345e3faa37ff0b2c0b84ae1f42358400923
Author: Bernhard Reutner-Fischer 
Date:   Tue Sep 1 14:27:41 2009 +0200

  warn about incorrect use of output_*



Not addressed yet.
I think we should do something along those lines. WDYT?



  Signed-off-by: aldot 

commit 3a40b44938d59b71d0c010579d9bd9f05e7eed46
Author: Bernhard Reutner-Fischer 
Date:   Tue Sep 1 11:52:51 2009 +0200

  allow for non-stripped install



That's not dealt with as far as I'm aware.
Nowadays distros tend to split off -dbgsym packages on their own. So if we 
strip the debug on our own, this defeats usability and debug ability for distro 
users IMO.

I think we should at least give distros an easy way to decide on their own, 
shouldn't we.

thanks and cheers,




___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] mob-stuff branch?

[grischka]

On 23.10.2022 09:48, Bernhard Reutner-Fischer wrote:

Hi Grischka and folks!

I have just pulled after some time.
In my clone, i see a remotes/origin/mob-stuff branch and i wonder what
that is/was about, does anybody remember by chance? Was that a staging
area for mob or somesuch?

Maybe it's an artifact that was pruned already?


Hi,

Indeed I did delete that branch (and another one) remotely not that
long ago (because of presumably little public interest).

As to what it was,  I think there was a strategy used two or three
times in the early days, that was to apply just selected patches from
mob to master and then reset mob, and that "mob-stuff" branch then was
a "for-the-records" collection of not-applied patches.

See also https://lists.gnu.org/archive/html/tinycc-devel/2009-12/msg3.html

Incidentally short time before the status of mob has been described as
"completely dysfunctional"

https://lists.gnu.org/archive/html/tinycc-devel/2009-09/msg8.html

-- gr





The last couple of commits on that branch are listed below.

AFAICS the "warn about incorrect use of output_*" by using an enum did
never end up on mob.
We seem to have --{no-,}whole-archive by now, so that's obsolete i
guess. And the elf-interpreter toggle is in there, too, so that's fine.

Not sure what you would think about the idea i toyed with in "add
--enable-shared, part1". IIRC the idea was to cut down on memory usage
when running many tcc processes or something along those lines.

thanks!

$ git log -n7 origin/mob-stuff
commit bfa394dab88cb417bb540c32647f04d08e9838af (origin/mob-stuff)
Author: Bernhard Reutner-Fischer 
Date:   Wed Sep 2 15:55:48 2009 +0200

 Move bounds-checking code to a bcheck.a

 ... to avoid undefined references to __bound_new_region()
 (when using a libtcc1_s.so instead of libtcc1.a) on i386.

 Signed-off-by: aldot 

commit a39d055d0e666b152df87b4a603c670c3af37d68
Author: Bernhard Reutner-Fischer 
Date:   Wed Sep 2 15:55:48 2009 +0200

 Handle --whole-archive

 Support and document -Wl,--{no-,}whole-archive.

 Signed-off-by: aldot 

commit f0e8b23d02a4c06789b4b8876c65866a237ce570
Author: Bernhard Reutner-Fischer 
Date:   Tue Sep 1 13:32:34 2009 +0200

 Implement -m{uclibc,glibc} to choose elf_interp

   Support -muclibc and -mglibc (default) to choose between the elf
   interpreter like gcc does.

   $ ./tcc -o hi-glibc hello.c
   $ ./tcc -muclibc -o hi-uclibc hello.c
   $ readelf -l hi-* | egrep "(^File: | interpreter)"
 File: hi-glibc
   [Requesting program interpreter: /lib/ld-linux.so.2]
 File: hi-uclibc
   [Requesting program interpreter: /lib/ld-uClibc.so.0]

 Signed-off-by: aldot 

commit 83cb1364a606fa9fbff450a65ab68e09a5bb4e42
Author: Bernhard Reutner-Fischer 
Date:   Wed Sep 2 12:03:51 2009 +0200

 Revert "add --enable-shared, part1"

 This reverts commit 9257c5221ea4f095d813082716f786c6c5d23321.

 Signed-off-by: aldot 

commit d90eb2008b62d19f70bdd14bdf9d784b8789da5d
Author: Bernhard Reutner-Fischer 
Date:   Tue Sep 1 17:04:42 2009 +0200

 add --enable-shared, part1

   Build a libtcc.so and link the tcc binary against it.

 Signed-off-by: aldot 

commit 8a555345e3faa37ff0b2c0b84ae1f42358400923
Author: Bernhard Reutner-Fischer 
Date:   Tue Sep 1 14:27:41 2009 +0200

 warn about incorrect use of output_*

 Signed-off-by: aldot 

commit 3a40b44938d59b71d0c010579d9bd9f05e7eed46
Author: Bernhard Reutner-Fischer 
Date:   Tue Sep 1 11:52:51 2009 +0200

 allow for non-stripped install

 Signed-off-by: aldot 




___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] test failures on win32 x86-64

[grischka]

On 14.10.2022 11:24, avih via Tinycc-devel wrote:

So somehow, on win7 the address from malloc is always ~22 bits,
while on win10 msvc and new mingw gcc procude ~43 bits address,
while with tcc and old gcc malloc returns ~22 bits addresses.

and indeed, when tcc64 is compiled using tcc64 then on win10
s->sh_addr is ~22 bits, and all tests do pass _before_ d76e0323.


Well, maybe behavior of malloc on Win10 has to do with the image-base
of the process. (see objdump -x file.exe/dll | grep ImageBase)

The new gcc seems to set
   dll: ImageBase 0003.20e9
   exe: ImageBase 0001.4000

whereas the old defaults (as used by tcc) were (both win32/64)
   dll: ImageBase .1000
   exe: ImageBase .0040

These can be set using -Wl,-image-base=0x..., for example
$ gcc tcctest.c -g -I.. -O0 -w -o tcctest.exe -Wl,-image-base=0x40
or
$ tcc tcctest.c -g -I.. -O0 -w -o tcctest.exe -Wl,-image-base=0x32000


On win10 with gcc 12.2, the output ends with this:
  ./tcctest.gcc > test.ref
  make: *** [Makefile:110: test.ref] Error -1073741819
  make: Leaving directory 'D:/tmp/tcc2/tests'

and the last line at test.ref is " asm_test -"


Ok, so it seems that it is tcctest.c compiled by gcc that crashes.
Which means this problem specifically hasn't to do anything with tcc.


Then, at tcctest.c, I commented out /* RUN(asm_test); */
and the test passes.

I tried to find which line crashes at asm_test, and it's:
  strncat1(buf, " worldX", 3);

(adding exit(42) just before it exits with code 42, but exit(42)
after it is not reached).


No idea why the strncat1() asm stuff now suddenly should fail,
regardless whether with addresses hi or lo.  Of course, most
likely there is some reason ;)

Some useful command if you happen to want find out:

$ gdb tcctest.exe
  > run
  > bt
  > disass
  > info reg

--- grischka


I then tried also
  make -C tests clean
  make -C tests test3

and it's the same end of output as with test1, and same
diagnostics (pass if commenting out RUN(asm_test), else
crash at strncat1(buf, " worldX", 3)).


- avih



___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel




___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] test failures on win32 x86-64

[grischka]

On 08.10.2022 22:39, avih via Tinycc-devel wrote:

Hi,

The following tests fail for me currently (0fd7376 gnu hash) when
building tcc for win32 x86-64 (but pass when building i386)

from tests/:
- test3
- test1b


Basically we would need to know first what part of the test fails
at all.  Is it tcc compiling itself, or the compiled tcc compiling
tcctest, or is it tcctest running, or even is it maybe gcc that
crashes?

You can see the command when you call the test directly:

   make -C tests clean
   make -C tests test1


from tests/tests2/:
- 104_inline.test


This might be fixed on mob.

--- grischka



I sampled several revisions since release_0_9_27, and all of them
fail somehow, mostly in tests (one revision also failed to build).

This could be related to the mingw gcc I'm testing with - gcc 11.3.0
using mingw64 in MSYS2. I _think_ the x86-64 win32 tests did pass
in thepast, so if someone could confirm the failures it may help.

I tested as follows on Windows 10:
- launch the mingw64 MSYS2 desktop shortcut
- cd path/to/tinycc
- git clean -xfd
- ./configure --cpu=x86_64 --config-mingw32 && make && make test


regards,
avih

___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel




___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] tcc-busybox-w32 broken since 20a1ebf (tccpp : get rid of 'ch')

[grischka]

On 08.10.2022 22:50, avih via Tinycc-devel wrote:

Hi,

It's the first time I tried building it (cute), and turns out that it's 
currently broken.

tcc-busybox is:
   http://download.savannah.nongnu.org/releases/tinycc/tcc-busybox-for-win32.zip

building this busybox using tcc which was built from mob 20a1ebf
or later results in sh.exe which always prints "sh: applet not found".


Hi, I'm afraid you're right.

Fortunately commit 20a1ebf had to do with the preprocessor exclusively,
so I did add -E to the build command for the busybox and could produced
two files, one of 180.381.021 bytes and one of 180.381.020 bytes... Hm.

--- x1.c2022-10-09 02:13:59.909900800 +0200
+++ x2.c2022-10-09 02:14:02.998700800 +0200
@@ -1916652,7 +1916652,7 @@
}
max -= 150;
}
-   max /= (unsigned)8;
+   max = (unsigned)8;
i /= (unsigned)8;
 # 289 "libbb/appletlib.c"
while (i < max) {

Turned out that max(a,b) was defined as a macro, and in order to see
whether it should be applied to the 'max' above,  tcc needs to find
out whether there is a '(' following, and in course of that whether
possibly '/' could be the start of a comment, as for example in
max /* ... */ (1,2)
However seen that after having read '=' that this is not the case,
tcc (by that commit of mine) forgot to put back the '/' on the input
stream.

Anyway, fixed on mob.

As to spurious problems with MSYS2 I can only say that in my experience
it is not a completely reliable build system.

As a derivative from cygwin it shares the same fork() emulation hack,
and I've seen it sub-processes just silently terminating (or maybe not
even start them) with no failure code whatsoever.

That would not affect the built tcc itself however it could affect the
'diff' used by the tests for example.

Mostly it seems to work just fine though,  I personally don't currently
see any problems.  Known reasons could be bad interaction with some
anti-virus-defender-etc...ware.  What I see is that on a windows-10
with its 'defender' ON, building & test tcc with msys is almost twice
as slow.

-- grischka



The steps to reproduce below are using MSYS2 mingw, but it was
reproduced also after building win32 tcc in other environments.

Interestingly, renaming the binary to ash.exe seem to "fix" it. e.g.
   ./sh.exe -c 'echo hello'  #  -> sh: applet not found
   mv ./sh.exe ./ash.exe
   ./ash.exe -c 'echo hello'  #  -> hello

This happens with both win32 tcc i386 and x86-64, and tcc i386
does pass all tests (x86-64 fails some tests, but probably unrelated).

Building one commit earlier (85c32dd tccpp: integrate __has_include..)
and both i386 and x86-64 tcc build sh.exe which seem to work as expected.

I didn't try to find what fails in busybox, and the the bad commit
20a1ebf is quite big, so it's hard to pinpoint the culprit, if any.

regards,
avih


steps to reproduce using MSYS2 with mingw i686 and x86-64 installed:

the following prints "sh: applet not found" if built using tcc from
20a1ebf, but prints "OK" if built using tcc from 85c32dd or earlier.


# get the sources once:

mkdir /c/test \
&& cd /c/test \
&& wget 
http://download.savannah.nongnu.org/releases/tinycc/tcc-busybox-for-win32.zip \
&& unzip tcc-busybox-for-win32.zip \
&& git clone http://repo.or.cz/tinycc.git


# build tcc32, busybox, and test:
# MSYSTEM=... PATH=...  emulates the mingw32 desktop shortcut

cd /c/test/tinycc \
&& git clean -xfd \
&& rm -rf /c/test/tcc-busybox-for-win32/tcc \
&& (
 MSYSTEM=MINGW32 PATH=/mingw32/bin:$PATH \
 && ./configure --cpu=i386 --prefix=/c/test/tcc-busybox-for-win32/tcc \
 && make \
 && make install \
 && cd /c/test/tcc-busybox-for-win32/busybox \
 && rm -f ../sh.exe \
 && PATH=/c/test/tcc-busybox-for-win32/tcc \
 && tcc @0.tcc/busybox.tcc.rsp -w \
 && ../sh.exe -c 'echo OK'
)

# tcc64: ... MSYSTEM=MINGW64 PATH=/mingw64/bin:$PATH \
#&& ./configure --cpu=x86_64 --prefix=...

___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel




___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] e41730f11 (tcc -vv: show cross-libtcc1.a correctly (and more)) broke my libtcc code

[grischka]

On 04.10.2022 07:45, Eric Raible wrote:

Perhaps I was using libtcc incorrectly, but libtcc.h is a bit unclear about it.

The comment for tcc_set_output_type() says:
/* set output type. MUST BE CALLED before any compilation */

In reality, as of e41730f11 that is no longer good enough.
It used to be that tcc_add_symbol() would work if called before
tcc_set_output_type().
After e41730f11 tcc_set_output_type() must be called first in order to
avoid symtab_section==0.

Sure, I can fix this by calling tcc_set_output_type() first, but it
was a regression for my use case.


Hi,

Well, I think we could argue that since the output type can be also
PREPROCESS,  and since for example tcc_add_symbol() does not make
sense in that case, it is somewhat reasonable that libtcc wants to know
the output type before it would accept other specific api calls.

Such the "correct" order (if any) is:
- create the state
- set options and paths
- set the output type
- ... proceed

Incidentally just the other day after the commit there was a report
from "Chris" about all kind of strange problems that he had, and the
reason turned out was that he forgot to set any output type at all.
https://lists.gnu.org/archive/html/tinycc-devel/2022-09/msg9.html

At least that now wont happen to anyone anymore ;)

-- gr




A more general comment: tcc and the ongoing work is awesome awesome
awesome, THANK YOU!

Thanks - Eric

___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel




___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] How to build tinycc for cross-compile code for arm target on x86_64 host

[grischka]

On 02.10.2022 17:33, Giang Vĩnh Lộc wrote:

Hi all,

I will try to explain my situation as simple as I can :))

- I have x86_64 Linux machine as host
- I want to compile tcc (from source, no prebuild binary) for running tcc on 
that machine
- I have ARM Linux as target. I want to build my C code using tcc (on the 
x86_64 machine) to run on that.

How can I do this?

I tried compiling tcc on the host machine using
```
./configure --cpu=arm
make -j8
```
but it failed ...



Also, it's possible to do this on Windows? I want to compile C code using tcc 
on x86 Windows to output ARM ELF for Linux (It's likely not possible, so feel 
free to skip that)


In general it is possible to cross-compile from any host for any
target that is supported by tcc.

To build and use an arm-eabihf-tcc, for example:

  $ ./configure
  $ make cross-arm-eabihf
  $ sudo make install

  $ arm-eabihf-tcc -v hello.c

Of course, the cross-compiler needs to know where to find the header
files, crtX.o's and libraries for that target.  It might work out of
the box if those files are present in /usr/arm-linux-gnueabihf for
example.  Otherwise it is possible to create a "config-extra.mak"
manually.  See "$ make help".

The commit comment here shows how a cross-compiler for android-armeabi-v7a
can be made on windows (as well as on any other host).

https://repo.or.cz/tinycc.git/commitdiff/09808f327f1d22c4cc5a2c7f96ba65be7ee9affa

-- gr


Thank you so much!
giangvinhloc610


___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel




___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] commit e5eedc0cd

[grischka]

On 26.09.2022 23:32, Detlef Riekenberg wrote:



Hey grischka.

Reducing the search path is a good idea. Thanks for that,
but your code does not work for the i386-tcc
on x86_64-linux.


Hi Detlef, sorry about that, but there was little information in your
patch itself or in your comments what scenarios it was meant to support.

When not sure then better be more explicit than too little.

Btw. as to the below, I wonder what common files a i386 cross compiler
on x86_64 would expect to find in /usr/lib ?

--- grischka



The path are different, as cross dev packages install files in:

lib:
/usr/lib/i386-linux-gnu
/usr/lib

include:
/usr/include/i386-linux-gnu
/usr/include

crt:
/usr/lib/i386-linux-gnu

###
and /lib is a link to /usr/lib


no idea, what path are used on a musl system.


--
Regards Detlef



___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel




___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Jump optimization questions - commit: 8227db3a

[grischka]

On 25.08.2022 21:40, Ekaitz Zarraga wrote:



Hi grischka,


vtop->r and vtop->cmp_r are used interchangeably in some parts of the codebase 
and I don't really understand why.


I don't know where you see this?


I'm probably mistaken by the code I read. I'm having a hard time reading it 
honestly.


Maybe what you read was code that you just did write yourself.  It does
not however exist in the tinycc as it is visible to everybody.


Also, what is "all the C constructs modern TinyCC is using nowadays" that
0.9.27 was not using and that prevent you from just porting your patches
to current tcc?


I'm not adding anything but moving the RISC-V support to a really old GCC that 
we can compile with MesCC. MesCC is proven to work in older tcc versions but 
not in the most recent one so all our infrastructure is set up to work on that 
old TinyCC.

If you want to know more, you can take a look to:
https://gitlab.com/janneke/tinycc


Ok, so that is based on git as from Mai 2017 which was about 7 months
before release 0.9.27, with on top I'd say a rather moderate set of
changes such as to work around problems in the compiling compiler with
more than one postfix-expr in a row ("func()->x").


I have not other chance at the moment but make this backport, as well as I 
already did with GCC.

Maybe this makes some more sense to you now you know.


Actually no, it doesn't.


Could you please help me understand how this internals work?


Internals about cmp_r I assume.  Let's see ...

  $ grep -nrw cmp_r .

gives this (with hits in other target generators omitted):

  ./riscv64-gen.c:325:int a = vtop->cmp_r & 0xff;
  ./riscv64-gen.c:326:int b = (vtop->cmp_r >> 8) & 0xff;
  ./riscv64-gen.c:979:int a = vtop->cmp_r & 0xff;
  ./riscv64-gen.c:980:int b = (vtop->cmp_r >> 8) & 0xff;
  ./riscv64-gen.c:1041:  vtop->cmp_r = ireg(d) | 0 << 8;
  ./riscv64-gen.c:1076:vtop->cmp_r = a | 0 << 8;
  ./riscv64-gen.c:1093:vtop->cmp_r = a | b << 8;
  ./tcc.h:525:  struct { unsigned short cmp_op, cmp_r; }; /* VT_CMP 
operation */

Which is four lines to get its value and three lines to set it, in the
generator, and one line in tcc.h to declare it.

Now you want to connect this generator with an older tcc version without
riscv64 and no cmp_r declared in tcc.h.  And ... what was the question?
Whether it would make sense?  No.


Thank you very much,
Ekaitz


No matter,

-- gr

___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Jump optimization questions - commit: 8227db3a

[grischka]

On 25.08.2022 13:06, Ekaitz Zarraga wrote:

Hi,

Sorry for insisting but I kept working on this and found no solution.

vtop->r and vtop->cmp_r are used interchangeably in some parts of the codebase 
and I don't really understand why.


I don't know where you see this?

Also, what is "all the C constructs modern TinyCC is using nowadays" that
0.9.27 was not using and that prevent you from just porting your patches
to current tcc?

--gr


I tried using vtop->r but it just generates invalid values.

Also RISC-V does not use flags so the process is different than in the other 
architectures so I don't have a good reference to look at in any others.

Does anyone have an idea about how can I tackle this?

I managed to make the code generate the correct branch instructions but I can't 
figure out how to obtain the correct registers.

Thanks a lot,
Ekaitz


--- Original Message ---
On Thursday, August 11th, 2022 at 1:36 PM, Ekaitz Zarraga  
wrote:



Hi,

I think I have it mostly working following your advice but I cannot find how to 
map v->cmp_r to the field that was storing that information before the commit.


In the gjmp_cond in riscv:

``` c
ST_FUNC int gjmp_cond(int op, int t)
{
int tmp;
int a = vtop->cmp_r & 0xff;

int b = (vtop->cmp_r >> 8) & 0xff;

switch (op) {
```

What do I need to replace `a` and `b` with to use the previous register access 
but I can't find how to do that.

Could you please help me?

Thank you,
Ekaitz


--- Original Message ---
On Wednesday, August 10th, 2022 at 1:53 PM, Ekaitz Zarraga eka...@elenq.tech 
wrote:




Hi,

On Wednesday, August 10th, 2022 at 1:43 PM, grischka gris...@gmx.de wrote:


On 09.08.2022 20:39, Ekaitz Zarraga wrote:


Hi all,

I'm working on the RISC-V bootstrapping efforts for Guix, and I have to 
backport the RISC-V backend to an older TinyCC version we have patched in order 
to be able to build it with a simpler compiler.


I wonder why not just apply these patches to the newer tcc then?


Mostly because the compiler we use to compile TinyCC does not provide all the C 
constructs modern TinyCC is using nowadays, so we can't use it now.
We may be able to do it in the future, but our current compiler chain does not 
allow us to do that.


The process worked mostly ok, but I can't understand very well the `gtst` 
function in the generation part, and I need to write it from scratch as the 
commit 8227db3a changed how the tests and jumps are managed.


Actually that commit was to put the former gtst() function in its pieces,
now gjmp_cond(t, op) to handle VT_CMP, and gjmp_append(n, t) for the
former VT_JMP "optimization" part.


Do you mean the commit was done to split the function in two?
I'll take a deeper look and see if I can undo it properly.

Thanks for the help

___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel





___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Add missing scope modifier?

[grischka]

On 11.08.2022 17:06, pursuer2 via Tinycc-devel wrote:


I'm sorry to send a duplicate mail by mistack a short while ago.

what I really want to say is that I make a patch to add all missing scope 
modifier .
Static scope is userful when use ONE_SOURCE build mode, which can avoid 
unexpected name confilict.

The patch show below:

https://github.com/partic2/tinycc/commit/2cb29cf0eb29f4e8d79b3f1774c6b3df749af550

But the il and c67 backend are not change because I'm not sure how to test.


Better leave alone tcccoff.c too.  Other than that I think it
makes sense.  You could test with
   $ make clean && make all cross ONE_SOURCE=yes
and with "no" too.

-- gr



And will mob accept this patch?


___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel




___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] uname -o is not valid on macOS

[grischka]

On 11.08.2022 11:02, Christian JULLIEN wrote:


Here:

test "$(uname -o)" = "Android" && targetos=Android

Why not just "$(uname)" ?


Well, because on Android just uname gives "Linux".



It shows an error but script continues


___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Jump optimization questions - commit: 8227db3a

[grischka]

On 09.08.2022 20:39, Ekaitz Zarraga wrote:

Hi all,

I'm working on the RISC-V bootstrapping efforts for Guix, and I have to 
backport the RISC-V backend to an older TinyCC version we have patched in order 
to be able to build it with a simpler compiler.


I wonder why not just apply these patches to the newer tcc then?



The process worked mostly ok, but I can't understand very well the `gtst` 
function in the generation part, and I need to write it from scratch as the 
commit 8227db3a changed how the tests and jumps are managed.


Actually that commit was to put the former gtst() function in its pieces,
now gjmp_cond(t, op) to handle VT_CMP, and gjmp_append(n, t) for the
former VT_JMP "optimization" part.

-- gr


I read the `gtst` function in other architectures but I don't understand every 
field, I hope you can help me.

This is the code I managed to arrange, following what I can see in the arm and 
i386 targets, but I need to fill the gaps. I added some comments in the hopes 
you can clarify them to me.

The thing that makes me be lost the most is the variable names... `t` and such 
are a little bit difficult to follow.

``` c
/* generate a test. set 'inv' to invert test. Stack entry is popped */
int gtst(int inv, int t)
{
   // I'd love be sure of what's `t` -> I think it's the jump target. In all the
   // gtst calls I see it's `0` but then when other things are called it's set
   // to another value and returned, so it might be that: the test doesn't need
   // to jump until we insert instructions after it...?
   int v = vtop->r & VT_VALMASK;
   int r=ind;
   // What's `ind`? the current location in the code (it looks like because
   // it's incremented in o() )

   if (nocode_wanted) {
 ;
   } else if (v == VT_CMP) {
   /* TODO */
   /*
* vtop->c.i  contains the kind of the operation we need to do (we need
* to invert it if we have `inv` set, we can use `negcc` for that, which
* just converts the value to the negated version )
*  - TOK_ULT
*  - TOK_UGE
*  - TOK_EQ
*  - TOK_NE
*  - TOK_ULE
*  - TOK_UGT
*  - TOK_Nset
*  - TOK_Nclear
*  - TOK_LT
*  - TOK_GE
*  - TOK_LE
*  - TOK_GT
*  We generate the operation with that, and we need to insert the branch
*  too: then o(operation) to generate the code.
*  The branch is obtained from:
*  - r -> position
*  - t -> address
*  - fail -> for the case that the jump is too large to be encoded here
* `- That should load the address in steps and all that, but arm
*doesn't implement that yet, so we won't
*  RISC-V does not have CPU flags, where's the value stored in that 
case?
*/
t=r;
   } else if (v == VT_JMP || v == VT_JMPI) {
   // && and || optimization I don't understand
   /* Check if jump is inverted (v&1) and if the gtst was inverted at the 
same time */
   if ((v & 1) == inv) {
   if(!vtop->c.i)
   vtop->c.i=t;
   // ??
   else{
   // DOES SOME INSTRUCTION DECODING HERE -> patching previous
   // jumps?
   }
   } else {
   // Just jump?
   // Why return `t`?
   t = gjmp(t);
   gsym(vtop->c.i);
   }
   }
   vtop--;
   return t;
}
```

Thank you all for the help,
Ekaitz

PS: grischka, I added you on copy as you are the autor of the mentioned commit.




___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Segfault due to ebaa5c8 dynamic executables (PIE)

[grischka]

On 06.08.2022 21:35, Arthur Williams via Tinycc-devel wrote:

Was trying to compile X and noticed that it failed building hw/xfree86/

Turns out tcc was segfaulting by trying to deference a null address.
Bisected mob to conclude that this regression was introduced by
`ebaa5c8 dynamic executables (PIE)`.

Also built tcc with its backtracing support and re-ran to get the
following output:
```
7f282ff1293c : by ???
tccelf.c:311: by section_ptr_add
tccdbg.c:453: by put_stabs
tccdbg.c:477: by put_stabn
```


"tcc -E -g ..." I'd think almost.


And putting that all together, `section_ptr_add` received a null `Section`
which implies `stab_section` is null. Double-checked this conclusion by
adding an assert.
Not too familiar with this part of the code so thought I'd just share my
observations.

Arthur


___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Broken commit e460f7dbb216

[grischka]

On 30.07.2022 20:13, Vincent Lefevre wrote:

On 2022-07-30 19:48:29 +0200, grischka wrote:

Sorry, what?  Are you saying that (n & (n - 1)) with n == 1 -> (1 & 0)
and with n == 0 -> (0 & -1) does not evaluate to 0 in both cases always
necessarily, in C?


Yes, if the 0 happens to be a negative 0, 1 & 0 will give 1
in ones' complement, and 0 & -1 will also give non-zero in
both ones' complement and "sign and magnitude".


Okay, I was not thinking about that.  Still, nothing just "happens".

For example, 0 cannot "happen" to be a negative 0.  A negative 0
needs to be generated, for example using the complement operator ~0.

We need to be precise.  When we are considering two cases, 1 and 0
this clearly does not include a third case ~0.

What you maybe are trying to say is that we do not know whether
n = expr_const();
could maybe return a negative zero on an imaginary platform.

However this is not about tcc, it is about our knowledge about tcc
pr the platform.   If we were interested we could update our knowledge
and then we would make sure that unexpected negative zeros can never
happen.

In conclusion I think we did prove that in both the existing as well
as the imaginary tcc, the additional "(n > 1 &&" clause is and will
remain redundant and unnecessary.

--- grischka


___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Broken commit e460f7dbb216

[grischka]

On 30.07.2022 12:45, Vincent Lefevre wrote:

I changed the & to && because it is more correct and makes more sense,
but note that this is not really redundant because n is signed and
n & (n - 1) is not portable when n = 0 or 1 if two's complement isn't
necessarily used, because 0 may have several representations (well,
tcc is not designed to work on such exotic platforms, but who knows
in the future... and moreover, because of this general portability
issue, compilers may issue warnings).


Sorry, what?  Are you saying that (n & (n - 1)) with n == 1 -> (1 & 0)
and with n == 0 -> (0 & -1) does not evaluate to 0 in both cases always
necessarily, in C?


As to the "n < 0 ||" clause by the way. the C-standards seem to say:

   "Alignments are represented as values of the type size_t. Valid alignments
include only fundamental alignments, plus an additional implementation-
defined set of values, which may be empty.  Every valid alignment value
shall be a nonnegative integral power of two."

Well, when "size_t" means unsigned, how could it be not "nonnegative"
then ?!?


I don't understand what you mean here. The fact is that in the code,
n is of type int, not size_t. So the case n < 0 needs to be taken
into account. Note that n comes from

   n = expr_const();

thus may be negative.


Seems I have misunderstood what they are trying to say.  It seems that by
   "nonnegative integral power of two"
they mean any powers 0..n of two, as in
2 ^ 0..n
as opposed to
2 ^ -1.2
for example.

That hasn't to do much with "int n = expr_const();" in tcc though because
the 'n' there does not mean "2 ^ n", just as _Alignas(1) does not mean
to align at 2 ^ 1.  It means to align at 2 ^ 0 = 1.

Therfor the combination

if (n < 0 || ...
tcc_error("alignment must be a positive power of two");

still seems misleading.  "_Alignas(0x8000) int x;" is not an
invalid declaration, per se.


BTW, the condition seems incomplete because large values are forbidden.
ISO C17 says in 6.2.8p2:

   A fundamental alignment is a valid alignment less than or equal to
   _Alignof (max_align_t).

and in 6.7.5p3 (a constraint):

   The constant expression shall be an integer constant expression.
   It shall evaluate to a valid fundamental alignment, or to a valid
   extended alignment supported by the implementation for an object
   of the storage duration (if any) being declared, or to zero.



Then I think we can still accept larger values as "extended alignments
supported by implementation".  (Where really large values would crash
"the implementation" rather efficiently though).

--- grischka

___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Broken commit e460f7dbb216

[grischka]

On 28.07.2022 16:34, Detlef Riekenberg wrote:

Hi grischka.



Hi Detlef,

Please try to be more precise.  For example, in your last commit,
you wrote:

   "Do not fail with _Alignas(0) and _Alignas(1), used by autotools"

But there wasn't anything wrong with _Alignas(1), to begin with.
Also, the "(n > 1) &" part that you added in your one-line patch

   -  if (n <= 0 || (n & (n - 1)) != 0)
   +  if (n < 0 || ((n > 1) & ((n & (n - 1)) != 0)))

is just redundant.  Unnecessary redundancy confuses the readers, and
confused readers may add even more confusing stuff in sequence.
(Now I see that "(n > 1) &" has changed to "(n > 1) &&" which, well,
is still equally redundant.)

As to the "n < 0 ||" clause by the way. the C-standards seem to say:

  "Alignments are represented as values of the type size_t. Valid alignments
   include only fundamental alignments, plus an additional implementation-
   defined set of values, which may be empty.  Every valid alignment value
   shall be a nonnegative integral power of two."

Well, when "size_t" means unsigned, how could it be not "nonnegative"
then ?!?

As to your "My local workaround" below (-DTCC_LIBTCC1="\"libtcc1.a\"")
all I can say is that it does not have any effect in the context of a
tinycc as it is available in the public repo.

Maybe you do have some local configuration hacks in place that may or
may not have been disturbed.

--- grischka


After your commit related to CONFIG_TCC_CROSSPREFIX,
every compiler failed to work on Linux.
I rechecked with a clean checkout.

Broken commit:
https://repo.or.cz/tinycc.git/commitdiff/e460f7dbb2165112bc618816ec15be312b257de2

Message examples:
repo.or.cz_tinycc$ ./tcc helloworld.c -o helloworld_tcc
In file included from helloworld.c:6:
/usr/include/stdio.h:33: error: include file 'stddef.h' not found
repo.or.cz_tinycc$ ./i386-tcc helloworld.c -o helloworld_tcc
tcc: error: file 'crt1.o' not found
tcc: error: file 'crti.o' not found
In file included from helloworld.c:6:
/usr/include/stdio.h:33: error: include file 'stddef.h' not found



My local workaround:
diff --git a/Makefile b/Makefile
index 947f757..6d27eaf 100644
--- a/Makefile
+++ b/Makefile
@@ -175,10 +175,10 @@ DEFINES += $(DEF-$(or $(findstring win,$T),unx))

  ifneq ($(X),)
  ifeq ($(CONFIG_WIN32),yes)
-DEF-win += -DCONFIG_TCC_CROSSPREFIX="\"$X\""
-DEF-unx += -DCONFIG_TCC_CROSSPREFIX="\"lib/$X\""
+DEF-win += -DTCC_LIBTCC1="\"libtcc1.a\"" -DCONFIG_TCC_CROSSPREFIX="\"$X\""
+DEF-unx += -DTCC_LIBTCC1="\"libtcc1.a\"" -DCONFIG_TCC_CROSSPREFIX="\"lib/$X\""
  else
-DEF-all += -DCONFIG_TCC_CROSSPREFIX="\"$X\""
+DEF-all += -DTCC_LIBTCC1="\"libtcc1.a\"" -DCONFIG_TCC_CROSSPREFIX="\"$X\""
  DEF-win += -DCONFIG_TCCDIR="\"$(tccdir)/win32\""
  endif
  endif
And your patch is incomplete.
The cross prefix for libtcc1 is missing with -print-search-dirs


Can you please take a look?

Thanks


--
Bye bye ... Detlef


___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel



___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Segfault on musl with '-run'

[grischka]

On 20.07.2022 06:03, Arthur Williams via Tinycc-devel wrote:

Hi,

Was writing an application and noticed a bug. The script can be reduced
to the following:

```
#!/bin/tcc -run
#include 
int main() {
 struct timespec start, current;
 clock_gettime(CLOCK_MONOTONIC, ); // Segfaults
}
```

When the file is executed, it crashes at the indicated line. If I
explicitly compile the program and run it, it behaves correctly. Also tested
the same script on a glibc based machine and it also didn't crash.

Not sure exactly what's special about the call to `clock_gettime`, but
replacing it with something trivial or a printf avoids the crash.


Maybe tcc and the system disagree about the sizeof (struct timespec) ?

-- gr



Arthur

___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel




___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Bug that TinyCC Analyses Strings inside #if 0 blocks

[grischka]

On 16.07.2022 18:11, Christian JULLIEN wrote:

Hi, with mod (having your last commit),
I get this error on macOS:
/bin/sh: line 1: 32935 Segmentation fault: 11./tcctest.gcc > test.ref



Hi Christian,

seems you did use a tcc to compile tests/tcctest.c to a MACHO x86_64
executable and the executable did crash.

The tcc (I assume) you did build and install previously also from that
latest commit and probably also did run the tests on that without having
seen the problem.

If that is so then it seems that compiled executable vs. tcc -run makes
a difference.  I have no idea what it could be though.

You could try to see where tcctest crashes like so:

$ tcc -g -I. tests/tcctest.c
$ gdb a.out
  r
  bt

or using tcc's builtin stack trace:

$ tcc -bt -I. tests/tcctest.c
$ ./a.out


thanks,

-- grischka




./configure --cpu=x86_64 --config-bcheck=no --config-backtrace=no --cc=tcc 
--prefix=/Users/jullien/tinycc/static

=== /Users/jullien/local-tcc/bin/tcc

Binary directory/Users/jullien/tinycc/static/bin

TinyCC directory/Users/jullien/tinycc/static/lib/tcc

Library directory /Users/jullien/tinycc/static/lib

Include directory /Users/jullien/tinycc/static/include

Manual directory/Users/jullien/tinycc/static/share/man

Info directory/Users/jullien/tinycc/static/share/info

Doc directory /Users/jullien/tinycc/static/share/doc

/usr/include 
dir/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include

Source path /Users/jullien/tinycc

C compilertcc (0.927)

Target OS Darwin

CPU x86_64

ConfigOSX dll=no bcheck=no backtrace=no

Creating config.mak and config.h

tcc -o tcc.o -c tcc.c 
-DCONFIG_USR_INCLUDE="\"/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include\""
 -DTCC_TARGET_X86_64 -DTCC_TARGET_MACHO -DCONFIG_TCC_BCHECK=0 -DCONFIG_TCC_BACKTRACE=0 -DONE_SOURCE=0 
-DTCC_GITHASH="\"mob:af1abf1\"" -Wall -O2 -arch x86_64 -I.

tcc -o libtcc.o -c libtcc.c 
-DCONFIG_USR_INCLUDE="\"/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include\""
 -DTCC_TARGET_X86_64 -DTCC_TARGET_MACHO -DCONFIG_TCC_BCHECK=0 -DCONFIG_TCC_BACKTRACE=0 
-DONE_SOURCE=0 -Wall -O2 -arch x86_64 -I.

tcc -DC2STR conftest.c -o c2str.exe && ./c2str.exe include/tccdefs.h tccdefs_.h

tcc -o tccpp.o -c tccpp.c 
-DCONFIG_USR_INCLUDE="\"/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include\""
 -DTCC_TARGET_X86_64 -DTCC_TARGET_MACHO -DCONFIG_TCC_BCHECK=0 -DCONFIG_TCC_BACKTRACE=0 
-DONE_SOURCE=0 -Wall -O2 -arch x86_64 -I.

tcc -o tccgen.o -c tccgen.c 
-DCONFIG_USR_INCLUDE="\"/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include\""
 -DTCC_TARGET_X86_64 -DTCC_TARGET_MACHO -DCONFIG_TCC_BCHECK=0 -DCONFIG_TCC_BACKTRACE=0 
-DONE_SOURCE=0 -Wall -O2 -arch x86_64 -I.

tcc -o tccdbg.o -c tccdbg.c 
-DCONFIG_USR_INCLUDE="\"/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include\""
 -DTCC_TARGET_X86_64 -DTCC_TARGET_MACHO -DCONFIG_TCC_BCHECK=0 -DCONFIG_TCC_BACKTRACE=0 
-DONE_SOURCE=0 -Wall -O2 -arch x86_64 -I.

tcc -o tccelf.o -c tccelf.c 
-DCONFIG_USR_INCLUDE="\"/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include\""
 -DTCC_TARGET_X86_64 -DTCC_TARGET_MACHO -DCONFIG_TCC_BCHECK=0 -DCONFIG_TCC_BACKTRACE=0 
-DONE_SOURCE=0 -Wall -O2 -arch x86_64 -I.

tcc -o tccasm.o -c tccasm.c 
-DCONFIG_USR_INCLUDE="\"/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include\""
 -DTCC_TARGET_X86_64 -DTCC_TARGET_MACHO -DCONFIG_TCC_BCHECK=0 -DCONFIG_TCC_BACKTRACE=0 
-DONE_SOURCE=0 -Wall -O2 -arch x86_64 -I.

tcc -o tccrun.o -c tccrun.c 
-DCONFIG_USR_INCLUDE="\"/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include\""
 -DTCC_TARGET_X86_64 -DTCC_TARGET_MACHO -DCONFIG_TCC_BCHECK=0 -DCONFIG_TCC_BACKTRACE=0 
-DONE_SOURCE=0 -Wall -O2 -arch x86_64 -I.

tcc -o x86_64-gen.o -c x86_64-gen.c 
-DCONFIG_USR_INCLUDE="\"/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include\""
 -DTCC_TARGET_X86_64 -DTCC_TARGET_MACHO -DCONFIG_TCC_BCHECK=0 -DCONFIG_TCC_BACKTRACE=0 
-DONE_SOURCE=0 -Wall -O2 -arch x86_64 -I.

tcc -o x86_64-link.o -c x86_64-link.c 
-DCONFIG_USR_INCLUDE="\"/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include\""
 -DTCC_TARGET_X86_64 -DTCC_TARGET_MACHO -DCONFIG_TCC_BCHECK=0 -DCONFIG_TCC_BACKTRACE=0 
-DONE_SOURCE=0 -Wall -O2 -arch x86_64 -I.

tcc -o i386-asm.o -c i386-asm.c 
-DCONFIG_USR_INCLUDE="\"/Appli

Re: [Tinycc-devel] Bug that TinyCC Analyses Strings inside #if 0 blocks

[grischka]

On 13.07.2022 16:45, Ziyao wrote:

On Wed, Jul 13, 2022 at 12:01:57PM +0200, grischka wrote:

Is it necessary or a good idea to remove that behavior/feature now
from tcc?
I've seen no arguments.


Sorry for my impulsive decision.

It is a valuable feature to be honest but supposed to be described
in document I think.


To be honest, I don't know how valuable it is, or whether or not it
might be in use by someone out there.  It could be useful maybe
with libtcc applications to wrap C-code in strings, for example.


As for me, I agree with Vincent and am wishing to make TinyCC throw a
warning in this case at least,because it seems exactly to break the
language rules.


Users, as we know, are fully entitled to express their wishes freely
as well as to call a bug whatever gets in their way and not to be
bothered with the details.

But:  As soon as someone considers to patch the public TinyCC, he
cannot see himself as an user merely anymore.  He is expected to
know what he is doing and to have understood what has been done
before. (The short answer to a "Sometimes Asked Question")

See also:
https://repo.or.cz/tinycc.git/commitdiff/af1abf1f45d45b34f0b02437f559f4dfdba7d23c

-- grischka



Ziyao


___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Bug that TinyCC Analyses Strings inside #if 0 blocks

[grischka]

On 13.07.2022 17:17, Vincent Lefevre wrote:

On 2022-07-13 12:01:57 +0200, grischka wrote:

There was no bug here in tcc,  it was/is just different behavior, fully
intentional and even documented with a test case.


There was a bug in tcc: the ISO C standard requires a diagnostic.


Well, define "bug" ...?

In my book, a bug is unwanted behavior in the sense of unwanted by
the person who wrote the code.  It is when what I wrote (for example)
doesn't do what I want.

Common sources of bugs are, beyond simple mistakes, that (1) I maybe don't
really know what I want, or maybe that (2) I refuse to acknowledge that
what I want, in combination, is logically impossible.

It is not a bug, per se, when tcc doesn't work like gcc, or when it doesn't
conform to the standards in some aspect.  As long the behavior is on purpose
and consistent.  In my book.


Is it necessary or a good idea to remove that behavior/feature now from tcc?
I've seen no arguments.


Detect bugs in user code.


Which is a good thing per se, but see (2) above:  It is logically not
possible to allow new-lines in strings and at the same time help the
user to find out that for example
   "
   #if 0
   "
was not written by intention.  Because in the logic of tcc's (admittedly
non-conformant) behavior, there is no bug.  There is simply the string

   "\n#if 0\n"

At which point one could discuss -Wstrict or -Wpedantic, or maybe to give
up on the non-conformant behavior (as already shown) at all, or to replace
it eventually by the new "raw string literals" that you mentioned (my
favorite).

--- grischka


___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Bug that TinyCC Analyses Strings inside #if 0 blocks

[grischka]

On 13.07.2022 09:35, Ziyao wrote:


 "Fix wrong handling of strings which do not end properly at the end of line"


I think this conclusion is just as wrong as the initial assumption made
in the thread subject "Bug that TinyCC Analyses Strings inside #if 0 blocks".

There was no bug here in tcc,  it was/is just different behavior, fully
intentional and even documented with a test case.

(actually the behavior is as in gcc-2.95.3 which IIRC as the final release
of the 2.xx line was very good and quasi state-of-the-art at the time when
tcc was written first.)

Is it necessary or a good idea to remove that behavior/feature now from tcc?
I've seen no arguments.

--- grischka



Ziyao

---

diff --git a/tccpp.c b/tccpp.c
index 25654b2..f070640 100644
--- a/tccpp.c
+++ b/tccpp.c
@@ -944,19 +944,16 @@ static uint8_t *parse_pp_string(uint8_t *p,
  }
  }
  } else if (c == '\n') {
-file->line_num++;
-goto add_char;
+tcc_error("missing terminating %c character",sep);
  } else if (c == '\r') {
  PEEKC_EOB(c, p);
  if (c != '\n') {
  if (str)
  cstr_ccat(str, '\r');
  } else {
-file->line_num++;
-goto add_char;
+tcc_error("missing terminating %c character",sep);
  }
  } else {
-add_char:
  if (str)
  cstr_ccat(str, c);
  p++;
diff --git a/tests/tcctest.c b/tests/tcctest.c
index e969c76..f7fbd65 100644
--- a/tests/tcctest.c
+++ b/tests/tcctest.c
@@ -4253,11 +4253,6 @@ void func_arg_test(void)
  /* gcc 2.95.3 does not handle correctly CR in strings or after strays */
  #define CORRECT_CR_HANDLING

-/* deprecated and no longer supported in gcc 3.3 */
-#ifdef __TINYC__
-# define ACCEPT_CR_IN_STRINGS
-#endif
-
  /* keep this as the last test because GCC messes up line-numbers
 with the ^L^K^M characters below */
  void whitespace_test(void)
@@ -4279,20 +4274,6 @@ ntf("aaa=%d\n", 3);
  \
  ntf("min=%d\n", 4);

-#ifdef ACCEPT_CR_IN_STRINGS
-printf("len1=%d\n", strlen("
-"));
-#ifdef CORRECT_CR_HANDLING
-str = "
-";
-printf("len1=%d str[0]=%d\n", strlen(str), str[0]);
-#endif
-printf("len1=%d\n", strlen("
a
-"));
-#else
-printf("len1=1\nlen1=1 str[0]=10\nlen1=3\n");
-#endif /* ACCEPT_CR_IN_STRINGS */
-
  #ifdef __LINE__
  printf("__LINE__ defined\n");
  #endif


___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel




___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Help with tcc_add_symbol // pe_find_import in 0.9.27

[grischka]

On 22.06.2022 07:51, draco wrote:

grishka, thank you so much for pointing me in the right direction.

I was able to solve the problem (more or less) with this hint, though this 
means to patch tclDecls.h and tclIntDecls.h, two headers I took in from the tcl 
Source, so a bit problematic to maintain.

Furthermore, the __attribute__((dllimport)) is not needed, when compiling 
against libtclstubsXX.a, and was not needed in 0.9.26, behavior seems a bit 
inconsistent to me. Anyway, it's working for the moment...


I can't help you to get back the buggy implementation from 0.9.26, but
maybe you want to declare 'dllimport' symbols without actually having
to use dllimport?  Then you might want to try this:

tcc_define_symbol(s, "tclStubsPtr", "(*_imp__tclStubsPtr)");

which would redirect any usage of tclStubsPtr in client code as well
as provide a legal declaration for it from (non-patched) tclDefs.h:

   extern TclStubs *tclStubsPtr;

(-> extern TclStubs *(*_imp__tclStubsPtr); )

See also tcc/win32/include/stdlib.h for example:

   #define _environ (*_imp___environ)
   extern char ***_imp___environ;

--- grischka


Michael



IIRC tcc from 0.9.27 on tries to help with a more explicit error message
made just for that case:

 tcc: error: undefined symbol '', missing __declspec(dllimport)?

See also the libtcc_test.c example:

 /* this strinc is referenced by the generated code */
 const char hello[] = "Hello World!";

 char my_program[] =
 "..."
 "#ifdef _WIN32\n" /* dynamically linked data needs 'dllimport' */
 " __attribute__((dllimport))\n"
 "#endif\n"
 "extern const char hello[];\n"

 [...]
 tcc_add_symbol(s, "hello", hello);

FYI, the change was necessary with the introduction of 64-bit targets
to the effect that data objects that are resolved via tcc_add_symbol()
are now accessed by the same mechanism as those that come from dlls.

*This mechanism needs special code to be generated already at compile time 
which is what happens when tcc sees __declspec(dllimport) (and does not 
otherwise).*

-- grischka




___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel



___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Help with tcc_add_symbol // pe_find_import in 0.9.27

[grischka]

On 21.06.2022 12:38, Michael Richter wrote:

Symbols are added in the form tcc_add_symbol (s,"tclStubsPtr", tclStubsPtr) where 
 refers to the adress of the internal pointer from the active Tcl 
Interpreter. the stubstable is organized as a list of functionpointers, that are called 
relative to tclStubsPtr (https://wiki.tcl-lang.org/page/Stubs for further info)
With 0.9.27 this fails, wether with unkonwn symbol or, if I force tccpe to find 
the symbol, the adress gets resolved in the wrong way and coredumps.


IIRC tcc from 0.9.27 on tries to help with a more explicit error message
made just for that case:

tcc: error: undefined symbol '', missing __declspec(dllimport)?

See also the libtcc_test.c example:

/* this strinc is referenced by the generated code */
const char hello[] = "Hello World!";

char my_program[] =
"..."
"#ifdef _WIN32\n" /* dynamically linked data needs 'dllimport' */
" __attribute__((dllimport))\n"
"#endif\n"
"extern const char hello[];\n"

[...]
tcc_add_symbol(s, "hello", hello);

FYI, the change was necessary with the introduction of 64-bit targets
to the effect that data objects that are resolved via tcc_add_symbol()
are now accessed by the same mechanism as those that come from dlls.

This mechanism needs special code to be generated already at compile
time which is what happens when tcc sees __declspec(dllimport) (and
does not otherwise).

-- grischka


Further Info:
- I used the last 0.9.27 stable from Fabrice Bellard 
http://download.savannah.gnu.org/releases/tinycc/
- I compile and test it under windows (ok, wine to be exact), but use -m32 
WIN32 model to build the tcc4tcl.dll
- Tcl version is 8.6.6
Dumping the symboltable shows, that tclStubsPtr and tclIntStubsptr are in 
dynsymtable.
pe_find_import refuses to find the symbol, though sym_index >0, because the 
tested conditions are true.
(...)
sym_index = find_elf_sym(s1->dynsymtab_section, s);
 if (sym_index
 && ELFW(ST_TYPE)(sym->st_info) == STT_OBJECT // was stt_object
 && 0 == (sym->st_other & ST_PE_IMPORT)
 && 0 == a
 ) err = -1, sym_index = 0;
(...)
If I hack this to return the sym_index, the linker will link and the linked adress 
"looks" like it did in 0.9.26, but the resulting code coredumps, so something 
is terribly wrong with this.
I can't say, why the symbol gets sorted out. I don't kno, if the coredump comes 
from a false conversion of the pointer adress or if the generated asm is 
handling it wrongly. I'm stuck
Is anyone here able to point me in the right direction? Is there a patch im 
missing?
I can put up the modified code on github as a zip if anyone interested in 
getting into the details :-)
Is my problem clear enough or is there any helpful information missing?
Michael


___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel



___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Reverted commits

[grischka]

Detlef Riekenberg wrote:

Hi List.

My commits from the last 2 month where reverted.

Why?
And why without any comment?



Fixing simple bugs to make tcc more usable for all developer should be our goal.


Hi Detlef,

of course, simple bugs fixed is good, as long as no other simple
bugs are created at the same time.

For example, you removed .exe from c2str.  No comment what the
problem was.  But then c2str wasn't cleaned up anymore, as well as
not .gitignored.  In the sum two simple problems more that we had
in exchange for one problem less which we didn't have.

Just nitpicking, hope you don't mind.

Overall the commits all had a notion of preliminary, of proposals,
calling for other people to do the "real work".  As you noted in
one of them:

   "The code needs to be fixed: use the functions or remove them."

I really fixed some of them and decided to just drop the others.
I think that is more than you could expect.  If next time you decide
to do the real work yourself, including the necessary care not to cause
unwanted side effects, also to make them fit somehow nicely into the
rest of the code, and also spend some thoughts yourself on whether
or not tinycc really is the best place to solve some problem,  then
nobody will feel any need to touch your patches.


*Example Bug fixed, but patch reverted:
* arm64-tcc helloworld.c -o helloworld
No longer possible.
Startfiles are in /usr/aarch64-linux-gnu/lib
Includes are in /usr/aarch64-linux-gnu/include


Well, could you maybe share the possibly more interesting part of
your "OOTB Experience", too?   How did you make that arm64-tcc?

-- grischka


The tcc pakage from the OS is too old
and provides only i386-tcc and tcc (on x86_64),
but not for arm, arm64 and other targets


--
Bye bye ... Detlef



___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] TCC riscv32 port - Deferring code generation on external symbol

[grischka]

Sam Ellicott wrote:

Example code is here
```
.global _start
_start:
la gp, _global_pointer
la a0, _bss_start
la a1, _bss_end
bgeu a0, a1, 2f
1: sw zero, (a0)
addi a0, a0, 4
bltu a0, a1, 1b
2: # setup the stack
la sp, _stack_end
call main
```
For example when the `_global_pointer` symbol is encountered what is
the correct behavior? Since the symbol is defined in a separate
compilation unit, I'm assuming some sort of marker needs to be placed
in the .o file to indicate what immediate value goes there at link
time. However, I don't know what that is, or how it is generated.
Similarly for `_bss_start`, `_bss_end`, etc.


That 'sort of marker' thing is called 'relocation' entry.

You would emit code as if it were  'la a0, 0' but put a relocation on
it that refers to the symbol.  (In tcc, using 'greloc[a]' for example).

Whether or not the symbol is defined in the current unit doesn't really
make a difference in that regard.

With riscv it's maybe two relocations as I've seen that 'la' really is
two instructions to first load the 20 HI-bits and then the 12 LO-bits.

-- gr


Thanks!



___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] TCC riscv32 port - Deferring code generation on external symbol

[grischka]

Example?

On April 16, 2022 5:03:59 AM UTC, Sam Ellicott  wrote:
>Hi All,
>I have been working on porting tcc to generate code for riscv32
>targets and have run into an issue when writing the assembler in the
>case of an externally defined symbol. 
...

___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] compiler switches -m32 -m64 and busybox

[grischka]

Antoni Gual Via wrote:

Hello
I have recently compiled a Win64 version of TCC from the mob using the
busybox and a 0.9.27 Win64 release.

When trying to compile with the -m32 switch mentioned in the help I get
all kind of errors. I guess the headers and libs I have are all for 64
bits windows. GCC has separate lib folders for Win32 and Win64..

Is there a setting in the config of the busybox that would give me the
two sets of libraries or I should use  a completely separate
compilation for Win32?


The cross compiler and library needed for -m32 can be build using

$ make all cross-i386-win32 && make install

Ciao,

-- gr



Kind regards



___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Initialiser overflow bug

[grischka]

Arthur Williams via Tinycc-devel wrote:

On Thu, Mar 10, 2022 at 10:27:25AM -0800, Elijah Stone wrote:

Hi,

The following code results in an initialiser overflow ICE on the latest
version of tcc (917aad3), amd64 linux.

#include 
#include 

typedef struct { char b[2]; } Barb;

Barb *f(Barb x, Barb y) {
return memcpy(malloc(2*sizeof(Barb)), &(Barb[]){x,y}, 2*sizeof(Barb));
}

Note: if I declare char b[1] in Barb, there is no error; but the error
occurs on any larger size.


Posted about the same issue a month ago. And I believe someone had
reported the issue even before that. Last theory I heard was that the
cast might be affecting padding. I believe if you have
```
Barb temp[2] = {x,y};
```
and used temp in the memcpy you can avoid this issue. At least for me,
the fact the issue is so easy to avoid is why it isn't at the top of my
priority list.


The problem with

Barb temp[] = {x,y}

was that in the 1st pass (meant to determine the actual size)
tcc didn't realize that 'x' is meant to initialize the complete
struct.  Rather it assumed that braces were omitted and 'x'
was to initialize the first member of the struct.  It didn't really
care about the type of 'x' at that point.

Also fixed the problem mentioned elsewhere with array-size
expressions in function parameters:

   int main(int argc, char *argv[argc + 1]);

Anyway, some things get fixed, others get broken ...

-- gr



Arthur



___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Windows: To add .res to the extensions allowed by the preprocessor?

[grischka]

Antoni Gual Via wrote:

Hi
To build a Windows app, windres from gcc is required. By default it uses
the gcc preprocessor to resolve the defines, and gcc has its
dependencies, so a complete Mingw install is required. A command line
option in windres allows to use any other preprocessor, and using tcc's
would make the thing almost selfcontained. Unfortunately tcc's preprocessor
does'nt allow the extension .res for its inputs.
I have a tcc I built recently from the mob using the busybox Grichka made
for us poor Windows users. Which file should I check to add .res extension
to the allowed inputs for the preprocessor?


See the -xc option. As in
$ windres --preprocessor="tcc -E -xc -DRC_INVOKED" -O coff ...

winresrc.h (needed by windows.h with RC_INVOKED) and dependencies
can be found in the winapi-full-for-0.9.27 pack.

-- gr



Regards
Antonio




___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] NULL pointer dereference due to unchecked return from fdopen()

[grischka]

Christian Jullien wrote:

Thanks,
This is unfortunately not the only case where returned value is not tested, 
just for fdopen, if maintainers agree, we can probably apply:
Wdyt?


The rule is, as always:  don't write code that you cannot test.

Can you?

Otherwise, can we stop suggesting sloppily crafted quick patches
addressing non-existent problems?

Is that possible, then?

-- gr


git diff tcc*.c
diff --git a/tccelf.c b/tccelf.c
index 507e83c..bd0a1d9 100644
--- a/tccelf.c
+++ b/tccelf.c
@@ -2428,6 +2428,9 @@ static int tcc_write_elf_file(TCCState *s1, const char 
*filename, int phnum,
 return -1;
 }
 f = fdopen(fd, "wb");
+if (f == NULL) {
+tcc_error("Unable to fdopen %s for output", filename);
+}
 if (s1->verbose)
 printf("<- %s\n", filename);

diff --git a/tccmacho.c b/tccmacho.c
index 57c62c3..f94f976 100644
--- a/tccmacho.c
+++ b/tccmacho.c
@@ -800,6 +800,9 @@ ST_FUNC int macho_output_file(TCCState *s1, const char 
*filename)
 return -1;
 }
 fp = fdopen(fd, "wb");
+if (fp == NULL) {
+tcc_error("Unable to fdopen %s for output", filename);
+}
 if (s1->verbose)
 printf("<- %s\n", filename);




-Original Message-
From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On 
Behalf Of John Scott
Sent: Monday, February 28, 2022 05:18
To: tinycc-devel@nongnu.org
Subject: [Tinycc-devel] NULL pointer dereference due to unchecked return from 
fdopen()

Hi all,

I found this bug using the oomify tool at https://github.com/tavianator/oomify

The problem can be seen at tccelf.c around line 2430 (f has type FILE*):
f = fdopen(fd, "wb");
if (s1->verbose)
printf("<- %s\n", filename);

#ifdef TCC_TARGET_COFF
if (s1->output_format == TCC_OUTPUT_FORMAT_COFF)
tcc_output_coff(s1, f);
else
#endif
if (s1->output_format == TCC_OUTPUT_FORMAT_ELF)
tcc_output_elf(s1, f, phnum, phdr, file_offset, sec_order);

Note that the return value from fdopen() is not checked if it is NULL.
If the output format is ELF, then tcc_output_elf() expects that f is a valid 
FILE* variable and passes it to fwrite(), which causes undefined behavior.

I don't know how to fix this, but hope that maybe one of you folks will 
appreciate this report.


___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel



___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Fwd: [PATCH] freebsd support update proposal

[grischka]

David CARLIER wrote:

Hi if nobody objects, I may apply the last aforementioned patch
sometime next week.


Since you asked:


--- a/tests/tests2/46_grep.c
+++ b/tests/tests2/46_grep.c
@@ -14,6 +14,9 @@
  * included and reference made to  the  fact  that  reproduction
  * privileges were granted by DECUS.
  */
+#if defined(__FreeBSD__)
+#include 
+#endif
 #include 
 #include 
 #include// tolower()


- what is this (nobody will know without a comment)
- sys/cdefs.h is not that a user file should include
- 46_grep.c looks really "innocent" enough that it should compile
  OOTB on any C and platform
- in general, when tests fail, we want the problem be fixed, not the test

Maybe you can find a better solution, or maybe someone else can...

-- gr



Kind regards.



___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] [PATCH] freebsd support update proposal

[grischka]

See tccdefs.h where you can put the SIZEOF constants.

--gr

David CARLIER wrote:

fair enough. thanks.

On Sat, 29 Jan 2022 at 17:09, David CARLIER  wrote:

Hi and thanks here a new version of the patchset.

On Sat, 29 Jan 2022 at 00:18, David CARLIER  wrote:

adding few constants for compile time and fetching thread id for bound check.



___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel



___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Fwd: TCC VLA bug?

[grischka]

Michael Matz wrote:

So, the problematic type was:

  int (*)[a][b]

That's pointer to an vla-array of an vla-array of int.  All three (inner
array, outer array and pointer, but not the int) should be marked
VT_VLA.


Hm...,

IMO one (very) invariant convention is that VT_ARRAY rsp. VT_VLA
always also have VT_PTR.

Therefor if the outer pointer would have VT_VLA as you say above,
then it would be not a pointer to a VLA, but it would be a VLA,
as in

int arr[z][a][b];

Anyway, now that I already did look into it (which initially I was
trying to avoid ;) I would maybe just replace all this:


if (type1.ref->type.t & VT_VLA)
vla_runtime_pointed_size();
else {
u = pointed_size();
if (u < 0)
tcc_error("unknown array element size");
   #if PTR_SIZE == 8
vpushll(u);
   #else
/* XXX: cast to int ? (long long case) */
vpushi(u);
   #endif


by that single line:

vla_runtime_type_size(pointed_type([-1].type), ):

which looks as it would do the right thing automatically also for the
normal array (non-vla) case (but except the "unknown array size" check).

Of course one could rename "vla_runtime_type_size" to something better, then.

Btw, now that I already did look into it (which initially ... ;) I think
I found 2 related problems as can be seen with this (added to the original
test case):

// int (*arr)[h][w];
printf("diff = %d, size = %d/%d\n",
arr + 1 - arr, sizeof *arr, sizeof (*arr + 1));

-- gr



In TCC we collapse the outer array+pointer into one type (a
pointer that also has VT_ARRAY/VT_VLA set), so there actually should be
two levels: the inner level a VT_VLA pointing to the VT_INT (with its
VLA runtime length being evaluated to sizeof(int) * b) and the outer
level a VT_VLA pointing to the inner VT_VLA (and its VLA runtime length
being evaluated to inner length * a).

I'm surprised that your patch didn't cause other problems, it seems
either the testsuite isn't testing VLAs very much, or that the VT_VLA
flag is set on types where it shouldn't have been (e.g. on the VT_INT
type that is in the type->ref of the 'int [n]' array type).


Ciao,
Michael.




___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel




___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

[Tinycc-devel] Fwd: TCC VLA bug?

[grischka]

Got this report on private email.  Not sure what it means ...
-->>

Output of the code below if compiled with TCC is pretty messy:
array values are "misplaced" and overwrite each other.
But everything's ok if compiled with GCC.

#include 
#include 

int main() {
const int w = 5;
const int h = 4;
const int d = 3;

int (*arr)[h][w] = malloc(sizeof(int) * d*h*w);

int c = 1;

/* fill with consecutive numbers */
for (int z=0; zhttps://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] [BUG] 0.9.28.pre - Cannot link due to : undefined symbol 'main'

[grischka]

david.k...@libertysurf.fr wrote:

'GLFrontier-win32\src\lib\SDLmain.lib' contains an entry point to 'main'

Yet is not recognized as a library.

'GLFrontier-win32\src\lib\libSDLmain.a' contains an entry point to 
'console_main'

Both contains an entry point to 'WinMain@16', but this is "handled" by SDL.

So, I'm running out of idea how to get this linked.


"SDLmain.lib" and "libSDLmain.a" sounds like pre-made libraries for
usage with MSVC rsp. MINGW-GCC.

Both these binary formats are not compatible with tcc. See also
"tcc-win32.txt -> Limitations".

You'll need to get SDLmain.c and try to compile it from source
using tcc (which may or may not cause additional compilcations ...)

-- gr



Your thought ?

Regards, David KOCH

___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel



___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Making tinycc fully reentrant

[grischka]

Domingo Alvarez Duarte wrote:

Hello again grischka !

I finally managed to get a github workflow to build my reentrant fork of
tinycc on linux, osx and windows.

Actually there is two builds:

- one with CONFIG_TCC_SEMLOCK set to ONE here
https://github.com/mingodad/tinycc/actions/runs/1378248438

- and another with CONFIG_TCC_SEMLOCK set to ZERO here
https://github.com/mingodad/tinycc/actions/runs/1378259299 and it seems
that in both all tests pass.

Obs: You can clcik on individual builds to see the build/test output.

Please if anyone is willing to test it and give any feedback I'll
appreciate.


Sorry, forgot to mention i386-windows.  The problem seen obviously
was caused by the 2 static globals still present in i385-gen.c.

So with that corrected I can report that the 3rd test of
libtcc_test_mt
"running tcc.c in threads to run fib"
actually runs faster with your version (here, with 2 CPU cores.
~1600ms, compared to ~2600ms with the semaphore lock).

Whether any practical project exists or ever will exist that would
benefit from that is another question.  One could think of a tcc
able to compile several files in parallel for example, but maybe
people will more likely stick to make -j instead.

--- grischka


Cheers !

On 23/10/21 17:29, grischka wrote:

Domingo Alvarez Duarte wrote:

Hello Christian !

Thank you for reply !

I also noticed that there was some problems when trying to compile for
arm64 on Android under termux.

I'll put my changes here now https://github.com/mingodad/tinycc.

I did reverted all my changes !

Cheers !


Hi Domingo,

I'd say at least this is good enough to make some performance tests.
(Here it seems about 4% slower with gcc, 6% with msvc)

It doesn't seem to fulfill its promise thoug, that is libtcc_test_mt
doesn't seeom to pass with CONFIG_TCC_SEMLOCK set to 0,

Many of the 1+ lines changed could be avoided if one sticked
simply with 's1' instead of 'S'.  In fact the files not defining
USING_GLOBALS already are fully reentrant (except some functions
dealing with BufferedFile in libtcc.c which would rather belong to
tccpp.c in fact).

Of course such invasive change will cause many problems for everyone
who may have patches still laying around intended to be rebased and
published at some point in the future.  The same problems that you
will have to rebase your patch on other peoples patches that may
come in in future.

This was also the main reason why I dropped the idea of "s1 everywhere"
in 2019 and decided to go with the "quasi-reentrancy" using a semaphore
for some regions/files (tccpp, tccgen, gen-xxx, see commit 72729d8e3604).

Beside that I was looking for a "one-click" conversion method rather than
a "three days of work" method.  IIRC I've made some progress based on a
"tcc -E -C ..." patch that allows to retain comments and with some
extensions, also preprocessor statements, such that tcc -E was able
to output basically identical files.  The plan then was of course to
feed it with "#define tok s1->tok" etc. and have everything rewritten
including function protos and calls with just some commands from a shell
script. ;)

--- grischka


On 22/10/21 6:00, Christian Jullien wrote:

Hi Domingo,
Thank you for your attempt to make tcc better. However, please never
commit huge changes like this without making a branch before **and**
ask maintainers if they agree (I'm not a maintainer but an enthusiast
user).
So I strongly suggest you revert your all changes as, among others, it
breaks

- Windows:
../tccpe.c:871: warning: assignment from incompatible pointer type
In file included from ../tcc.c:25:
../tcctools.c:442: error: 'S' undeclared

- macOS
In file included from tcc.c:21:
In file included from ./tcc.h:362:
./libtcc.h:28:16: error: typedef redefinition with different types
('long' vs '__darwin_off_t' (aka 'long long'))
   typedef long off_t;
^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/sys/_types/_off_t.h:31:33:

note: previous definition is here
typedef __darwin_off_t  off_t;

Christian

-Original Message-
From: Tinycc-devel
[mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On Behalf Of
Domingo Alvarez Duarte
Sent: Thursday, October 21, 2021 20:19
To: tinycc-devel@nongnu.org
Subject: [Tinycc-devel] Making tinycc fully reentrant

Hello !

I did it once in the past and did again moving almost all global
variables to TCCState and on Ubuntu 18.04 x86_64 all tests from "make
test" pass.

It's a massive refactoring (3 full working days).

Any comments/suggestions are welcome !

Cheers !




___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel




___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Making tinycc fully reentrant

[grischka]

Domingo Alvarez Duarte wrote:

Hello Christian !

Thank you for reply !

I also noticed that there was some problems when trying to compile for
arm64 on Android under termux.

I'll put my changes here now https://github.com/mingodad/tinycc.

I did reverted all my changes !

Cheers !


Hi Domingo,

I'd say at least this is good enough to make some performance tests.
(Here it seems about 4% slower with gcc, 6% with msvc)

It doesn't seem to fulfill its promise thoug, that is libtcc_test_mt
doesn't seeom to pass with CONFIG_TCC_SEMLOCK set to 0,

Many of the 1+ lines changed could be avoided if one sticked
simply with 's1' instead of 'S'.  In fact the files not defining
USING_GLOBALS already are fully reentrant (except some functions
dealing with BufferedFile in libtcc.c which would rather belong to
tccpp.c in fact).

Of course such invasive change will cause many problems for everyone
who may have patches still laying around intended to be rebased and
published at some point in the future.  The same problems that you
will have to rebase your patch on other peoples patches that may
come in in future.

This was also the main reason why I dropped the idea of "s1 everywhere"
in 2019 and decided to go with the "quasi-reentrancy" using a semaphore
for some regions/files (tccpp, tccgen, gen-xxx, see commit 72729d8e3604).

Beside that I was looking for a "one-click" conversion method rather than
a "three days of work" method.  IIRC I've made some progress based on a
"tcc -E -C ..." patch that allows to retain comments and with some
extensions, also preprocessor statements, such that tcc -E was able
to output basically identical files.  The plan then was of course to
feed it with "#define tok s1->tok" etc. and have everything rewritten
including function protos and calls with just some commands from a shell
script. ;)

--- grischka


On 22/10/21 6:00, Christian Jullien wrote:

Hi Domingo,
Thank you for your attempt to make tcc better. However, please never
commit huge changes like this without making a branch before **and**
ask maintainers if they agree (I'm not a maintainer but an enthusiast
user).
So I strongly suggest you revert your all changes as, among others, it
breaks

- Windows:
../tccpe.c:871: warning: assignment from incompatible pointer type
In file included from ../tcc.c:25:
../tcctools.c:442: error: 'S' undeclared

- macOS
In file included from tcc.c:21:
In file included from ./tcc.h:362:
./libtcc.h:28:16: error: typedef redefinition with different types
('long' vs '__darwin_off_t' (aka 'long long'))
   typedef long off_t;
^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/sys/_types/_off_t.h:31:33:
note: previous definition is here
typedef __darwin_off_t  off_t;

Christian

-Original Message-
From: Tinycc-devel
[mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On Behalf Of
Domingo Alvarez Duarte
Sent: Thursday, October 21, 2021 20:19
To: tinycc-devel@nongnu.org
Subject: [Tinycc-devel] Making tinycc fully reentrant

Hello !

I did it once in the past and did again moving almost all global
variables to TCCState and on Ubuntu 18.04 x86_64 all tests from "make
test" pass.

It's a massive refactoring (3 full working days).

Any comments/suggestions are welcome !

Cheers !




___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Outdated .def files

[grischka]

NightStrike wrote:


You could use what we provide with tinycc, and likewise still have a
small footprint.


I would say that out of the box support for TINYC in the mingw
headers could of course be a nice option (avoiding the notorious
#define __attribute__  unless __GNUC__ for example to
start with).

Provided someone is interested to work it out and then to point
people to the related download links at mingw(-w64).

I'd suspect though that those who are interested in targeting the latest
windows achievements under tinycc could belong to a rather rare species.
And then they better should know how to help out themselves, in my opinion.

FWIW tcc's current win32 includes are from an early mingw-64 from 2009
(tinycc commit dc251a7d).  Also the winapi-full-for-0.9.27 pack on
http://download.savannah.nongnu.org/releases/tinycc/.

-- grischka


___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Outdated .def files

[grischka]

Christian Jullien wrote:

Hi Grischka,

I fact I processed differently. I was very disappointed to see that my code
compiled by tcc reported "Windows 10" on "Windows 11" because kernel32.def
lacks the few API I recently added for this purpose.


As far as I can see, "Windows 11" identifies itself as 10.0.21995(++),
that is "Windows 10" with a build number >= 21995.

And that information can be obtained simply with "GetVersion()" which
exists forever in all windoses.

While it seems that the API you just did add to the tinycc kernel32.def
already has been depreciated again:

"VerifyVersionInfoA function (winbase.h)
 ...
 Note: This function has been deprecated for Windows 10. See 'targeting
 your applications for Windows' for more information."

And even the old GetVersionEx() was admittedly added only for the stupids:

"The GetVersionEx function was developed because many existing
 applications err when examining the packed DWORD value returned
 by GetVersion, transposing the major and minor version numbers..."

(of course it's not the applications but the people who wrote them).

Seen that I'm inclined to think that much of the 3 times as big kernel32.def
from newer windoses that you did mention doesn't really serve a purpose other
than to support an increasing stupidity (or at least the assumption of it) ?!?

Or otherwise that the purpose is to make people feel more stupid than they
really are:
   "In time there will be a way to properly detect Windows 11, I'm sure
Microsoft is still figuring out the most complicated way to make life
more difficult for developers"
and
   "Don't worry, they have a guy for that I'm sure."

comments from
https://www.techpowerup.com/forums/threads/gpu-z-2-40-2-vs-windows-11.283417/

Really I don't care which scenario they want to prepare for with their OS,
but then again is is still up to us where we make TinyCC to go.

In any case saying "OUtdated .def files" means to me that you didn't really
understand anything of it.

As a fact the files were "outdated" already in their very first incarnation
when added in 2005 and haven't seen any significant changes since then.
Therefor "outdated" isn't really a category for something that never was
up-to-date nor ever even tried to be.

Btw. the easiest way to have all the functions of the windows system dll's
is just to delete the tinycc .def files on your computer.

--- grischka


___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Preprocessor directive "pragma"

[grischka]

suote127 wrote:

I made a small patch to fix this problem.All tests are passed(with make 
test).


That's good, but as you may guess, none of the tests that so far
exist was made specifically to test your new feature.  See for
example:

  #pragma pack(push+1)
  #pragma pack(pop)
  #pragma pack(push)
  struct foo { char c; int d; };
  #pragma pack(pop)
  main() { printf("size: %d\n", sizeof (struct foo)); }

should notify the user about the typo, and when you replace
the '+' by a ',' it should print 'size: 8' (not '5').

You can add one or two tests in 60_errors_and_warnings.c,
if you want.

-- grischka



Suote127




___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel






___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] [Patch] Implement __has_* operators

[grischka]

Alvarito050506 wrote:


The patch isn't great (it abuses macros, for example) so suggestions,
criticism, and feedback in general would be appreciated.


I guess that patch is two patches actually, one for the feature and
one to obfuscate tcctok.h a little bit plus adding a new file to the
project with some cryptic name plus showing a rather sophisticated
method to count tokens to everybody.

And that while I just recently could happily remove 5 files, sigh...

So, would you think we can avoid the unnecessary and let tcctok.h stay
as is, at least for now?  And approach the feature in a somehow less
spectacular way, such as with:

 /* first and last of supported attributes */
 #define SUPPORTED_ATTRIBUTES { TOK_SECTION1, TOK_MODE }

to be used like:

static int const supported_arr[4][2] = {
SUPPORTED_ATTRIBUTES,
...
?

--- gr



Thanks,
Álvaro.



___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] 114_bound_signal error when tcc is compiled by tcc on macOS M1, new -arch behavior

[grischka]

Christian Jullien wrote:

Hi folks,



Hi Christian,


gcc: error: this compiler does not support arm64  <= Sad



Grischka, can you please reconsider this choice as it seems dangerous to
me to ignore argument? Please note that my error message was the same as
gcc.


I did make considerations of course and I think the conclusion was
that this is category "fragmentary feature".  The error message
may be the same as with gcc but all the rest required to make it
a feature useful for other people is absent.

There was some aspect of "unnecessarily different" too. tcc -hh
already has a list the ignored options, there was no need to add
an extra line explaining that -arch is ignored now too.

It may be arguable how user-friendly or "dangerous" tcc is with
how it ignores some options, however I do not see the argument
to handle specifically this one differently. Rsp. arguments always
exist of course but do they justify the extra effort, that is
the consideration to be made.

--- grischka





C.





___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] -Werror=X (but ugly)

[grischka]

Christian JULLIEN wrote:

On macOS M1 (not yet fixed with long double), the latest commit
 stalls on test 60
...60_errors_and_warnings ;; runs forever


Should work now.

I did set the TCC_USING_DOUBLE_FOR_LDOUBLE for macho-arm64 instead
which might or might not have some effect.

Thanks,

--- grischka


___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] -Werror=X (but ugly)

[grischka]

Steffen Nurpmeso wrote:

grischka wrote in
 <6102f8d1.40...@gmx.de>:
 |Steffen Nurpmeso wrote:
 |> The enum adds quite a bit on top of it; the addition of
 |> set_W_flag() is, hmm, not nice, but i hope the current approach is
 |> not too heavy.
 |
 |Maybe not heavy really but unnecessary, in quite some aspects.
 |One of them that after all tinycc currently does have only
 |2 warnings where all that bit-mask fuzz can develop.
 |
 |Just in case, below the commands how you can revert this more
 |or less cleanly:
 |
 |$ git revert -n 2709b7 49cd6f 0d59ac 0c1676 a7a138
 |$ git commit -m "revert experimental -W[no-]error=X ..."
 |
 |Take care ...

\o/
Greetings to the Microsoft world!


Greetings from the blatant uncomplexers
https://repo.or.cz/tinycc.git/commitdiff/4b2c6cf3

-- gr



--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel


___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] -Werror=X (but ugly)

[grischka]

Steffen Nurpmeso wrote:

The enum adds quite a bit on top of it; the addition of
set_W_flag() is, hmm, not nice, but i hope the current approach is
not too heavy.


Maybe not heavy really but unnecessary, in quite some aspects.
One of them that after all tinycc currently does have only
2 warnings where all that bit-mask fuzz can develop.

Just in case, below the commands how you can revert this more
or less cleanly:

$ git revert -n 2709b7 49cd6f 0d59ac 0c1676 a7a138
$ git commit -m "revert experimental -W[no-]error=X ..."

Take care ...

--- grischka


Keep on going tcc :)

Ciao,

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)



___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] -Werror=X (but ugly)

[grischka]

Steffen Nurpmeso wrote:

 |  gcc -Wwrite-strings -Werror=discarded-qualifiers

Hm.  Well then this part is not compatible it seems.


Not compatible and cannot work:

const char *xxx = "123"; /* no warning or error here */
foo(); /* nobody said we would want this to stop */

$ tcc -Werror=write-strings ...
test.c:8: error: implicit declaration of function 'foo'

Because -Wwrite-strings is NOT a warning option, really.

And with
const char *xxx = "123";
strcpy(xxx,"456");
tcc would complain the "discarded const qualifier" but it cannot
track variables and code flow at compile-time in order to know
that some pointer came from a string, originally.

Forget it.


I have never
tested it that much, i usually step in when somewhere the build
fails or spits warnings like grazy.  Actually i have given up on
managing the mess that happens from compiler development.


Yes, the mess ... eventually it can be reduced:

$ git log -1 --shortstat --oneline eadcee65
eadcee65 macos: yet another tbd adjustment
8 files changed, 155 insertions(+), 169 deletions(-)

14 lines less, same functionality (although Christian claims that
it's broken since, who knows... ;)


Unfortunately tcc_warning() does not take arguments itself ...


I would (maybe) go for
tcc_warning(On_warn_badthing "bad thing did happen with %s", stuff);
with say
#define On_warn_badthing "\005"

While not sooo nice without a comma, it would allow to "manage away"
quite a few existing 'if (s1->warn_...)' clauses already and seems
somewhat easily extensible.

With some luck one might be able to implement the feature (-Werror= etc.)
and come out with +/- zero or even less additional lines required.

Currently it still adds 78 lines total though:
$ git diff --shortstat a7a138~1 2709b7
8 files changed, 126 insertions(+), 48 deletions(-)

--- grischka


___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] macOS M1 is broken since last Grischka commit

[grischka]

Christian JULLIEN wrote:

Grischka, you last set of commits breaks macOS M1 port (see make -k test
log in attachment).

Do you test your macOS changes on a real M1 machine? If you like and if
you don't have a M1 machine, I'll be glad to test your patches before
they go to mob.
Better if you create a macos-M1 branch to experiment changes which is
then merged in mod if nothing gets wrong.


Well according to one of your recent commits

#if defined(TCC_TARGET_MACHO) && defined(TCC_TARGET_X86_64)
/* Special case for Rosetta to handle --cpu=x86_64 on macOS */
else if (sizeof(double) == sizeof(long double))
memcpy(ptr, >c.ld, sizeof(double));
#endif

I was concluding that long doubles are just doubles on macos-x86_64.

If that is not the case (as the test results suggest) then I probably
was confused by what these lines were trying to say.

I still have no idea, actually.

Anyway, obviously setting TCC_USING_DOUBLE_FOR_LDOUBLE for osx-x86_64 was
a mistake but it might still apply to macos-arm64 eventually (according to
https://developer.apple.com/forums/thread/673482).

--- grischka



C.



___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] -Werror=X (but ugly)

[grischka]

Steffen Nurpmeso wrote:

Hello!

I would like to have it, but the implementation is so ugly!


Classic dilemma ...


My "natural" thought would be to have flag carriers, and simply
use bit 1 for "warn" and bit 2 for "error out", but that needs
quite some work.


Sure.  Natural and simple idea but too much work.


Also, things like write-strings play with


What "things like write-strings"?  There is only -Wwrite-strings
which is different.  Also in gcc, to stop it needs

 gcc -Wwrite-strings -Werror=discarded-qualifiers


conditions and states which later result in "something", so having
a global this_is_the_actual_warning_trigger would need to be
looked at in error1(), and the "is not warning but error" state be
deduced there only; yet, this was too complicated.


Ok, could be done all in only one place but is too complicated... (?!?)


The below thus works


(partially sometimes)


but is far from what i had in mind, which is
why i refrained from committing it (which i never tried in years
also, who still knows how that works)?



What do you think?


What we do think about what is far from what you did think? ;)

-- gr


From: Steffen Nurpmeso 
Date: Mon, 26 Jul 2021 16:18:45 +0200
Subject: [PATCH] (Complicated,ugly) -Werror=(need unrolled code) support

---
 libtcc.c | 24 +++-
 tcc.h|  2 ++
 tccgen.c | 15 ---
 3 files changed, 37 insertions(+), 4 deletions(-)

diff --git a/libtcc.c b/libtcc.c
index 2002dd56c9..eb38f339a4 100644
--- a/libtcc.c
+++ b/libtcc.c
@@ -1647,6 +1647,14 @@ static const FlagDef options_W[] = {
 { 0, 0, NULL }
 };

+/* XXX ideally .warn* would be flags, 1=only warn, 2=warn and out? */
+static const FlagDef options_Werror[] = {
+{ offsetof(TCCState, warn_write_strings_error), WD_ALL, "write-strings" },
+{ offsetof(TCCState, warn_implicit_function_declaration_error), WD_ALL,
+  "implicit-function-declaration" },
+{ 0, 0, NULL }
+};
+
 static const FlagDef options_f[] = {
 { offsetof(TCCState, char_is_unsigned), 0, "unsigned-char" },
 { offsetof(TCCState, char_is_unsigned), FD_INVERT, "signed-char" },
@@ -1938,8 +1946,22 @@ reparse:
 break;
 case TCC_OPTION_W:
 s->warn_none = 0;
-if (optarg[0] && set_flag(s, options_W, optarg) < 0)
+if (optarg[0] && set_flag(s, options_W, optarg) < 0) {
+char *sub;
+int subt = 0;
+
+/* XXX -W[no-]error= handling ugly; -W+: enum,flag carrier? */
+if ((sub = strchr(optarg, '=')) != NULL &&
+(!strncmp(optarg, "error", (uintptr_t)(sub-optarg)) ||
+ (subt = 1, !strncmp(optarg, "no-error",
+(uintptr_t)(sub - optarg &&
+set_flag(s, options_Werror, ++sub) == 0) {
+if (subt != 1)
+set_flag(s, options_W, sub);
+break;
+}
 goto unsupported_option;
+}
 break;
 case TCC_OPTION_w:
 s->warn_none = 1;
diff --git a/tcc.h b/tcc.h
index cc8a2f82b5..3bb75215e9 100644
--- a/tcc.h
+++ b/tcc.h
@@ -775,10 +775,12 @@ struct TCCState {

 /* warning switches */
 unsigned char warn_write_strings;
+unsigned char warn_write_strings_error;
 unsigned char warn_unsupported;
 unsigned char warn_error;
 unsigned char warn_none;
 unsigned char warn_implicit_function_declaration;
+unsigned char warn_implicit_function_declaration_error;
 unsigned char warn_gcc_compat;

 /* compile with debug symbol (and use them if error during execution) */
diff --git a/tccgen.c b/tccgen.c
index 833b70431a..4fd30476a4 100644
--- a/tccgen.c
+++ b/tccgen.c
@@ -5915,8 +5915,11 @@ ST_FUNC void unary(void)
 len = strlen(funcname) + 1;
 /* generate char[len] type */
 type.t = VT_BYTE;
-if (tcc_state->warn_write_strings)
+if (tcc_state->warn_write_strings) {
+if (tcc_state->warn_write_strings_error)
+tcc_state->warn_error = 1;
 type.t |= VT_CONSTANT;
+}
 mk_pointer();
 type.t |= VT_ARRAY;
 type.ref->c = len;
@@ -5942,8 +5945,11 @@ ST_FUNC void unary(void)
 if (tcc_state->char_is_unsigned)
 t = VT_BYTE | VT_UNSIGNED;
 str_init:
-if (tcc_state->warn_write_strings)
+if (tcc_state->warn_write_strings) {
+if (tcc_state->warn_write_strings_error)
+tcc_state->warn_error = 1;
 t |= VT_CONSTANT;
+}
 type.t = t;
 mk_pointer();
 type.t |= VT_ARRAY;
@@ -6384,8 +6390,11 @@ special_math_val:
(which usually start with uppercase letter) */
 || (name[0] >= 'A' && name[0] <= 'Z')
 #endif
-)
+) {
+if 

Re: [Tinycc-devel] Errors using riscv64-tcc with gcc/newlib headers

[grischka]

Sam Ellicott wrote:

Hi everyone,
This is my first time using the mailing list/patching an open-source
program, so let me know if I am doing something wrong.

I was trying to build the riscv version of tcc while using the newlib
standard library for riscv provided by GCC and I ran into a couple of
issues. First, I wanted to make the cross compiler use the newlib library
by default and I believe using the `--sysincludepaths`, `--libpaths`, and
`--crtprefix` However, I found when I tried adding these options to the
`./configure` script, they had no effect on the tcc cross compiler.
(Command and output shown below)


Honestly configure was not made to create real working cross-compilers.
cross-compilers as build by default are more or less just for developers
to catch some errors or warnings earlier.

There is however a mechanism with a file "config-extra.mak" included from
Makefile that allows to set paths and flags for cross-compilers individually:

ROOT- = ... (translated to -DCONFIG_SYSROOT=...)
CRT-  = ... (translated to -DCONFIG_TCC_CRTPREFIX=...)
LIB-  = ... (translated to -DCONFIG_TCC_LIBPATHS=...)
INC-  = ... (translated to -DCONFIG_TCC_SYSINCLUDEPATHS=...)
DEF-  = ... (translated to -DDEFINES+=...)

So once you did create the file and did add your options, it should just
work without any special further configuration.  At least that is how
it was meant to work.

See also "make help".

As to the integer defs I maybe would not add anything one can find
from anywhere.  TCC is not GCC, so just to have the minimum of what
is required to make it work should be fine as well.

Also, cygwin might not be representative for what a riscv compiler should
have.  You didn't tell what the error with "stdint.h" actually was but
obviously no "stdint.h" seen by tcc so far did require any of these defines.
Therefor it might be just a mistake on the cygwin people's side.

Maybe you can try with files from a real riscv system first?

--- grischka


I put together a small patch that seems to fix the issue
(0001-Update-build-scripts.patch). It changes the `print_mak` function in
the configure script to output these options to the `EXTRA_DEFINES`
variable (a random name I chose) instead of the `NATIVE_DEFINES` variable.
Then the `EXTRA_DEFINES` variable is always appended to the total build
defines, so that is used for cross-compilers as well as the main tcc
compiler. With this change a few other lines could probably be removed from
the Makefile as well, but I wasn't brave enough to do it.

The next issue I ran into was errors when using `stdint.h`, (specifically a
file included by it `_intsup.h`). Many base definitions that are provided
by the gcc riscv compiler were missing (like __INT32_TYPE__) along with
some pointer size definitions. I added in the pointer size definitions
generally, and the other riscv definitions were copied from definitions by
the riscv gcc compiler. This is in
(0002-stdint-base-types-for-riscv-in-tccdef.h.patch).
The file contents for _intsup.h can be found here:
https://www.sourceware.org/git/?p=newlib-cygwin.git;a=blob;f=newlib/libc/include/sys/_intsup.h;h=993121ba890b2208eb83432daf741aa0ba598d30;hb=HEAD

Thanks,
-Sam Ellicott
Soli Deo Gloria


___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

[Tinycc-devel] tinycc personal mob branches

[grischka]

Hi all, in case ...

  a) you want to show your patches for people to comment or to test, but
  b) do not (yet) want to commit on our main 'mob' branch', or, in general
  c) your work is still "in progress" rather than ready to use, and
  d) you look for a less tedious way than diffs attached to emails, but
  e) don't really want to create a full blown fork either,

here is my summary from a quick test of the "Personal Mob Branch" feature
on repo.or.cz (See https://repo.or.cz/h/mob.html).

1) One first needs to register a username at https://repo.or.cz/reguser.cgi
with an email and a public SSH key (id_rsa.pub as by "$ ssh-keygen").

2) Then it is convenient to set up a remote destination alias for the
ssh-url in tinycc/.git/config, say if you are 'fred':

[remote "personal"]
url = ssh://f...@repo.or.cz/tinycc.git

3) Then, assumed that 'fred' has a new feature on a local branch, and
that he did create (or rename) that branch already like this (with a
directory-like prefix)

mob_fred/some_feature

then this is how 'fred' can make this branch visible to the other people
as a personal mob branch:

$ git push personal mob_fred/some_feature

4) and this is how the other people can checkout his feature:

$ git fetch origin refs/mob/mob_fred/some_feature:some_feature
$ git checkout some_feature

5) and this is how 'fred' could delete a personal mob branch, finally:

$ git push personal :mob_fred/some_feature  (note the ':')

In any case, all existing remote branches including personal ones can be seen 
with

$ git ls-remote

Last, if you want to try this,  much likely your username won't be 'fred'. ;)

--- grischka


___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] TinyCC -std=c2x support?

[grischka]

Christian Jullien wrote:

Hi no one complains or comments, I suggest you push your patches end of June


Since when do we tell other people what to do and until when, in tinycc?

-- gr

___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel