tinycc-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Tinycc-devel] Trouble on x86-64, not windows, not gcc


From: David Mertens
Subject: Re: [Tinycc-devel] Trouble on x86-64, not windows, not gcc
Date: Mon, 1 Aug 2016 09:50:58 -0400

FWIW, when I patch our copy of stdarg.h to #define _VA_LIST_T on Macs, the tests pass: http://www.cpantesters.org/cpan/report/a5fc4ca8-5788-11e6-bb69-be43cba39ea2

Amusingly, those are reported as test failures, but that's because I'm doing a straight text comparison of the output. The header files include a #warning with "Unsupported compiler detected" and so I get additional, unexpected text. I don't believe that this is something we want to work around; this is Apple's fault, I'd say.

Shall I modify our stdarg.h?

David

On Sun, Jul 10, 2016 at 3:29 PM, David Mertens <address@hidden> wrote:
I found a copy of Apple's _va_list.h header file:

http://opensource.apple.com/source/xnu/xnu-3248.20.55/bsd/sys/_types/_va_list.h

The offending lines are:

#ifndef _VA_LIST_T
#define _VA_LIST_T
typedef __darwin_va_list va_list;
#endif /* _VA_LIST_T */
Perhaps our stdarg.h should #define _VA_LIST_T?

On Sun, Jul 10, 2016 at 3:13 PM, David Mertens <address@hidden> wrote:
Well bother, the cpantesters site appears to be experiencing intermittent trouble at the moment. If you try to read the full report on cpantesters, you may need to hit "refresh" a few times.

On Sun, Jul 10, 2016 at 3:06 PM, David Mertens <address@hidden> wrote:
Hello Michael,

Thanks for your reply, and for explaining things. A few points of clarification are in order.

On Sun, Jul 10, 2016 at 1:21 PM, Michael Matz <address@hidden> wrote:
On Sat, 9 Jul 2016, David Mertens wrote:

When run on Mac systems, I get errors about "incompatible redefinition of
'va_list'".

Is that the message from TCC or from some other compiler?  The other compiler should use its own <stdarg.h>, not TCCs version.  If the message comes from TCC, what are the two definitions of va_list and where does the one not coming from TCCs <stdarg.h> comes from?

(Ultimately the layout of va_list has to be compatible between compilers on the same system anyway; it's dictated by the psABI.)

The error message comes from tcc. The exact text of the error (as well as a preceding warning) is:
In file included from test.c:8:
In file included from /usr/include/stdio.h:64:
/usr/include/sys/cdefs.h:81: warning: #warning "Unsupported compiler detected"
In file included from test.c:8:
In file included from /usr/include/stdio.h:71:
/usr/include/sys/_types/_va_list.h:31: error: incompatible redefinition of 'va_list'
I'm assuming that tcc picked up its own va_list definition first. Then when it pulled in stdio.h via the system header files, they pulled in a different va_list as illustrated in the series of include provided by the error message. Probably, then, the problem is that everybody is using preprocessor definitions for va_list, and because the tokens that clang uses (a builtin _expression_) is different from the struct that tcc uses, tcc can't figure out that the two are actually compatible. If that's the case, I'm not entirely sure how to go about fixing the problem.
 
<snip>

Normal BSDs use the sysv ELF psABI, so better have the same definition of va_list like in TCCs <stdarg.h>.  Darwin uses the same layout as sysv as well.  What could happen is that there are some (and different) type aliases in between va_list and the real struct type.

<snip>

Solaris as well.

TCC's handling of variable argument lists are spelled out in stdarg.h, with implementation in libtcc1.c. I think that for 64-bit machines, we should also check for clang, and then use clang-compatible definitions. I think I could just check if __llvm__ and/or __clang__ are defined, and then insert the appropriate definitions. Does this sound right?

Not quite.  The definition of va_list depends on the system, not on the compiler.  clang can be used with different systems.  So if anything the appropriate define would be something MacOS/Darwin related.

Right, your above explanation makes clear that this idea is not the right approach.
 
I'd be happy to work on a solution, but I don't have access to a Mac machine
or a BSD system. I'm not interested in going through a full-on BSD
installation at this time, so if anybody knows where I could find a
pre-canned BSD virtualbox image with working git and cc, I'd be much
obliged.

You need some Darwin system to properly solve this.  I wonder how you get the above error message on Mac if you don't have to Macs?

Quite the puzzle, isn't it. (・_・ヾ

This error comes from a CPAN test report for Alien::TinyCCx, a perl distribution of mine that distributes tcc with extended symbol table support. The full test report can be found at http://www.cpantesters.org/cpan/report/b1b60820-29ae-11e6-9071-5d9dc272c7fc, with thanks to Nigel Horne for setting up his automated Mac testers. I cannot believe that this error is due to the exsymtab work, but if there is any concern, I can update a similar distribution, Alien::TinyCC, which is supposed to distribute the main tcc. We could then wait a few days for the smoke testers to pick it up and test it. It is a rather slow iteration cycle.

For what it's worth, I didn't get these errors on the Macs I used to have access to (machines used for data acquisition in intro physics labs), and I strongly suspect they were older 32-bit machines. I may soon have access to Macs at work, but I'm in between jobs at the moment, and so I can't test this myself.

@grishka, I was actually considering an approach that you had committed quite a bit earlier: http://repo.or.cz/tinycc.git/commitdiff/dc251a7d8d8bb4fb57773790152bfe85236f5f12#patch2

David

--
 "Debugging is twice as hard as writing the code in the first place.
  Therefore, if you write the code as cleverly as possible, you are,
  by definition, not smart enough to debug it." -- Brian Kernighan



--
 "Debugging is twice as hard as writing the code in the first place.
  Therefore, if you write the code as cleverly as possible, you are,
  by definition, not smart enough to debug it." -- Brian Kernighan



--
 "Debugging is twice as hard as writing the code in the first place.
  Therefore, if you write the code as cleverly as possible, you are,
  by definition, not smart enough to debug it." -- Brian Kernighan



--
 "Debugging is twice as hard as writing the code in the first place.
  Therefore, if you write the code as cleverly as possible, you are,
  by definition, not smart enough to debug it." -- Brian Kernighan

reply via email to

[Prev in Thread] Current Thread [Next in Thread]