Another development environment option!

Since the last thing that was tried was successful and allowed me to call it a night. Decided to apply just the last changes to the defective binary and see if keeping it simple was sufficient. It was. So I can document per your request right here and right now.

PE deals with dynamically loaded libraries via a couple of tables. I'll call them the:
Import Directory
Bound Import Address Table Directory

The bound import address table, i think, gets overwritten by windows with real function addresses from the dlls it loads when the program is prepped for launching. In the exe it matches a section of the Import Directory.

There's an import directory for each dll the program required and each has an entry to call out offsets to imported functions, to the dll name, and to the bound import address table directory. The imported functions pointer is: 2bytes of which has the 0x8000 bit set if it is an ordinal load and the lower 15 bits contain the ordinal number. If the 0x8000 is clear then the value of the other 15 bits is a hint to the exe loader of where the ordinal lies within the DLL. After these two bytes, if the 0x8000 is cleared sits an ASCII string with a NULL terminating character of the function name like printf, fopen, and etc.

The problem with the tcc generated exe is that it does not align these function hint + function name entries. That results in the windows ce loader hanging. By taking a problem EXE and aligning the hint base to align at 0x4 multiples the hanging went away and the code executed correctly. I tried 0x2 alignment and the hanging still occurred.

Happy to see it root caused to a simple fix rather than create and reorder sections massively like i did in hex editor. Means the tidying up of the tcc code should be very fast and straightforward.

Next steps:
1. Tidy tcc on laptop to care about alignment of the above when compiled for ARM and windows ce 2.11 and 3.0.
2. Recompile tcc-for-ce-on-ce with the fixed up tcc.
3. See if it (#2) works on native jornada to write exes for jornada on jornada
4. debug likely issues (ram limitations? file handle limitations? bug in my target specific code? etc?)

Got through 1, 2 and 3.

status can compile complex apps that run on windows ce arm 2.11 and 3.0. My dev environment is ubuntu or rooted android. and after i get thru #4 will publish and add dev environment of jornada and viewpad.





Attachments
----------------
tccce.jpg (27KB - 0 downloads)

It's alive!

Status:
Clean compilations are good. Any compilation errors and warnings go through a va_list error function and corrupts the stack resulting in app crash.

But... Clean compiles work! My first app written on jornada for jornada screenshot is attached.





Attachments
----------------
selfhost.png (7KB - 0 downloads)

I never thought I'd see the day! Stunning work sir

Very cool! Ability for Jornada application to be written on Jornada??! Great work!

thanks guys! reckon it should work on these devices too under strongarm unless ce version is too low or memory too limited:

https://www.hpcfactor.com/hardware/devices/default.asp?page=showCpu

It should also work on the XScale - PXA255's as it is a backwards compatible architecture.

This community never ceases to amaze. Awesome work.

You're probably very correct. MS seems like they are wicked good about compatibility going forwards.

For example, today I tested with two more devices and used the same TCC binary that was used on the jornada.

For Pocket PC 2003 on an HP ipaq rx3715, these steps were followed:
1. Copy tcc.exe and my lib directory containing .def files to the ipaq
2. Download windows mobile power tools to a pc and install it.
3. Grab the command prompt app from the package and copy to the ipaq
4. Copy the console.dll to windows directory
5. copy tcc.exe to ipaq's root directory and copy lib directory to ipaq's root directory
6. Create a MsgBawx.txt with pocket word and save as plain text file
7. Run console
8. Rename MsgBawx.txt to MsgBawx.c
9. Compile it with tcc
10. execute it
11. success

For HTC Touch Pro 2 (Windows Mobile 6.1) it worked after following these steps:
1. Copy tcc.exe and my lib directory containing .def files to the phone
2. Grab the command prompt app from the Windows Mobile Power tools package and copy to the phone (see above procedure #2 if you've skipped it)
3. Copy the console.dll to windows directory
4. copy tcc.exe to phone's root directory and copy lib directory to phone's root directory
5. Create a MsgBawx.txt with pocket word and save as plain text file
6. Run console
7. See nothing
8. Websearch and find that HKEY_LOCAL_MACHINE\Drivers\Console\OutputTo needs to be set to zero
9. Find a registry editor already on my sd card, yay
10. do the needful
11. Rename MsgBawx.txt to MsgBawx.c
12. Launch console
13. Realize it is not working with the physical keyboard
14. Realize that it partially works with soft keyboard in ABC mode or T9 mode
15. Type compile command and execute command into pocket word and copy to clipboard
16. Paste the command in the command prompt to compile it with tcc and subsequently execute it
17. success


wow! Would have been a 10x more thrilling thing for me if this was all in place thirteen years ago! Very impressed with MS compatibility.

Wow, amazing work! Thanks for sharing this

If they don't accept your changes into the main branch, will you upload your version as a fork onto GitHub?

Karpour, thank you!



Yes, but first I still need to ask them and to solve the stack issue and then take care of dll exports which likely have alignment requirements also. Took the pocketpc and windows mobile diversion, because it is easy and also because I could do that from the couch. Also, noticed my message never reached them: http://lists.nongnu.org/archive/html/tinycc-devel/2018-05/threads.h...

For the stack issue, have a couple hypotheses a) It's either lacking __stdcall on a vararg function that blows the stack up, or worse, b) the program growing the stack over the stack limit.

1st may be trivial to overcome by adding some attributes to said functions.

Second might need some linker options to change stack size or to allocate stack out of heap and repoint the stack pointer there. Unfortunately tcc isn't tcc-asm and I'd need to write the asm for the stack magic with embedded visual tools. Then I don't think tcc will link the generated object. Then would need to investigate grab the raw opcodes, stuff them in a memory location, and set a function pointer up to jump there and return. Hoping it is just the lack of __stdcall on vararg function. Would not, tcc does NOT crash a PC and lacks __stdcall. Maybe intel vs. arm architecture plays a role for crash avoidance in such situation?

couple of updates

using tcc to compile for windows ce accepted my request to mainline. will do soon.

using tcc on ce to compile for ce root caused the crash.

well, embarrassingly, it was myself corrupting the stack by missing a place where an open call failed vs an #ifdef guarded fopen for ce.

open < 0 is no bueno. open == 0 is bueno.

fopen == NULL (0) is no bueno


so far compilation errors and warnings are not trashing the stack any longer. more testing ahead. tomorrow is golf at torrey pines though.

An update...

First, selfishly noted, a personal milestone occurred at the aforementioned Torrey Pines outing - and no laughing - I was able to break below 100 for the first time since I started golfing a few years ago. Some would think it is a horrible score to take pride in, but it's been my goal this year and has now been achieved! On to the development environment.

As mentioned, was planning to do more testing on the native tcc running on jornada to see if I introduced any other bugs. In order to do that I needed some apps to compile. Inspecting my own apps and the samples in the CE SDK left me with one TODO item. Need a resource compiler. tcc accepts resource files compiled with windres. Two ways to solve this problem:

1. Compile the resources with windres on PC from various .rc (and associated resources) and transfer the emitted .o files to CE device to link with the native compiled .c files using the native tcc. The workflow seemed tedious and against the final goal for this endeavor.
2. If one wants to do self contained development on CE ARM devices for CE ARM devices then they'd need a native windres in addition to the tcc which is already established. The windres would be needed in order to make use of the PE file .rsrc (resources) section and provide a more elegant solution to manage strings, icons, graphics, menus, trees, etc.

Therefore I chose path #2. Wow, what a boatload of work!

Broke this problem into more parts and am nearing completion of the 2nd sub-part.

1. Compile binutils including windres on my ubuntu computer and emit a .o file from a .rc file using the self-built windres. Status: Done. This went quick.
1a. Test link the output object to a project using tcc on jornada. Status: Built the .o, but haven't tried building with tcc on the jornada yet.
2. Copy the above compilation to a new directory and detach most of the libiberty, libz, and libbfd code that are not directly involved in the windres project. Status: Mostly done.
3. Reason for detaching as described in #2, immediately above, is that this code base needs to be ported to windows ce from a very posix oriented environment. Even the windows incarnation of binutils relies on mingw. I don't want to port all of mingw to the windows ce environment. cegcc already did that Want to minimize what needs porting. Status: Not started yet, but have some ideas how to tackle some of the various posix items that windows and windows ce lacks.

One example of windres posix usage, in case still interested in reading technical detail, is that the windres uses gcc as a pre-compiler for the .rc file in order to pull in all inclusions, expand macros, and avoid #ifdef excluded code and definitions. In order to use the gcc they use pipes or alternatively temp files. For this project need to use tcc instead of gcc and also either need to hijack stdout or mandate temp files. Still deciding which way to go - both seem feasible.

golf... something I've never tried in my whole life...

There's a good golf iron enhancer just around my house though. PING and all that. (I have no idea)
smb_gaiden, I think we're really rare species out there in the world doing this right now in 2018.

And that makes us valuable. haha


Edited by stingraze 2018-10-10 11:36 AM