Adding in a case in the re_get_caller_pc() code for defined(__CYGWIN__)
like:
#elif defined(__CYGWIN__)
*paddr = uc->uc_mcontext.eip;
for each of the 4 cases allowed this to compile. Then there were some
issues
with stdint.h failing in the libtcc.c compile because on cygwin, the
stdint.h relies
on some _intsup.h and others that require the macro definitions from gcc.
If I hack those in then I can build that.
The next problem is with lib/bcheck.c where since this is not supported, we
need CONFIG_TCC_MALLOC_HOOKS to be #undefed. However, since the
preprocessing is being done by tcc the __CYGWIN__ macro is not defined
and I can't figure out where that would go.
At that point things build but the tests fail because crt1.o, crti.o and
crtn.o
are not correctly located.
--Chris
On Tue, May 17, 2016 at 3:42 PM, Chris Marshall <[email protected]>
wrote:
> I don't mean exactly the same code but since cygwin is a flavor of posix
> system,
> it should be possible to support it the way that MacOSX, linux, and *bsd
> are.
>
> @David: ./configure works out of the box.
> make goes well until it hits tccrun.c where there is no appropriate version
> of rt_get_caller_pc() defined. I think an #ifdef for cygwin with the
> values
> eip/ebp and rip/rbp could work:
>
> make
> gcc -o tccrun.o -c tccrun.c -DTCC_TARGET_X86_64 -I. -Wall -g -O0
> -Wdeclaration-after-statement -Wno-deprecated-declarations
> -Wno-strict-aliasing -Wno-pointer-sign -Wno-sign-compare -Wno-unused-result
> -Wno-uninitialized -fno-strict-aliasing
> tccrun.c: In function 'rt_get_caller_pc':
> tccrun.c:544:33: error: 'mcontext_t {aka struct __mcontext}' has no member
> named 'gregs'
> *paddr = uc->uc_mcontext.gregs[REG_RIP];
> ^
> tccrun.c:544:40: error: 'REG_RIP' undeclared (first use in this function)
> *paddr = uc->uc_mcontext.gregs[REG_RIP];
> ^
> tccrun.c:544:40: note: each undeclared identifier is reported only once
> for each function it appears in
> tccrun.c:555:29: error: 'mcontext_t {aka struct __mcontext}' has no member
> named 'gregs'
> fp = uc->uc_mcontext.gregs[REG_RBP];
> ^
> tccrun.c:555:36: error: 'REG_RBP' undeclared (first use in this function)
> fp = uc->uc_mcontext.gregs[REG_RBP];
>
>
> Here is a link to the work done in cygwin to overlay the ucontext structure
> so it refers to the underlying windows locations:
> https://cygwin.com/ml/cygwin-cvs/2015-q2/msg00141.html
>
> --Chris
>
>
> On Mon, May 16, 2016 at 10:44 PM, David Mertens <[email protected]>
> wrote:
>
>> On Sat, May 14, 2016 at 3:27 PM, grischka <[email protected]> wrote:
>>
>>> Chris Marshall wrote: ---
>>>
>>>> To be more specific, it should be possible to build the mingw version
>>>> of tcc on cygwin (I don't know, haven't had time to try) but what I would
>>>> like is the linux/unix version---if it builds on unix, it should be
>>>> buildable on cygwin---as long as you don't look under the covers to find
>>>> windows.
>>>>
>>>
>>> Probably you could do that. It is just that you'll find that
>>> such (almost true) linux/unix version of tcc will produce
>>> (entirely) true linux/unix programs. And these will not
>>> run on windows, not even under cygwin.
>>>
>>> -- gr
>>>
>>
>> This is already the case on Macs, but we still go to some lengths to
>> support it anyway. And, just as with Macs, even if the compiled executables
>> cannot be run on Windows, the memory output can be run. Knowing Chris, I'm
>> pretty sure this is what he is most interested in. :-)
>>
>> Chris, what happens if you run ./configure on Cygwin?
>>
>> David
>>
>> _______________________________________________
>> Tinycc-devel mailing list
>> [email protected]
>> https://lists.nongnu.org/mailman/listinfo/tinycc-devel
>>
>>
>
_______________________________________________
Tinycc-devel mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
