Re: [Tinycc-devel] Add support for Unicode entries 'wmain' and 'wWinMain' on Windows

2017-02-17 Thread avih
This caused tests failures on windows (gcc, normal configure and make, the 
build succeeds) - missing symbol "main" when running libtcc test, and many 
later tests too which probably use libtcc in memory.
Attached are two orthogonal patches, i.e. the test failures happen with or 
without also building the unicode variants of the crt files, and the tests pass 
(with the tccpe.c fix) regardless if building with or without the unicode 
variants.
I'm not entirely sure the tccpe.c fix is correct, and also not sure whether the 
wrapper c file is an acceptable solution for re-compiling the same files with 
different defines and to different .o files. Please either someone pushes a 
better fix, or tell me how to improve the patches, or just tell me to push it 
as is.
Thanks.
 

On Thursday, February 16, 2017 10:35 PM, grischka  wrote:
 

 YX Hao wrote:
> Dear grischka and group,
> Unicode entry support for windows platform is useful. Especially when
> developing programs which relays on the Unicode version APIs and takes
> Unicode arguments, it will help.
> 
> Here is my patch for this feature. I have used it for about 1 year. It has
> followed the recent commits (7b99c3ac2c9c1761d68be1192f975a39199be28d).
> 
> '-run' option is useable. And arguments converted.
> 
> Since I'm not experienced as you guys. Please give me a review.

Looks good.  Please push.  I will adjust the Makefiles later.

Thanks,

--- grischka

>  
> Best Regards,
> 
> YX Hao
> 

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


   From f5126397c1c96b3ffe866303c8177c4458df3e0e Mon Sep 17 00:00:00 2001
From: "Avi Halachmi (:avih)" 
Date: Sat, 18 Feb 2017 08:04:07 +0200
Subject: [PATCH 1/2] win: fix usage of libtcc in memory

This also fixes test failures for libtcc and other tests which were introduced
at "86e3cd0 Add support for Unicode entries 'wmain' and 'wWinMain' ..."

This fix is orthogonal to building also with the unicode variants of crt1.c
and wincrt1.c (adding those does add tcc support for wmain and wWinMain, but
the build/tests don't use them anyway, and the failures happened with or
without them).
---
 tccpe.c | 18 +++---
 1 file changed, 11 insertions(+), 7 deletions(-)

diff --git a/tccpe.c b/tccpe.c
index 8bb3d85..5c1339d 100644
--- a/tccpe.c
+++ b/tccpe.c
@@ -1760,6 +1760,7 @@ static void pe_add_runtime(TCCState *s1, struct pe_info *pe)
 const char *start_symbol;
 int pe_type = 0;
 int unicode_entry = 0;
+int user_entry = 1;
 
 if (find_elf_sym(symtab_section, PE_STDSYM("WinMain","@16")))
 pe_type = PE_GUI;
@@ -1778,12 +1779,15 @@ static void pe_add_runtime(TCCState *s1, struct pe_info *pe)
 pe_type = PE_EXE;
 if (find_elf_sym(symtab_section, "wmain"))
 unicode_entry = PE_EXE;
+else if (!find_elf_sym(symtab_section, "main"))
+user_entry = 0;  /* hopefully we're using libtcc in memory */
 }
 
 start_symbol =
 TCC_OUTPUT_MEMORY == s1->output_type
 ? PE_GUI == pe_type ? (unicode_entry ? "__runwwinmain" : "__runwinmain")
-: (unicode_entry ? "__runwmain" : "__runmain")
+: user_entry ? (unicode_entry ? "__runwmain" : "__runmain")
+: "_main"  /* not used except to report if "main" is missing */
 : PE_DLL == pe_type ? PE_STDSYM("__dllstart","@12")
 : PE_GUI == pe_type ? (unicode_entry ? "__wwinstart": "__winstart")
 : (unicode_entry ? "__wstart" : "__start")
@@ -1793,12 +1797,12 @@ static void pe_add_runtime(TCCState *s1, struct pe_info *pe)
 ++start_symbol;
 
 /* grab the startup code from libtcc1 */
-/* only (PE_Dll == pe_type) doesn't need it,
-   (TCC_OUTPUT_MEMORY == s1->output_type && PE_Dll == pe_type) is illegal */
-set_elf_sym(symtab_section,
-0, 0,
-ELFW(ST_INFO)(STB_GLOBAL, STT_NOTYPE), 0,
-SHN_UNDEF, start_symbol);
+if (user_entry) {
+set_elf_sym(symtab_section,
+0, 0,
+ELFW(ST_INFO)(STB_GLOBAL, STT_NOTYPE), 0,
+SHN_UNDEF, start_symbol);
+}
 
 tcc_add_pragma_libs(s1);
 
-- 
2.11.0

From 2a0355f51019af84c1bf34c75920e89148149aa9 Mon Sep 17 00:00:00 2001
From: "Avi Halachmi (:avih)" 
Date: Sat, 18 Feb 2017 08:13:16 +0200
Subject: [PATCH 2/2] win: makefiles: add upport for wmain and wWinMain

Prior to this commit, wmain and wWinMain were only supported at build-tcc.bat

Since crt1.c and wincrt1.c need to be compiled twice with different
defines and to different .o files, it's easier to add wrapper .c file
for each which sets the defines and includes the original file. This
makes the makefiles, and especially the main makefile, much simpler to handle.

We also change win32/build-tcc.bat to use the same wrappers and method
instead of manually specifying the defines and output files.
---
 lib/Makefile  | 2 +-
 win32/Makefile  

Re: [Tinycc-devel] x86_64 or x86-64

2017-02-17 Thread grischka

Christian JULLIEN wrote:

64bit Intel processor is used inconsistantly in different Makefile and 
configiration script.
IMHO we should use only x86_64 everywhere which is a valid C identifier. 
Scripts are more complicated to write.
Among others:
Makefile:else ifeq ($(ARCH),x86-64)grep:
libconfig.mak:ARCH=x86_64: Is a directory
configure:  echo "ARCH=x86-64" >> config.mak
conftest.c:# define TRIPLET_ARCH "x86_64"


Sure, go ahead ;)

-- gr

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


[Tinycc-devel] x86_64 or x86-64

2017-02-17 Thread Christian JULLIEN
64bit Intel processor is used inconsistantly in different Makefile and 
configiration script.
IMHO we should use only x86_64 everywhere which is a valid C identifier. 
Scripts are more complicated to write.
Among others:
Makefile:else ifeq ($(ARCH),x86-64)grep:
libconfig.mak:ARCH=x86_64: Is a directory
configure:  echo "ARCH=x86-64" >> config.mak
conftest.c:# define TRIPLET_ARCH "x86_64"

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