Re: [Tinycc-devel] _Generic or __builtin_choose_expr

[Michael Matz]

Hi,

On Fri, 30 Jun 2017, uso ewin wrote:

> I'd like to do that, problem is with default:
> if we encounter a default,
> we need to remember that there is a default in the generic,
> but we need to continue parsing generic expression to check
> if there is a type that match, and with you technique we can't go back and
> re-evaluate default if at the end, no match was found.

Aw, crap, right, they've introduced more syntax that defeats single-pass 
parsing.  Okay, then your token saving code is nevertheless buggy 
I think.  E.g. what are you using 'i' for: you sometimes increase it, but 
zero it always, and never make use of it.  And this code will be wrong 
when presented with an expression like 'call(a,b)' because of the skipping 
on ','.  Instead of doing it yourself try to use skip_or_save_block.  
Despite its name it can also be used to skip expressions (i.e. stops at 
outer ',') and should be usable here.

(You also don't make use of the outer buf[], so remove it and its 
setting).  Oh, and your call to unary() should be expr_eq, the accepted 
expressions after the ':' are assignment-expression, not just unaries.


Ciao,
Michael.

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

Re: [Tinycc-devel] _Generic or __builtin_choose_expr

[Michael Matz]

Hi,

On Tue, 4 Jul 2017, grischka wrote:

> Michael Matz wrote:
> > First string literals are now always const char, ...
> 
> Hm... ;)
> 
> Actually the behavior with -Wwrite-strings that we had is what
> gcc has too:
> 
> typeof("123") cc = "456";
> cc[1] = 'x';
> printf("%s\n", cc);
> 
> $ gcc -Wno-write-strings ...
> 4x6
> $ gcc -Wwrite-strings ...
> error: assignment of read-only location 'cc[1]'

Ugh, you're right.  Indeed the standard doesn't mandate a const char[] 
type for string literals (I was confused because it does say that 
modification of string literals is undefined, i.e. that's an extension).  
Let me work on this a bit.

> (mingw gcc 3.4.2 and 6.3.0)
> 
> Also, now tcc doesn't warn with this one anymore:
>const char cc[] = "456";
>char *p = cc;

Yeah, that was conscious on my part but still under the influence of the 
above confusion ;-)


Ciao,
Michael.

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

Re: [Tinycc-devel] _Generic or __builtin_choose_expr

[Michael Matz]

Hi,

On Tue, 4 Jul 2017, Michael Matz wrote:

> Ugh, you're right.  Indeed the standard doesn't mandate a const char[] 
> type for string literals (I was confused because it does say that 
> modification of string literals is undefined, i.e. that's an extension).  
> Let me work on this a bit.

Actually, not much need for work.  I've checked GCC sources and, even 
though it wonders in a comment if it's a good idea to change expression 
types with warning flags, it indeed does so; so if for nothing else than 
compatibility I've reverted the patch.

The hack in the current patch for _Generic (to regard string literals as 
const char* always) isn't needed.  GCC indeed differs in behaviour 
depending on the warning flag, also in _Generic:

---
extern int printf(const char *,...);
int main()
{
  const char *msg;
  msg = _Generic("foo", const char *:"const char*", char*:"char *", 
default:"something else");
  printf ("type \"foo\" = %s\n", msg);
  return 0;
}
---
% gcc-6 -Wwrite-strings x.c && ./a.out
type "foo" = const char*
% gcc-6 -Wno-write-strings x.c && ./a.out
type "foo" = char*

So, thanks for checking after me ;)


Ciao,
Michael.

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

Re: [Tinycc-devel] _Generic or __builtin_choose_expr

[Michael Matz]

Hi,

On Mon, 3 Jul 2017, uso ewin wrote:

> I've try to use skip_or_save_block but using this function would ask me to
> completely refactor it,
> so I've made a skip_or_save_block2
> (code here: 
> https://github.com/cosmo-ray/tcc/commit/48e16cb2e33ea39b5051992ab23b006523fd14b4
> ),
> it work mostly like skip_or_save_block but, don't allocate TokString,
> and ignore braces, as brace should not be take into account inside
> a generic expression (I'm not sure here).

The braces are necessary for the GNU extension of statement expressions:

  ({ int i = 42; i; })

is a valid expression (in GNU C).  Anyway, I've just pushed some changes 
to mob which should simplify your life a bit.  First string literals are 
now always const char, so your hack with is_str and overriding the type 
shouldn't be needed anymore.  Second skip_or_save_block should now be 
directly usable for you (if called on non-'{' it collects the tokens until 
comma or ')'; or semicolon or '}' but those latter are syntax errors which 
will be diagnosed when actually parsing that token string).

In your patch you have also this after the loop:

  +skip(')'); 
  +tok_str_add_tok(); 
  +tok_str_add(, 0); 
  +begin_macro(, 2);
  +next();
  +expr_eq();

That doesn't seem right.  You add the token after the ')' that 
closes the _Generic expression to the token string that you evaluate 
afterwards.  That is you'd parse "_Generic(x,default:1 + 2) * 2" as
"1 + 2 * 3", but it should be parsed as "(1 + 2) * 3" (note operator 
precedence).  The correct idiom for parsing a saved string of tokens as 
expression would be something like this:

ParseState saved_parse_state;
...
// assume str contains the token string
skip(')');
save_parse_state(_parse_state);
begin_macro(str, 1);
next();
expr_eq();
end_macro();
restore_parse_state(_parse_state);

(note also the '1' in begin_macro).  The above sequence relies on TOK_EOF 
being part of str (like skip_or_save_block does), but without such 
separator you'd always run into the 1+2*3 problem from above, and the 
above is still only one line longer than your sequence :)

You have to take care to not create leaks inside the loop if you see a 
matching type after a default association, the str needs to be freed 
appropriately (you have a similar leak in there, str is a local variable 
but the contents (the ->str member) is simply overwritten and leaks).

So, can you re-try implementing your _Generic parsing with the new 
skip_or_save_block from mob and with the above remarks taken into account?  
Sorry for the back and forth, but let's try to create a tiny change with 
the largest impact and avoid code duplication ;)


Ciao,
Michael.

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

Re: [Tinycc-devel] tinycc predefined macro

[Michael Matz]

Hi,

On Wed, 28 Jun 2017, Gabriele Fulgaro wrote:

> Can tinycc implementing in future __COUNTER__ macro?

Would be easy to do.  Why do you need it specifically?  It's 
non-standard.  Even though a couple compilers provide it, it would be good 
to have some rationale for adding it.


Ciao,
Michael.

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

Re: [Tinycc-devel] _Generic or __builtin_choose_expr

[Michael Matz]

Hi,

On Wed, 28 Jun 2017, uso ewin wrote:

> > Are there any plans for C11's _Generic or at least __builtin_choose_expr?
> >
> >
> > Best regards,
> > Petr Skocik
> >
> > ___
> > Tinycc-devel mailing list
> > Tinycc-devel@nongnu.org
> > https://lists.nongnu.org/mailman/listinfo/tinycc-devel
> 
> Hello,
> 
> I was working on _Generic implementation on tcc(as an hobby)
> Your mail made me want to continue my job, and yesterday I've succeed
> to make something usable:
> https://github.com/cosmo-ray/tcc/commits/generic

Thanks for working on this.

> The code as it is actually is pretty crappy, doesn't respect C
> standard(main difference is I can't make difference between a char*,
> an int * or any kind of pointer), but should be enough for most use
> case, and pretty easy to merge on mob
> 
> should I try to merge it to mob once I've clean my commits ?
> maybe by adding some option like: "--with-fake-generic" ?
> So _Generic are not enable by default

Hmm.  I'd dislike an implementation of _Generic that isn't standard 
conforming (at least in most cases and as far as we know).  So try a bit 
harder to implement it fully :)  (I.e. you might need to extend 
compare_types)  A separate option wouldn't be needed then.

I've very briefly looked at your implementation: Don't use your current 
way of parsing the controlling expression/type, you should be able to 
reuse expr_type/parse_expr_type/parse_type (or parts of it).


Ciao,
Michael.

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

Re: [Tinycc-devel] _Generic or __builtin_choose_expr

[Michael Matz]

Hi,

On Tue, 4 Jul 2017, uso ewin wrote:

> I've just force push the change on my github, so now it should have the 
> same behaviour as gcc

Please move the tests to a new file in tests/tests2/94_generic.c .
Then I think this can go into mob.


Ciao,
Michael.

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

Re: [Tinycc-devel] Annoying new warning

[Michael Matz]

Hi,

On Sat, 29 Apr 2017, Christian Jullien wrote:

No one looking at it? What is the behavior of this test when lower is 
unitialized?


As the comment above the structure clearly says, this is the layout for 
x86 only (the x87 80bit long double type).  ARMs long double type simply 
is double itself, and hence these functions are unused on ARM.  Well, they 
would be if there wouldn't be strange code in arm-gen.c that makes use of 
xfdi conversions when VFP is enabled.  That makes no sense, also with VFP 
there's only support for IEEE double, not for extended double.


So the fix for this would entail ifdefing the XF routines in libtcc1.c, 
and not using them in the arm backend.



Ciao,
Michael.

 > 

 

From:  Christian JULLIEN

  Subject:  [Tinycc-devel] Annoying new warning

Date:  Thu, 20 Apr 2017 09:29:31 +0200 (CEST)

 

Trying to build mob on RPI I now get this new warning

 

gcc -c ./lib/libtcc1.c -o libtcc1.o -DTCC_TARGET_ARM -Wall -g -O2
-Wdeclaration-after-statement -Wno-pointer-sign -Wno-sign-compare
-Wno-unused-result -fno-strict-aliasing -I.  -fPIC

./lib/libtcc1.c: In function __fixunsxfdi:

./lib/libtcc1.c:586:26: warning: dl1.l.upper is used uninitialized in this
function [-Wuninitialized]

 if (dl1.l.lower == 0 && dl1.l.upper == 0)

  ^

 

unsigned long long __fixunsxfdi (long double a1)

{

    register union ldouble_long dl1;

    register int exp;

    register unsigned long long l;

 

    dl1.ld = a1;

 

    if (dl1.l.lower == 0 && dl1.l.upper == 0)

    return (0);

 

 

And union is defined as:

 

/* only for x86 */

union ldouble_long {

    long double ld;

    struct {

    unsigned long long lower;

    unsigned short upper;

    } l;

};


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

Re: [Tinycc-devel] bitfield handling

[Michael Matz]

Hello,

On Tue, 2 May 2017, grischka wrote:


Michael Matz wrote:
I chose to adjust field layout instead of field type; the latter can cause 
invalid mem accesses with packed structs/fields: 


Hi Michael,

May I suggest something:

It appears to me that it's the point of packed (pcc) bitfields that
all bits are fully tightly packed with no padding whatsoever, such that
they can be used for decoding bit-stream protocols or some such.


No, the (my) point always was to be compatible with existing compilers in 
the sense that bitfields are layed out as the source author customized to 
$compiler expected/intended or was used to.  All my changes were about GCC 
and MSVC compatibility (for GCC see (*)).  At least insofar as bitfields 
are required in gawk and linux kernel and strange hand-written testcases.


[side mark: The rationale for msvc or pcc or $whatever bitfield layout is 
really of no consequence (i.e why they decided to put the bits here or 
there); most probably nobody can explain anymore why they chose this or 
that specific layout of bit-fields (and in fact many CPU vendors didn't 
think about this at all; they used whatever was default with GCC).  But 
the layout of _tcc_ bitfields IMHO should be clear: they should follow 
whatever the native compiler (i.e. GCC or MSVC)  is doing.; if 
realistically possible]


Yes, we could simplify the bitfield layout code quite much by ignoring 
this aspect (i.e. devise a TCC specific layout and be done with all the 
strangenesses).  IMHO we shouldn't.



"More or less" packed isn't better than not at all in that case
because it is just not what people will expect (I suppose).

Therefor I'd suggest to revert the layout code to the point where it
actually was producing the correct layout, then comment out the
pcc:packed part and substitute by a warning "currently unsupported",
for now.


So ... (as per above) reversion is IMHO out of question, all the changes 
were made for a reason.  Perhaps my comments are crappy (and I'd admit 
that parts of them are crappy because the bitfield layout code in GCC is 
_really_ complicated and that I skimmed over details) but that shouldn't 
stand in the way of code.


OTOH your mentioning of "to the point where it actually was producing the 
correct layout" indicates that it's not producing correct (i.e. expected) 
layout/code anymore.  Examples?  Because, really, I fixed struct bit-field 
incompatibilities with both MSVC and GCC, and hence am interested where 
it's getting things still wrong.  (Yes, the recent report was an example. 
I haven't checked if it got everything right before by design or luck, or 
superstition.)  Still, other examples where things go wrong would be 
appreciated. :)



Ciao,
Michael.

(*) GCC compatibility: GCC started out as alternative compiler for $random 
platform, where range($random) really was large.  At that time it was 
therefore an alternative compiler for whatever existed on the machine 
(e.g. the C runtime library).  For that GCC needed to emulate all aspects 
of the ABI (how functions are called; at that time the concept of ABI 
wasn't widespread, but existed) that the native compiler would produce 
(e.g. procedure calling conventions for functions in libc).  Many of the 
ABIs were based on whatever PCC (portable C compiler) produced, they 
weren't in fact really thought out, especially in the corner aspects 
(bit-fields!).  So, in the end many of the traditional unix ABIs for 
random architectures are actually just what "the" compiler happened to 
produce".  And from then it went "oh, but we need to be compatible". 
That's why PCC bit-field layout still exists, and isn't just called GCC 
bit-field layout; because it isn't.  It's the traditional "if I don't do 
anything special then this is what I get" layout :)


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

Re: [Tinycc-devel] bitfield handling

[Michael Matz]

Hi,

On Wed, 3 May 2017, grischka wrote:

> However, suppose we have a field with bit_pos=5,bit_size=32.
> In order to read it we need to read 40 bits, yes?  How do we
> do that on a 32-bit target, for example?

Yep, we don't (i.e. we're buggy in these cases and always were).  It's one 
example of the class of problems I'd added a comment on (tcctest.c ca. 
line 2070):

#ifndef __i386__
/* on i386 we don't correctly support long long bit-fields.
   The bitfields can straddle long long boundaries (at least with
   GCC bitfield layout) and code generation isn't prepared for this
   (would have to work with two words in that case).  */
...

;-)

This also extends to long bit-fields straddling more than four bytes on 
32bit (or eight bytes on 64 bit).  Luckily those seems to happen 
relatively seldom in practice.

> Test code attached, have fun ... (no hurry ;)

He, thanks.  Yeah, eventually.


Ciao,
Michael.

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

Re: [Tinycc-devel] _Generic or __builtin_choose_expr

[Michael Matz]

Hi,

On Fri, 16 Jun 2017, Petr Skočík wrote:

> Are there any plans for C11's _Generic or at least 
> __builtin_choose_expr?

__builtin_choose_expr is implemented since July last year.


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

Re: [Tinycc-devel] building older gcc with tcc?

[Michael Matz]

Hi,

On Sat, 27 May 2017, ra...@openmailbox.org wrote:

I would like to build an older version of the gcc compiler using tcc 
(then use that to build newer gcc's). On this page 
 it says that tcc 
was used to build gcc in the past.


I did that once in 2012 with gcc 4.x, 5<=x<=7 (don't remember exactly 
which) on x86_64.  At the time I had to fix a couple bugs in tcc to make 
this work.  That obviously regressed since then.


I tried using the latest http://repo.or.cz/tinycc.git to build gcc 4.7.0 
(one of the latest C versions before it was rewritten in C++) like so:


MAKEINFO=missing CC=tcc CFLAGS='-I/usr/include/x86_64-linux-gnu/' 
PCC=tcc ./configure --enable-languages=c,c++ --disable-multilib 
--prefix=$HOME/gcc-out


but I got an error:

../.././libgcc/libgcc2.c: In function ‘__negti2’:
../.././libgcc/libgcc2.c:73:1: internal compiler error: Segmentation 
fault

Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

this seems to be a bug in a program 'xgcc' that was built by tcc


Rather it seems that cc1 was miscompiled.  Is the above in stage1 or 
later?  If stage1 then tcc miscompiled something in cc1 fairly directly, 
if later then tcc miscompiled cc1 in a way that it somewhat works but 
ultimately miscompiles itself.  Those miscompiles tend to be difficult to 
track down; you'll have to basically bisect which .o file is miscompiled 
(by compiling parts of them with a known-good compiler or known-good 
options, and the other parts with known-bad compiler/options), and then 
either doing the same for the individual functions in that file, or by 
otherwise staring at the disassembly for both variants.


If the above is stage1 then it might be a bit easier, namely when the seg 
fault above happens near the place where the miscompile occurs (and not 
somewhere far away just causing some internal data structures to be wrong 
leading to the segfault much later).  So, you'd have to start debugging 
the segfaulting cc1 (adding -v to the failing command will show you how 
it's invoked) and see of anything obvious pops up that doesn't match the 
source code.


A still different way would be to see if any tcc version of the past was 
behaving correctly.  If you find one you can also bisect between that and 
current mob to find which patch lead to breakage, and from there find the 
miscompilation easier.


Obviously all of the above requires non-trivial amounts of work :)


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

Re: [Tinycc-devel] building older gcc with tcc?

[Michael Matz]

Hi,

On Sat, 27 May 2017, Michael Matz wrote:


Obviously all of the above requires non-trivial amounts of work :)


Actually it was in stage1 and the problem was parameter passing on x86-64. 
I was sitting on a patch for a time that rewrites that and happens to fix 
the problem, so I've pushed that to mob now.  I.e. gcc 4.7.4 can be 
compiled again by TCC.



Ciao,
Michael.

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

Re: [Tinycc-devel] Add support of musl-libc to tinycc

[Michael Matz]

Hi,

On Sat, 6 May 2017, Larry Doolittle wrote:


Micheal, Marc, and tinycc lurkers -

On Sun, May 07, 2017 at 04:54:38AM +0200, Michael Matz wrote:

On Thu, 20 Apr 2017, Marc Vertes wrote:

I just committed the patch to support musl-libc in the tcc
compiler development branch: http://repo.or.cz/w/tinycc.git
[...]
Dear tinycc developers, let me know if this feature can be added
to the upcoming 0.9.27 version, and also how to fix the DLL
bootstrap problem.

Fixed in mob.  The problem is the stricter dynamic loader of musl,
which ignores all STB_LOCAL symbols for symbol resolution [...]
With that the tests also run on musl.  [...]


On Debian Jessie amd64 with musl-dev installed, tinycc (commit 5732a188)
detects that musl exists (CONFIG_musl=yes in config.mak), builds OK, but
fails on make test at dlltest:

./tcc2 -B.. -I/home/larry/git/tinycc/include -I/home/larry/git/tinycc -I.. 
-DCONFIG_TRIPLET="\"x86_64-linux-gnu\"" -DTCC_TARGET_X86_64 -DTCC_MUSL 
-DONE_SOURCE -run /home/larry/git/tinycc/tcc.c -B.. -I/home/larry/git/tinycc/include 
-I/home/larry/git/tinycc -I.. -run /home/larry/git/tinycc/examples/ex1.c
/usr/lib/x86_64-linux-gnu/libc.so:2: error: unrecognized file type
tcc: error: Unknown relocation type: 23


On debain, if you have libc6-dev and musl-dev installed you get a strange 
mix of glibc and musl objects and shared libraries linked into the exe. 
E.g. in the above it picks up /usr/lib/x86_64-linux-gnu/libc.a (from 
glibc), which has TPOFF32 relocs and those aren't handled by TCC.


Removing libc6-dev, installing musl-tools, and using musl-gcc for 
compilation ensures that there's no mixture at least.  But that then fails 
because TCC itself isn't prepared to look into e.g. 
/usr/include/x86_64-linux-musl for standard headers like e.g. stdio.h, 
neither does it look into /usr/lib/x86_64-linux-musl/ for startup files 
like crt1.o.  So, yeah, the detection/support of musl is early and doesn't 
work with the split-mind approach that debian is using.


It does work for the setup of musl as the main libc, like with alpine 
linux; so I'm not sure the detection should be disabled or rather be 
improved (or there should perhaps be a configure option to override the 
detection by users).



I just made a quick attempt to build gcc-4.7.4 with current git tcc.
It made it through about 337 compiles before failing on
../.././gcc/c-family/c-opts.c:141: error: ';' expected (got "=")


Yeah, thanks for finding the cause downthread.  extern file-scope 
declarations with initializer are questionable style but indeed allowed by 
the standard, i.e. the above rejection is a bug in TCC.  Fixed in mob.



Ciao,
Michael.

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

Re: [Tinycc-devel] Annoying new warning

[Michael Matz]

Hi,

On Sun, 7 May 2017, Christian Jullien wrote:

Forget one moment what has been said so far and concentrate on my 
concern with narrowed info.


Facts:


Yes, all known and agreed upon.


* Finally, arm-gen.c uses TOK___fixxfdi with yet another #if condition =>
LDOUBLE_SIZE != 8
#if LDOUBLE_SIZE != 8
   else if(r2 == VT_LDOUBLE)
 func=TOK___fixxfdi;
   else if(r2 == VT_DOUBLE)
#else

So there is at least one combination of compiler/pre-processor options on
ARM that may use __fixunsxfdi with a test on a uninitialized value.


LDOUBLE_SIZE != 8 is not possible in any arm config, so the function won't 
be actually used at runtime.  That's why your ifdef-ing out of these 
functions in libtcc1.c is fine, and it is what we suggested all along. 
(The dead code above should also be cleaned up to not cause further 
confusion).


But _read what I write_: you have also disabled some dfdi routines at the 
same time in your patch, not only the xfdi ones.  _That_ is the problem, 
you have ifdef-ed out other unrelated routines.



Ciao,
Michael.

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

Re: [Tinycc-devel] tiny bit of lint

[Michael Matz]

Hi,

On Sun, 7 May 2017, Larry Doolittle wrote:


Using gcc's -Wextra, I found 17 "unused parameter", which could be
addressed by bloating the source code a bit (casting to void), and with
no consequence on the binary.  If anyone else thought that would be an
improvement, I'd be happy to write and submit a patch.


Some of those are public lib functions, where the parameter that's right 
now unused could conceivably be used in the future, so there it'd be 
appropriate to silence the warning.


Some of them are internal and it's probably better if the unused parameter 
simply be removed.  Some of them are functions with multiple 
implementations in different backends, where some do and others don't use 
the parameter, so there again it would have to be silenced.


If the silencing really should happen (e.g. by void casting, as you say) I 
have no big opinion on.  I'd like to look at the possible cleanup for 
internal functions first, though.


Using gcc's -Wextra, I found 23 "missing initializer for field", all 
generated by macros in x86_64-asm.h.  I would not be able to test any 
attempt to improve that situation, so I'll leave it alone.


Just fixed in mob.  This warning is borderline useless IMHO, but silencing 
it didn't require uglification, so I've done it.


Using gcc's -Wwrite-strings, I found one simple lack-of-const in 
tcctools.c, patch attached.  The patch has zero effect on the code's 
functionality.  That patch also adds "undef strict-prototypes 
write-strings" to the list of warning flags that will be used if 
present.


IMO: push to mob.


Ciao,
Michael.

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

[Tinycc-devel] ll-bitfield test on i386-linux

[Michael Matz]

Hello grischka,

parts of your last patch:

* tcctest.c: remove outdated limitation for ll-bitfield test
  It always worked, there is no reason why it should not work
  in future.

That's not true.  The comment I've put there tried to explain it:

-#ifndef __i386__
-/* on i386 we don't correctly support long long bit-fields.
-   The bitfields can straddle long long boundaries (at least with
-   GCC bitfield layout) and code generation isn't prepared for this
-   (would have to work with two words in that case).  */
-/* bit sizes below must be bigger than 32 since GCC doesn't allow
-   long-long bitfields whose size is not bigger than int */

Note the reference to GCC bitfield layout.  That (or PCC layout if you 
will) makes it so that the code generation of TCC can't cope with it (and 
never could).  That's the default on linux systems (not on windows, 
though), so accordingly the test is now broken:


--- test.ref2017-05-07 22:18:06.0 +0200
+++ test.out3   2017-05-07 22:18:06.0 +0200
@@ -378,7 +378,7 @@
 121 121
 st1.f1 == -1
 st1.f2 == -1
-4886718345 4026531841 120
+4886718345 4157519691776 536871032
...

Note, only on i386-linux (on windows and x86-64 it works).  Let me know if 
I should just reinstate the ifdef or amend it with
"&& defined(__linux__)".  It's not so superlikely that I come around 
fixing code generation for this case until release of 0.9.27 (or at all, 
my interest in i386 is not very pronounced :) ).



Ciao,
Michael.

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

Re: [Tinycc-devel] bitfield handling

[Michael Matz]

Hi,

On Sun, 30 Apr 2017, Vicente Bergas wrote:


struct{short x:12; char y:1;}s; s.y=1;


Note that the above is tricky: char can be signed and unsigned if not 
explicitely specified, and if it's signed then a 1-bit bitfield of char only 
contains values -1 and 0, so storing a 1 into it actually makes the value be 
-1. So depending on what you tested that might actually have been the problem. 
(I.e. always specify signedness of char when using it to store numeric values 
and not characters).


There is no problem with signedness. To factor out the sign, you can
also test this:
struct{unsigned short x:12; unsigned char y:2;}s; s.y=1;
which also fails. Both fail even after applying your patch.


Indeed, I thought I tested the above variant before writing the mail but 
obviously I fat-fingered something, it still failed.  Fixed in mob.  I 
chose to adjust field layout instead of field type; the latter can cause 
invalid mem accesses with packed structs/fields: consider the above struct 
being packed (hence having size 2) and placed at the last two bytes of a 
page with the page after that not being accessible.  Reading a whole int 
will then segfault.




Ciao,
Michael.

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

Re: [Tinycc-devel] bitfield handling

[Michael Matz]

Hi,

On Fri, 28 Apr 2017, Vicente Bergas wrote:


For example the following does not work:
struct{short x:12; char y:1;}s; s.y=1;


Note that the above is tricky: char can be signed and unsigned if not 
explicitely specified, and if it's signed then a 1-bit bitfield of char 
only contains values -1 and 0, so storing a 1 into it actually makes the 
value be -1.  So depending on what you tested that might actually have 
been the problem.  (I.e. always specify signedness of char when using it 
to store numeric values and not characters).



The attached patch improves bitfield handling.


Yeah, but the bitfield layout involving char fields was actually what was 
broken.  I've fixed that in mob making the above (with 'unsigned char') 
and ...



There are still corner cases which are still failing, like:
struct{int x:31; char y:2;}s; s.y=1;
in which the char overflows the 32-bit type.


... this work.  Thanks for the report.


Ciao,
Michael.

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

Re: [Tinycc-devel] This (incorrect) code crashes the compiler

[Michael Matz]

Hi,

On Thu, 4 May 2017, Tony Papadimitriou wrote:


char xxx()[] {}
 
Specifically, it’s the (wrong) use of [] that causes the crash.


Fixed in mob (the crash, not implementing full support for this extension 
of returning arrays from functions; it's regarded as returning a pointer 
to char).



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

Re: [Tinycc-devel] tiny bit of lint

[Michael Matz]

Hi,

On Mon, 8 May 2017, Christian Jullien wrote:

> tcc.h: (in function is_space)
> tcc.h:1244:12: Operands of == have incompatible types (int, char): ch == ' '
>   A character constant is used as an int. Use +charintliteral to allow
>   character constants to be used as ints.  (This is safe since the actual
> type
>   of a char constant is int.)

That's not a very useful warning.  As the explanation that splint itself 
is giving there's no danger of any misinterpretation of the meaning.

> tcc.h:1244:25: Operands of == have incompatible types (int, char): ch ==
> '\t'
> arm64-gen.c:49:31: Initializer block for reg_classes has 28 elements, but
> declared as int [25]:

And this is simply wrong.  From arm64-gen:
% grep NB_REGS arm64-gen.c
arm64-gen.c:#define NB_REGS 28 // x0-x18, x30, v0-v7
arm64-gen.c:ST_DATA const int reg_classes[NB_REGS] = {

So, quite clearly reg_classes is declared as an int[28] just fine.  
splint is probably confused by the NB_REGS definition in x86_64-gen.c 
(which defines it to 25), but that's immaterial, those sources aren't used 
in arm64-gen.c.


Ciao,
Michael.

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

Re: [Tinycc-devel] Annoying new warning

[Michael Matz]

Hi,


On Sat, 6 May 2017, Christian Jullien wrote:


Using your advice, I added #if !defined(TCC_TARGET_ARM) around all code
directly or indirectly using ldouble_long which solved warning.


But you now also ifdefed out __fixunsdfdi and __fixdfdi.  That can't work, 
they are called from the backend:



+#if !defined(TCC_TARGET_ARM)


Here you start the ifdef ...


unsigned long long __fixunsdfdi (double a1)


... so this, ...


{
register union double_long dl1;
@@ -598,24 +601,25 @@ unsigned long long __fixunsxfdi (long double a1)
return 0;
}

-long long __fixsfdi (float a1)
+long long __fixdfdi (double a1)


... this ...


-long long __fixdfdi (double a1)
+long long __fixxfdi (long double a1)


... and this are commented out.  Only the last one and __fixunsxfdi should 
be.



Ciao,
Michael.

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

Re: [Tinycc-devel] Annoying new warning

[Michael Matz]

Hi,

On Sat, 6 May 2017, Christian Jullien wrote:


I'm a bit confused now. As documented and pointed out by grischka
/* only for x86 */
union ldouble_long {
   long double ld;
   struct {
   unsigned long long lower;
   unsigned short upper;
   } l;
};

ldouble_long should only be used by x86. So far so good.
So I commented out using #if  unsigned long long __fixunsxfdi (long double
a1) and, by transitive closure
long long __fixxfdi (long double a1)
{
   long long ret; int s;
   ret = __fixunsxfdi((s = a1 >= 0) ? a1 : -a1);
   return s ? ret : -ret;
}


Yes, that you did, and that's right.  But that's not the only thing you 
did, look at your patch again.  Your second '#if !defined(TCC_TARGET_ARM)' 
also surrounds and hence on arm comments out the implementations of 
__fixunsdfdi, __fixdfdi (after rename/move), and that's wrong.  Note: df, 
not xf!



Ciao,
Michael.

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

Re: [Tinycc-devel] Add support of musl-libc to tinycc

[Michael Matz]

Hi,


On Thu, 20 Apr 2017, Marc Vertes wrote:

I just committed the patch to support musl-libc in the tcc compiler 
development branch: http://repo.or.cz/w/tinycc.git


I tested the patch on alpine-linux x86_64. Beside disabled bound 
checking, everything works so far, except the dlltest target test, 
meaning that tcc can not yet bootstrap itself using shared library.


I think that tcc is a perfect match for musl and simple small and fast 
platforms like alpine-linux.


Dear tinycc developers, let me know if this feature can be added to the 
upcoming 0.9.27 version, and also how to fix the DLL bootstrap problem.


Fixed in mob.  The problem is the stricter dynamic loader of musl, which 
ignores all STB_LOCAL symbols for symbol resolution (and hence can't 
resolve relocs against those).  Local symbols can always be resolved 
statically, but TCC didn't do that (easier to code), and it was harmless 
on e.g. glibc loader.  But it always was suboptimal, so this was a good 
opportunity to extend this in TCC.


With that the tests also run on musl.  Take note that the default diff on 
alpine linux (the busybox one) doesn't support the -I option which is used 
in the preprocessor testsuite of TCC, so for completely clean results you 
need a different diff in $PATH.



Ciao,
Michael.

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

Re: [Tinycc-devel] Annoying new warning

[Michael Matz]

Hi,

On Mon, 1 May 2017, Daniel Glöckner wrote:


On Sat, Apr 29, 2017 at 07:55:18PM +0200, Michael Matz wrote:

ARMs long double
type simply is double itself, and hence these functions are unused
on ARM.  Well, they would be if there wouldn't be strange code in
arm-gen.c that makes use of xfdi conversions when VFP is enabled.
That makes no sense, also with VFP there's only support for IEEE
double, not for extended double.


Since LDOUBLE_SIZE == 8 on VFP, those code lines will only be used with FPA.


And there they won't either because LDOUBLE_SIZE is also 8 for !VFP. 
That's what I meant with "strange" I guess, it's dead code :)



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

Re: [Tinycc-devel] Argh! No PIE on musl libC (i give up)

[Michael Matz]

Hi,

On Thu, 5 Oct 2017, Steffen Nurpmeso wrote:

> But so i tried a simple-minded approach which surprisingly simple
> ends up as

Yeah, that's not enough.  You need to adjust relocation processing to be 
more like TCC_OUTPUT_DLL mode (which then eventually results in unoptimal 
but working PIEs).  At the very least you need the hunks below in addition 
to what you had.  As is this wouldn't be ready for mob.

Instead of this it'd probably be nicer to just figure out why musls ldd 
doesn't like the executables we produce by default.


Ciao,
Michael.
diff --git a/libtcc.c b/libtcc.c
index 3adb793..5c4a76a 100644
--- a/libtcc.c
+++ b/libtcc.c
@@ -992,7 +992,7 @@ LIBTCCAPI int tcc_set_output_type(TCCState *s, int 
output_type)
 if ((output_type == TCC_OUTPUT_EXE || output_type == TCC_OUTPUT_DLL) &&
 !s->nostdlib) {
 if (output_type != TCC_OUTPUT_DLL)
-tcc_add_crt(s, "crt1.o");
+tcc_add_crt(s, "Scrt1.o");
 tcc_add_crt(s, "crti.o");
 }
 #endif
diff --git a/tccelf.c b/tccelf.c
index e2ba5a4..a539986 100644
--- a/tccelf.c
+++ b/tccelf.c
@@ -1015,8 +1015,10 @@ ST_FUNC void build_got_entries(TCCState *s1)
 attr = put_got_entry(s1, reloc_type, type, sym->st_size, 
sym->st_info,
  sym_index);
 
-if (reloc_type == R_JMP_SLOT)
+if (reloc_type == R_JMP_SLOT) {
 rel->r_info = ELFW(R_INFO)(attr->plt_sym, type);
+   get_sym_attr(s1, attr->plt_sym, 1)->dyn_index = 0;
+   }
 }
 }
 }
@@ -1402,7 +1404,7 @@ static void alloc_sec_names(TCCState *s1, int file_type, 
Section *strsec)
 s->sh_name = put_elf_str(strsec, s->name);
 /* when generating a DLL, we include relocations but we may
patch them */
-if (file_type == TCC_OUTPUT_DLL &&
+if ((file_type == TCC_OUTPUT_DLL || file_type == TCC_OUTPUT_EXE) &&
 s->sh_type == SHT_RELX &&
 !(s->sh_flags & SHF_ALLOC)) {
 /* gr: avoid bogus relocs for empty (debug) sections */
@@ -1976,8 +1980,9 @@ static int elf_output_file(TCCState *s1, const char 
*filename)
 if (file_type == TCC_OUTPUT_DLL) {
 if (s1->soname)
 put_dt(dynamic, DT_SONAME, put_elf_str(dynstr, 
s1->soname));
-put_dt(dynamic, DT_TEXTREL, 0);
+//put_dt(dynamic, DT_TEXTREL, 0);
 }
+put_dt(dynamic, DT_TEXTREL, 0); //xxx
 
 if (s1->symbolic)
 put_dt(dynamic, DT_SYMBOLIC, 0);
diff --git a/x86_64-link.c b/x86_64-link.c
index 27cad93..ee8bc58 100644
--- a/x86_64-link.c
+++ b/x86_64-link.c
@@ -165,7 +165,7 @@ void relocate(TCCState *s1, ElfW_Rel *rel, int type, char 
*ptr, addr_t addr, add
 
 switch (type) {
 case R_X86_64_64:
-if (s1->output_type == TCC_OUTPUT_DLL) {
+if (s1->output_type == TCC_OUTPUT_DLL || s1->output_type == 
TCC_OUTPUT_EXE) {
 esym_index = s1->sym_attrs[sym_index].dyn_index;
 qrel->r_offset = rel->r_offset;
 if (esym_index) {
@@ -183,7 +183,7 @@ void relocate(TCCState *s1, ElfW_Rel *rel, int type, char 
*ptr, addr_t addr, add
 break;
 case R_X86_64_32:
 case R_X86_64_32S:
-if (s1->output_type == TCC_OUTPUT_DLL) {
+if (s1->output_type == TCC_OUTPUT_DLL || s1->output_type == 
TCC_OUTPUT_EXE) {
 /* XXX: this logic may depend on TCC's codegen
now TCC uses R_X86_64_32 even for a 64bit pointer */
 qrel->r_info = ELFW(R_INFO)(0, R_X86_64_RELATIVE);
@@ -195,7 +195,7 @@ void relocate(TCCState *s1, ElfW_Rel *rel, int type, char 
*ptr, addr_t addr, add
 break;
 
 case R_X86_64_PC32:
-if (s1->output_type == TCC_OUTPUT_DLL) {
+if (s1->output_type == TCC_OUTPUT_DLL || s1->output_type == 
TCC_OUTPUT_EXE) {
 /* DLL relocation */
 esym_index = s1->sym_attrs[sym_index].dyn_index;
 if (esym_index) {

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

Re: [Tinycc-devel] Unify C and asm symbols (was: forward asm symbols vs static)

[Michael Matz]

Hi,

On Mon, 27 Nov 2017, Christian Jullien wrote:

> Hi Michael,
> 
> Using native Windows 32/64 builds from mob, I see no errors on tests suite.
> My RPi 3 box installed with Debian 32bit is also very happy.
> 
> Good job

Cool, thanks for checking, I appreciate that.


Ciao,
Michael.

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

Re: [Tinycc-devel] forward asm symbols vs static

[Michael Matz]

Hi,

On Sat, 25 Nov 2017, grischka wrote:


.def is created automatically if an "export table" with
at least one symbol (with __attribute__((dllexport))) is created for
the dll or exe.

This is done so for convenience and corresponds to msvc behavior which 
creates .exp and .lib files automatically in that case because if the 
module (exe/dll) exports symbols then most likely in order to be linked 
with other modules at some point.


The observed effect - thanks to avih for the heads up - obviously
comes from the abuse of sym.a.dllexport in tccasm.c.  Whether there
could be a similar effect from using sym.a.dllimport - less likely
I'd think but maybe still possible.


Ah yes, that make sense.  Thanks also to avih for the reproducer receipt 
on linux, I can investigate now.



However,... I see that end of the year we have other things to do.

Therefor, as it stands now, I'm tempted to suggest to you, Michael, to 
wait with release for that other idea that you did mention (with single 
symtab for both asm and C, etc.) to grow into shape.


I'm fine either way, I've started on the unification of the symtabs 
already, but will fix the .def file thingy separate from that.



After all, no need to hurry, what do you think?


My secret hope was for a christmas present (aka release) ;-)  That still 
doesn't imply any hurry yet, but would be really nice.


Hmm, let's see ... I'm fairly sure to have the .def file problem fixed 
later today.  The symtab unification I don't know yet, perhaps end of the 
weekend or next week.  Basically I don't want the unification to delay a 
release until next year, if it would have otherwise happened this year. 
I don't know your end of year planning of course, if this weekend was your 
only time slot to do a release this year I would feel bad about being the 
reason for a delay until next year.  If we only talk about a delay of one 
to three weeks I'll be happy about waiting for the unification.


Anyway, waiting on the .def bug now :)


Ciao,
Michael.

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

Re: [Tinycc-devel] forward asm symbols vs static

[Michael Matz]

Hi,

On Sat, 25 Nov 2017, avih wrote:


You can reproduce it with Linux too. This is with Ubuntu 16.04 but I'm
pretty sure it's not mandatory: Let's start from scratch after cloning and
cd into the tinycc dir:


Thanks for the receipt, I could reproduce it and have fixed it in mob.

(At the expense of using two new flag bits, but we had 5 available anyway, 
and it's only until the symtab unification is done, so it's only a 
temporary stop-gap solution).



Ciao,
Michael.

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

[Tinycc-devel] Unify C and asm symbols (was: forward asm symbols vs static)

[Michael Matz]

Hi,

On Sat, 25 Nov 2017, Michael Matz wrote:

Hmm, let's see ... I'm fairly sure to have the .def file problem fixed later 
today.  The symtab unification I don't know yet, perhaps end of the weekend 
or next week.


Both in mob now.  I've tested 32bit and 64bit linux; some proper Windows 
testing would be nice.  (I've also checked in your improved variant of the 
asm-c-connect test)



Ciao,
Michael.

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

Re: [Tinycc-devel] forward asm symbols vs static

[Michael Matz]

Hi,

On Thu, 23 Nov 2017, grischka wrote:

Different calling convention on win64.  I'd suggest the attached version 
which is more platform neutral.


Yup, that's better.


Ciao,
Michael.

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

Re: [Tinycc-devel] forward asm symbols vs static

[Michael Matz]

Hi,

On Fri, 24 Nov 2017, avih wrote:


I noticed a change at e7c71e24 ("tccasm: synch C and asm symtab tighter")
which I'm not sure is expected.

On Windows, when I build tcc using tcc with one source, a file "tcc.def" is
created at the same dir as the resulting tcc.exe, with this content:

LIBRARY tcc.exe

EXPORTS
___try__
__chkstk
__try__
_exception_code
_exception_info

To reproduce: prepare a working version of tcc for windows (this example is
with tcc 32), clone tcc, cd to its root dir, and execute:

echo '#define TCC_VERSION "0.9.27"' > config.h && path/to/tcc.exe
-DTCC_TARGET_PE -DTCC_TARGET_I386 -Iwin32 -I. -DONE_SOURCE -o tcc.exe tcc.c

And the result is that tcc.def is created alongside tcc.exe .
This started happening at e7c71e24 . The earlier commit ("Adjust testcase
for PIE compilers") doesn't create tcc.def with the same invocation.

Is it expected? a bug?


It'd be very surprising for my patch to have this effect.  It affects 
symbol table entries, and AFAICS that doesn't influence if the .def file 
is generated or not.  Ultimately it's created from pe_build_exports(), 
which itself is called when processing the first writable data section.  I 
don't see how commit e7c71e24 could make a difference.


Are you sure the .def file isn't generated by a TCC from a commit before?

Otherwise I'm at a loss, and not having a Windows system I can't help 
much.  grischka, any ideas?



Ciao,
Michael.

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

Re: [Tinycc-devel] forward asm symbols vs static

[Michael Matz]

Hi,

On Thu, 23 Nov 2017, avih wrote:

> > I hope it also works on win32 and win64, which I haven't tested
> asm-c-connect-test pass if the initial compiler is tcc 32 or 64 (and building 
> tcc 32/64 respectively).
> It segfaults if the initial compiler is gcc 64 (mingw gcc 7.2.0, in msys2 
> setup).
> I didn't test with gcc 32 mingw.

The test is always compiled by tcc.  So if you say "initial compiler", do 
you mean the compiler by which tcc itself is compiled?  I.e. there is a 
difference if tcc is compiled by gcc (tcc produces segfaulting code then), 
vs. with tcc (the resulting tcc produces good code)?

Hmpf.

Can you compile the two files separately into .o files and attach them 
here?  (With the failing compiler I mean).  Perhaps it's something 
obvious, but I can't test win32/64.


Ciao,
Michael.

> When it passes, this is what it prints: asm-c-connect-test 
> 
> ./asm-c-connect
> x1
> x2
> x3
> And when it fails:../tcc.exe -B../../win32 -I../../include -I../.. -I.. -L.. 
> -o asm-c-connect.exe ../../tests/asm-c-connect-1.c 
> ../../tests/asm-c-connect-2.c
>  asm-c-connect-test 
> ./asm-c-connect.exe
> make[1]: *** [Makefile:240: asm-c-connect-test] Segmentation fault
> make[1]: Leaving directory '/bld/tests'
> make: *** [Makefile:346: test] Error 2
>  
> 
> On Wednesday, November 22, 2017 7:11 PM, Michael Matz 
> <matz@frakked.de> wrote:
>  
> 
>  Hi,
> 
> On Mon, 20 Nov 2017, Michael Matz wrote:
> 
> > > naively I'd think that it probably should more closely emulate the gcc 
> > > situation where inline asm ends up just as embedded snippets in its C -> 
> > > asm output.  Which could mean for example that "free_asm_labels" should 
> > > be called only once at the end of each "translation unit" (file).
> > 
> > Yes, that would be the ultimate goal.  As said, this would elevate the 
> > problem of sharing C-label and asm-label namespace, which already is a 
> > problem right now, even more.  So that needs solving, preferably without 
> > needing too much additional memory, then the move to a single end-of-file 
> > free_asm_labels, and then all is sunny :)
> > 
> > > Below is some test that I just have tried.
> > 
> > Yep, a conscise example of all asm- symbol table problems we have right 
> > now :)
> 
> I've fixed the problems I know about, including this two-file testcase 
> (I've added it to the testsuite, I hope it also works on win32 and win64, 
> which I haven't tested).
> 
> After release I'm probably going to change how the asm symtable is 
> implemented, which then does away with the new slot in TokenSym.  My idea 
> is to have just a single sym table for global decls, the C one, which can 
> be used for the asm one as well, with some slight adjustments.
> 
> But as is, it at least fixes the testcase, the linux-2.4.x 32bit kernel, 
> and 64bit linux 4.6, so I'm happy enough for now :)
> 
> 
> 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

Re: [Tinycc-devel] forward asm symbols vs static

[Michael Matz]

Hi,

On Mon, 20 Nov 2017, Michael Matz wrote:

> > naively I'd think that it probably should more closely emulate the gcc 
> > situation where inline asm ends up just as embedded snippets in its C -> 
> > asm output.  Which could mean for example that "free_asm_labels" should 
> > be called only once at the end of each "translation unit" (file).
> 
> Yes, that would be the ultimate goal.  As said, this would elevate the 
> problem of sharing C-label and asm-label namespace, which already is a 
> problem right now, even more.  So that needs solving, preferably without 
> needing too much additional memory, then the move to a single end-of-file 
> free_asm_labels, and then all is sunny :)
> 
> > Below is some test that I just have tried.
> 
> Yep, a conscise example of all asm- symbol table problems we have right 
> now :)

I've fixed the problems I know about, including this two-file testcase 
(I've added it to the testsuite, I hope it also works on win32 and win64, 
which I haven't tested).

After release I'm probably going to change how the asm symtable is 
implemented, which then does away with the new slot in TokenSym.  My idea 
is to have just a single sym table for global decls, the C one, which can 
be used for the asm one as well, with some slight adjustments.

But as is, it at least fixes the testcase, the linux-2.4.x 32bit kernel, 
and 64bit linux 4.6, so I'm happy enough for now :)


Ciao,
Michael.

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

Re: [Tinycc-devel] Unify C and asm symbols

[Michael Matz]

Hi,

On Mon, 4 Dec 2017, grischka wrote:

> Michael Matz wrote:
> >> Here 'x5' should have the g[lobal] binding from C.
> > 
> > ... I have fixed this in mob with a one-liner instead :)
> 
> Well, however this one line
> > +   if (esym && s->type.t == VT_VOID) {
> 
> gives an interesting hint too because if after all we "post-process"
> only asm symbols then this means (IMO) that logically equivalently
> the same changes can be made to the symbol in place as well.
> 
> Anyway, while at it (and making more tests), I tried that and it
> seems to work quite well.
> 
> I've attached it as "no-asm-stack.patch".

Oh, shiny! :)  I like it.  It also works on my linux kernel sources, and 
some other things, so it's a definite improvement.  I'd say, apply.

> It clearly still has unwanted behavior with compiling multiple files
> if symbols with same name are defined as global in one file and
> then as static in another file.

Yeah, that, but not worse than before.

> The other "patch-type.patch" somewhat unifies type redefinition

And that's nice as well, I always wanted to do something similar, and 
never came to it.  Less lines --> good! :)

> Anyway. you might use these patches as just ideas or to run some tests
> to see if we can include them as is for the release.

As is.

> Apropos release, I don't have problems if the released version has
> "limitations" say with some corner cases, as long as unlikely an
> even simpler approach exist with equal or even less limitations.

Yeah, releases will always have problems, and there always will be new 
releases (err, hopefully :) ), so I also don't see problems with 
limitations.  I'm basically fine with a release whenever there aren't 
known regressions (i.e. something worked fine say two months ago, but 
doesn't anymore).  That's the case right now, no regressions.  And with 
your patches (also no regressions) tcc code is even smaller :)

> IOW if we're possibly somewhere close to such possibly simpler and
> better approach then I think it's worth to still wait, 1, 2, 3 ...
> weeks doesn't matter ;)

But, but ... Christmas!  :)


Ciao,
Michael.

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

Re: [Tinycc-devel] Unify C and asm symbols

[Michael Matz]

Hi,

On Mon, 4 Dec 2017, Michael Matz wrote:

> Oh, shiny! :)  I like it.  It also works on my linux kernel sources, and 
> some other things, so it's a definite improvement.  I'd say, apply.

Bleh, I wanted to ask one thing about the no_asmstack patch, the hunk:

@@ -390,7 +388,7 @@ ST_FUNC int find_elf_sym(Section *s, const char *name)
 while (sym_index != 0) {
 sym = &((ElfW(Sym) *)s->data)[sym_index];
 name1 = (char *) s->link->data + sym->st_name;
-if (!strcmp(name, name1))
+if (!strcmp(name, name1) && ELFW(ST_BIND)(sym->st_info) != STB_LOCAL)
 return sym_index;
 sym_index = ((int *)hs->data)[2 + nbuckets + sym_index];
 }

My tests go through also without this hunk, so it's either an optimization 
(but then it should be tested before the strcmp) or it's a left-over from 
during development of your patch, or it's for a situation I don't know yet 
(perhaps one of the multi-file ones?)

Conceptually it makes sense of course: STB_LOCAL symbols should be bound 
via the Sym structure (i.e. within a file), not be used for providing 
resolution for symbols from other files, but still I'm curious why you 
needed it.


Ciao,
Michael.

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

Re: [Tinycc-devel] Unify C and asm symbols

[Michael Matz]

Hi,

On Tue, 12 Dec 2017, grischka wrote:


OK, I just pushed the (if it were me) final commit for 0.9.27, so
we could say that it is now in BETA stage, at least.
http://repo.or.cz/tinycc.git/commitdiff/d348a9a51d32cece842b7885d27a411436d7887b

Also there is one more alternative approach for multi source-file
linking which (I think) behaves now really VERY similar to what
tcc does with object files. (No elf hashing during compilation at all.)
http://repo.or.cz/tinycc.git/commitdiff/1a4d4b76e803a32db1168e66ad8f8b26c29c8ea0

Anyway, I'd say, please test (and if anything, please fix ;), and if all 
goes well I could pack the tarballs then say ... next Sunday.


Works with my usual tests, so I'm good, nothing to fix ;)


Ciao,
Michael.

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

Re: [Tinycc-devel] debug info broken

[Michael Matz]

Hi,

On Sun, 17 Dec 2017, foobar wrote:

> Hi list,
> 
> First of all, thanks for the release!
> I've built 0.9.27 for x86_64 and tried a see if debugging works, but:
> 
> $ cat true.c 
> int main() { return 0; }
> 
> $ tcc true.c -g -o true

Above works for me (with 0.9.27 release and others).  The .stabs debug 
info of the executable says:

% objdump -g true
true.c:
 main ()
{ /* 0x4002c0 */
  /* file /matz/git/tinycc/true.c line 1 addr 0x4002c0 */
  /* file /matz/git/tinycc/true.c line 1 addr 0x4002cb */
} /* 0x4002d2 */

> $ gdb ./true
> GNU gdb (GDB) 7.6.2
> Copyright (C) 2013 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later 
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "x86_64-unknown-linux-gnu".
> For bug reporting instructions, please see:
> ...
> Reading symbols from ./true...DW_FORM_strp pointing outside of .debug_str 
> section [in module /home/rofl/hardcore-utils/true]

Maybe this is the problem in that gdb doesn't want to read debug info 
further after seeing this error?  Doesn't happen for me and must come from 
one of the system .o files (or static C library parts) as tcc doesn't use 
.debug_str (no dwarf in tcc).

> (gdb) b main
> Breakpoint 1 at 0x0 (2 locations)

And for me, as expected:

(gdb) b main
Breakpoint 1 at 0x4002cb: file true.c, line 1.

> IMO the perfect niche for using TCC is for development, since you can 
> rebuild entire projects in the fraction of time it takes with GCC, but 
> if debugging the result is impossible, that's quite a bummer.

TCCs debug information only contains line numbers and symbols for 
functions.  There's no info about local variables (for instance), so the 
debug experience won't be very great in any case.  But the above at least 
should work.


Ciao,
Michael.

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

[Tinycc-devel] forward asm symbols vs static

[Michael Matz]

Hello grischka,

I had to revert a small part of your da8c62 commit ("various stuff"):

tccasm.c:
- keep forward asm labels static, otherwise they will endup
  in dynsym eventually.

A symbol which stays undefined until the end is implicitely STB_GLOBAL, 
even without a .globl directive.  I've added a testcase to that effect.  
Before just reverting the hunk I've tried to move it somewhere else in 
order not to lose the effect mentioned above.

But in the end I wasn't really successful in constructing a testcase where 
such symbol ends up in dynsym when it shouldn't.  E.g. local labels (the 
numeric ones) are always already constructed as VT_STATIC.  And normal 
labels are also created VT_STATIC, except if they already were associated 
with a .globl directive.  So I don't really see how the problem above 
could have happened.

To recollect, give the following assembler snippet:

jmp 1f
local:
call local
call undefined
call global
.globl global
global:
1: nop

the symbols L..1 and local need to be STB_LOCAL, while undefined and 
global need to be STB_GLOBAL.

So, if you have a testcase or remember the situation that you tried to 
fix, can you tell me which one it was? :)


Ciao,
Michael.

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

Re: [Tinycc-devel] forward asm symbols vs static

[Michael Matz]

Hi,

On Thu, 16 Nov 2017, grischka wrote:

> Except ... there was one text relocation which at first I could not
> explain where it comes from but then with some objdumps I found it
> was a relocation to the 'p3' label in libtcc1.a:alloca86_64.s which
> defeated my efforts to get rid of DT_TEXTREL (at least for a self-
> compiled tcc at least on x86_64, that is).  See here
> 
> /* alloca86_64.S */
> .globl alloca
> 
> alloca:
> pop %rdx
> ...
> jz  p3
> ...
> p3:
> push%rdx
> ret
> 
> Now I would think that 'p3' neither is global nor is undefined and
> therefor should not be placed in dynsym and even less with a non-pc-
> relative relocation.  The only thing that is particular about p3
> (say in contrast to p1 and p2) is that it is a forward label.

Aha!  Indeed, p3 should be STB_LOCAL, and now (after my revert or before 
your patch) isn't anymore.  Okay, I'll work on this.  Need to find a way 
to get both things working, hmm :)

> Btw. my current 0.9.27 release plan is to do it as soon as I have
> time, using basically the current state of code (with one last commit).
> Is there something that you're currently working that would be a reason
> wait some more time?

Nope.  In fact I have a couple things in various branches where I was 
waiting for the release to happen, as I wanted to not disrupt stuff 
before.  But I think the above p3 problem should be fixed first.  Perhaps 
later today or tomorrow.


Ciao,
Michael.

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

Re: [Tinycc-devel] forward asm symbols vs static

[Michael Matz]

Hi,

On Sun, 19 Nov 2017, grischka wrote:

> I admit that tccasm.c is one of the white areas on my tcc map, but 
> naively I'd think that it probably should more closely emulate the gcc 
> situation where inline asm ends up just as embedded snippets in its C -> 
> asm output.  Which could mean for example that "free_asm_labels" should 
> be called only once at the end of each "translation unit" (file).

Yes, that would be the ultimate goal.  As said, this would elevate the 
problem of sharing C-label and asm-label namespace, which already is a 
problem right now, even more.  So that needs solving, preferably without 
needing too much additional memory, then the move to a single end-of-file 
free_asm_labels, and then all is sunny :)

> Below is some test that I just have tried.

Yep, a conscise example of all asm- symbol table problems we have right 
now :)

Ciao,
Michael.

> 
> --- grischka
> 
> $ gcc -c t1.c t2.c && gcc t1.o t2.o -o t.exe && t.exe
> x1
> x2
> x3
> 
> $ tcc -c t1.c t2.c && tcc t1.o t2.o -o t.exe && t.exe
> tcc: error: undefined symbol 'x1'
> tcc: error: undefined symbol 'x2'
> 
> $ tcc t1.c t2.c -o t.exe && t.exe
> tcc: error: undefined symbol 'x1'
> tcc: error: undefined symbol 'x2'
> 
> /***/
> /* T1.C */
> 
> #include 
> 
> #if defined _WIN32 && !defined __TINYC__
> # define U "_"
> #else
> # define U
> #endif
> 
> const char str[] = "x1\n";
> asm(U"x1: push $"U"str; call "U"printf; pop %ecx; ret");
> 
> int main(int argc, char *argv[])
> {
> asm("call "U"x1");
> asm("call "U"x2");
> asm("call "U"x3");
> return 0;
> }
> 
> static
> int x2(void)
> {
> printf("x2\n");
> return 2;
> }
> 
> extern int x3(void);
> 
> 
> /***/
> /* T2.C */
> 
> #include 
> 
> int x3(void)
> {
> printf("x3\n");
> return 3;
> }
> 
> > 
> > 
> > Ciao,
> > Michael.
> > 
> 
> 

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

Re: [Tinycc-devel] forward asm symbols vs static

[Michael Matz]

Hi,

On Sun, 19 Nov 2017, Michael Matz wrote:


Aha!  Indeed, p3 should be STB_LOCAL, and now (after my revert or before
your patch) isn't anymore.  Okay, I'll work on this.  Need to find a way
to get both things working, hmm :)


Fixed in mob.


Gnah, what a rats hole :-/ I found another failure mode that occurs only 
when defaulting asm labels to VT_STATIC/STB_LOCAL.  I don't yet want to 
revert as it fixes demonstratable bugs, but OTOH I lack time tonight to 
fix this third problem as well.  If you want to release soon, I'd suggest 
to revert d0db2175 back to a8ece0f2 (i.e. to a state where the 
alloca86_64.S/p3 reoccurs, like it always had in the past).  If you can 
wait some more days with the release I'm going to fix it properly 
(hopefully).


(FWIW the problem occurs when building multiple files into one executable 
(it works when compiling the files individually and then linking the .o 
files together) where the files each contain multiple asm snippets 
containing forward references that eventually turn out to be global. 
local symbols aren't entered into the ELF hash tables and when they are 
globalized later are missing from them, ultimately leading to linker 
errors.  At least I think that's the reason :) This is all made a bit 
messy by the fact that the asm symtable lives only during one asm snippet, 
which is itself messy to fix because it shares the namespace with the C 
labels.)



Ciao,
Michael.

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

Re: [Tinycc-devel] version d0db21757afc625a6299aec51cbc282f36abb85f

[Michael Matz]

Hi,

On Sun, 19 Nov 2017, Somchai Smythe wrote:


gcc -o tcctest.gcc tcctest.c -DCONFIG_TRIPLET="\"x86_64-linux-gnu\""
-DTCC_TARGET_X86_64 -fno-strict-aliasing -I.. -I..  -w -O0 -std=gnu99
-fno-omit-frame-pointer
./tcctest.gcc > test.ref
./tcctest.gcc: Symbol `getenv' causes overflow in R_X86_64_PC32 relocation
Segmentation fault (core dumped)


It seems Ubuntu GCC defaults to generate PIE or PIC code by default, 
that's incompatible with my new testcase.  Or was, please try current mob 
(330c01).


If it still doesn't work please give the output of the above gcc 
command, but with -v added to the command line.  I might then also ask for 
the intermediate files generated by above command when -save-temps is 
added, but try updated mob first.



Ciao,
Michael.

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

Re: [Tinycc-devel] forward asm symbols vs static

[Michael Matz]

Hi,

On Fri, 17 Nov 2017, Michael Matz wrote:


Aha!  Indeed, p3 should be STB_LOCAL, and now (after my revert or before
your patch) isn't anymore.  Okay, I'll work on this.  Need to find a way
to get both things working, hmm :)


Fixed in mob.

Btw. my current 0.9.27 release plan is to do it as soon as I have time, 
using basically the current state of code (with one last commit). Is 
there something that you're currently working that would be a reason 
wait some more time?


Nope.  In fact I have a couple things in various branches where I was 
waiting for the release to happen, as I wanted to not disrupt stuff 
before.  But I think the above p3 problem should be fixed first.


So, ship it!  ;-)


Ciao,
Michael.

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

Re: [Tinycc-devel] Unify C and asm symbols

[Michael Matz]

On Tue, 28 Nov 2017, grischka wrote:

I like it.  More lines removed than added could mean that it is going in 
the right direction anyway ;)


Hehe :)


Question:  I wonder whether now we could maybe get rid of the asm label
"post-processing" (asm_free_labels) and the asm_label stack altogether?


That requires surgery in how linking is done (in a sense moving that 
post-processing from asm symbols from compilation to linking time).  I 
believe this ultimately will be good anyway, as there are currently 
various strangenesses and corner cases that are buggy especially involving 
multi-file compilation (i.e. without intermediate .o files), or multi-file 
-run.  I think I'll work on that somewhen the next days, but it'll be a 
bit hairy and potentially disruptive, so the release doesn't have to wait. 
In the meantime ...



Seen that it can be counter-productive too, as with for example:

...

$ tcc -c t1.c t2.c && tcc t1.o t2.o -o t.exe && t.exe
tcc: error: undefined symbol 'x5'

$ tcc -c t1.c && objdump -x t1.o
   SYMBOL TABLE:
    ldf *ABS*    t1.c
   004a l   .text   001f x5

Here 'x5' should have the g[lobal] binding from C.


... I have fixed this in mob with a one-liner instead :)


Ciao,
Michael.

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

Re: [Tinycc-devel] inline assembly problem with cmovcl/cmovbl

[Michael Matz]

Hi,

On Sat, 2 Dec 2017, Somchai Smythe wrote:


I realize there are other ways to get this cpuid information, but if I
wanted to use cmovcl in some other code I think the inline assembler
really is broken.  I tried the synonym cmovbl, but it didn't work
either.  Both cmovc and cmovb are listed in intel's manual as
generating 0x04 0x42 /r, so I think they are just two mnemonics for
the same instruction.  If I delete the 'l' suffix, and use bare
'cmovc' (or bare 'cmovb'), it will compile.


And that's really the right solution: Unlike e.g. mov and push cmovCC 
always has register operands from which the size can be inferred, so it's 
always okay to remove the suffix.


But I've now added some code to mob which accepts (and ignores) size 
suffixes for cmovCC in a way that doesn't blow up our assembler tables 
even more, so your example should work now.



Ciao,
Michael.

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

Re: [Tinycc-devel] Unify C and asm symbols

[Michael Matz]

Hi,

On Sun, 10 Dec 2017, grischka wrote:


May I suggest however to keep doing the asm-label undef->non-static
conversion on the sym-stack (per file) level, because for one it is
more obvious at what we're doing and why, and also because otherwise
is is not correct for static C symbols, which must be defined in the
same file or are errors otherwise.


I thought about this, but actually I was quite happy to see that 
asm-tccgen connection go.  Then I remembered that GCC works the same 
(even in pedantic c99 mode):


% cat undef-local.c
static int printf(const char *, ...);
main() { printf("hello\n"); }
% gcc -c undef-local.c
undef-local.c:1:13: warning: ‘printf’ used but never defined
 static int printf(const char *, ...);
% readelf -sW undef-local.o | grep local
 9:  0 NOTYPE  GLOBAL DEFAULT  UND printf

(sure, there's a warning, but it's not an error).  That's no big wonder as 
GCC uses intermediate assembler files and there undefed locals become 
global.  I think doing the same in TCC is reasonable.  Maybe even 
required, as otherwise the above (questionable) program works with GCC 
(with a warning) but not TCC.



You could push first the combined final result of the asm related
patches, (possibly including the suggestion from above), as one
single commit (under your authorship).


Credit where credit is due :) Pushed as three separate commits (without 
the suggestion above), your two with the commit message and authorship 
extracted from your commits in the mail.



I'd then push the "type redefinition check" patch, including a minor
fix (as attached) that is meant to make sure that
- a transition global->static can never happen
- a transition static->global can happen, but only for symbols
 that (initially) come from asm.


Yeah, that'd be nice.  As long as for the C symbols the last transition is 
still allowed (and static wins, so in ELF symbol terms it's not really a 
transition).  Your patch seems to do the right thing here.


I'd then make one more commit with other small fixes, and then I'd pack 
the release, say next Sun (17.12.)


How does that sound?


Quite wonderful methinks, would be awesome :)


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

Re: [Tinycc-devel] Unify C and asm symbols

[Michael Matz]

Hi,

On Wed, 6 Dec 2017, grischka wrote:

My tests go through also without this hunk, so it's either an optimization 
(but then it should be tested before the strcmp) or it's a left-over from 
during development of your patch, or it's for a situation I don't know yet 
(perhaps one of the multi-file ones?)


f1.c:
 asm("call x1; ret; x1: ...");
f2.c:
 void x1() {}

MAY cause
 "error: 'x1' defined twice"


Yeah, that's whay I meant with multi-file mode problems ...


3) instead of (2), call rebuild_hash() at the end of each file.

Where all of 1..3 still have this problem:
f1.c:
   x1() { printf("x1(1)\n"); }
   main() { x1(); main_2(); }
f2.c:
   main_2() { asm("call x1"); }
   static x1() { printf("x1(2)\n"); }


... and this.


4) create asm symbols as "static" first always. This however needs to
   post-process asm symbol again (to convert any still undefined symbols
   to globals),  as well as to patch relocation entries if such global
   already was defined in a previous file.


And yes, using static asm symbols from the beginning is the only 
good solution (I see) to the above multi-file problems, with the 
associated fallout problems from that, as you noticed: newly globalized 
symbols need to be in the ELF hash table, the "old" local symbols might 
already be used in emitted relocs and undefined-at-end must be global.



See attached (additional) patch.  It definitely would add some lines
but then again I wasn't able to produce any problems w.r.t. multi-files
with that.

Comments ? ;)


I wasn't a big fan of the reloc rewriting, and when thinking about the 
above multi-file problems I had a more linker centric approach in mind.


So what I came up with is below: doing a proper regular-symbol resolution 
step: basically similar to what's done while reading in .o files. 
Advantages: no rewriting of reloc entries (which is expensive in your 
patch as you iterate all relocs for each into-global change), only needing 
to rebuild the hash table once or twice per output file (or -run), the 
undef globalization can be folded into it and it's overall a bit shorter 
(30 lines added) :)


This is on top of your last two patches (i.e. without the static-asm-sym 
patch).  If you don't beat me to it I think I'll push your two and this 
one somewhen tomorrow; together they (and even just your two) are a clear 
progression (and all three together even source line number neutral! ;) )


What do you think?


Ciao,
Michael.

commit c47d42823da2bb2908ce6a60452a24ba58b1b273
Author: Michael Matz <m...@suse.de>
Date:   Sun Dec 10 06:18:27 2017 +0100

Fix some multi-file corner cases with asm

for this we have to create also asm symbols as VT_STATIC initially
except if there's an indication that it should be global (.globl
or undefined at end of unit).  For this to work we need to
be able to globalize symbols after they were local and enter them
into the ELF hash tables, and also adjust the symbols that were
potentially already used in relocs when they were still local.

The easiest is to do a proper symbol resolution step also in multi-file
mode, for regular symbols (the non-dynamic ones, i.e. not from shared
libs).
---
 tcc.h|  4 +--
 tccasm.c | 21 +---
 tccelf.c | 87 
 tccpe.c  |  3 +--
 tccrun.c |  3 +--
 5 files changed, 74 insertions(+), 44 deletions(-)

diff --git a/tcc.h b/tcc.h
index 38bbda8..926ac5d 100644
--- a/tcc.h
+++ b/tcc.h
@@ -911,7 +911,6 @@ struct filespec {

 /* symbol was created by tccasm.c first */
 #define VT_ASM (VT_VOID | VT_UNSIGNED)
-#define VT_ASM_GLOBAL VT_DEFSIGN
 #define IS_ASM_SYM(sym) (((sym)->type.t & (VT_BTYPE | VT_ASM)) == VT_ASM)

 /* token values */
@@ -1426,11 +1425,10 @@ ST_FUNC void put_stabs_r(const char *str, int type, int 
other, int desc, unsigne
 ST_FUNC void put_stabn(int type, int other, int desc, int value);
 ST_FUNC void put_stabd(int type, int other, int desc);

-ST_FUNC void relocate_common_syms(void);
+ST_FUNC void resolve_regular_syms(void);
 ST_FUNC void relocate_syms(TCCState *s1, Section *symtab, int do_resolve);
 ST_FUNC void relocate_section(TCCState *s1, Section *s);

-ST_FUNC void tcc_add_linker_symbols(TCCState *s1);
 ST_FUNC int tcc_object_type(int fd, ElfW(Ehdr) *h);
 ST_FUNC int tcc_load_object_file(TCCState *s1, int fd, unsigned long 
file_offset);
 ST_FUNC int tcc_load_archive(TCCState *s1, int fd);
diff --git a/tccasm.c b/tccasm.c
index 4fe3f32..355d158 100644
--- a/tccasm.c
+++ b/tccasm.c
@@ -42,13 +42,12 @@ static Sym *asm_label_find(int v)
 return sym;
 }

-static Sym *asm_label_push(int v, int t)
+static Sym *asm_label_push(int v)
 {
-Sym *sym = global_identifier_push(v, t, 0);
 /* We always add VT_EXTERN, for sym definition that's tentative
(for .set, removed for real defs), for mere references it

Re: [Tinycc-devel] Inconsistency gcc/tcc on visibility hidden

[Michael Matz]

Hi,


On Sun, 6 May 2018, ag wrote:


 tcc -o liba-tcc.so alib.c -g -O2 -shared -fPIC -fvisibility="hidden"


TCC doesn't support the -fvisibility= option at all.  By default it 
silently accepts all -f options, if you want a warning then do:


% tcc ... -Wunsupported ... -fvisibility=hidden
tcc: warning: unsupported option '-fvisibility=hidden'


Ciao,
Michael.

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

Re: [Tinycc-devel] Found an issue when compiling raylib with TCC

[Michael Matz]

Hello,

On Mon, 28 May 2018, Ray wrote:


Just found an issue when compiling with TCC, it seems that TCC is not
casting some int values correctly to float when dividing, I mean:


Which version of TCC?  (mob branch or anything else?)


Following code fails on calculating correct float coordinates:

// sourceRec.x, sourceRec.y are floats
// texture.width, texture.height are int
rlTexCoord2f(sourceRec.x/texture.width, sourceRec.y/texture.height);

Same code works perfectly with MinGW, GCC, MSVC, Clang...

Also tried: 

rlTexCoord2f(sourceRec.x/(float)texture.width,
sourceRec.y/(float)texture.height);

Instead I had to do:

float width = (float)texture.width;
float height = (float)texture.height;

rlTexCoord2f(sourceRec.x/width, sourceRec.y/height);

More info about this issue: https://github.com/raysan5/raylib/issues/553


I can't find a test which reproduces a problem with current mob branch. 
I tried:


% cat x.c
#include 

void get2f (float a, float b)
{
  printf("%f %f\n", a, b);
}

struct F2 {
float x,y;
};
struct I2 {
int width, height;
};

int main()
{
  struct F2 a = {5.5f, 42.3f};
  struct I2 b = {1024, 768};
  get2f(a.x/(float)b.width, a.y/(float)b.height);
  return 0;
}
% tcc x.c && ./a.out
0.005371 0.055078

(which is the correct result)  It also works without the explicit casts to 
float in the divisions, and it works when the initialization of a and b 
are done via assignments, not in the initializer.  So I fear you'll have 
to get us a self-contained testcase showing a problem (or confirm that 
it's no problem anymore with mob branch).



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

Re: [Tinycc-devel] Found an issue when compiling raylib with TCC

[Michael Matz]

Hi again,

On Thu, 31 May 2018, Michael Matz wrote:


I can't find a test which reproduces a problem with current mob branch.


FWIW, I tried your raylib on x86-64 linux with the mob branch of TCC.  The 
problem doesn't reproduce for examples/textures_rectangle, also not when 
going back to raylib commit 1f0cc57ec (the one before your work-arounds 
for TCC).  So if you had the problem on x86-64-linux as well, then it's 
fixed in the mob branch.  If you had the problem somewhere else you need 
to tell us the details.



Ciao,
Michael.

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

Re: [Tinycc-devel] Small bug: Uncalled null function pointer literal makes code unlinkable

[Michael Matz]

Hi,

On Tue, 26 Jun 2018, Petr Skočík wrote:


Hi. I came across this little bug. It's not a showstopper for me but I
thought I'd report it in case somebody knows a quick fix.

example:c.c:
  void y(void);
#define x ((void(*)(void))0)
void call_x() { x?x():y(); }

compiling and attempted linking with

tcc -fPIC c.c -c && tcc -shared -o so.so c.o


on x86_64 (untested elsewhere) gives
  c.o: error: Invalid relocation entry [ 6] '.rela.text' @
  000c


Thanks for the report, fixed in mob.


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

Re: [Tinycc-devel] Overflows in the dynamic linker on x86_64 when using a tcc-built shared library along with others

[Michael Matz]

Hi,

On Thu, 28 Jun 2018, Petr Skocik wrote:


Symbol `__dso_handle' causes overflow in R_X86_64_PC32 relocation
Symbol `fstatat' causes overflow in R_X86_64_PC32 relocation
Symbol `fstat' causes overflow in R_X86_64_PC32 relocation
Symbol `mknod' causes overflow in R_X86_64_PC32 relocation
Symbol `pthread_atfork' causes overflow in R_X86_64_PC32 relocation


Indeed.  TCC doesn't link with crtbegin.o (or crtbeginS.o) coming from 
GCC, and hence doesn't provide the hack symbol __dso_handle (which 
pthread_atfork in glibc needs).  This is another case of an 
interdependency between glibc and compiler specifics.



I tried to make an MCVE (minimal, complete, verifiable example) and this one
should do it:


Thanks.  There's a work around for the pthread_atfork problem: add this 
definition to one source file for each shared library/executable that 
contains a call to pthread_atfork:


  void * __dso_handle __attribute((visibility("hidden"))) = &__dso_handle;

e.g. in your testcase, add it to liblib.c .  Eventually we probably want 
to create this symbol automatically from TCC on glibc systems, until then 
you can use the above.


That fstat/fstatat/mknod have overflows as well might have multiple 
reasons: on glibc systems all three functions have something in common: 
they are defined in the libc_nonshared.a archive, which normally should 
have been included via libc.so (a linker script, not a normal softlink to 
the real shared lib).  You can check with -vvv which should list that 
library to be included.  No matter what I can't reproduce that problem by 
e.g. adding a call to fstatat into your reproducer for the dso_handle 
problem, so if you can provide one for e.g. fstatat as well...



If this is a bad place to post such bug reports, please let me know. 
(Should  I post bug reports on
https://savannah.nongnu.org/bugs/?group=tinycc or elsewhere instead?) 


Many people here don't have a bugzilla account there and so 
don't monitor it; it seems better to write here.



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

Re: [Tinycc-devel] Bug: "mov -0x10(%rbp), %eax", but source is 8-bit signed type

[Michael Matz]

Hi,

On Fri, 22 Jun 2018, Steffen Nurpmeso wrote:


if(use_shexp){
 27d7:   8b 45 f0mov-0x10(%rbp),%eax

That should be movsbl i think.


Yes.  The x86-64 port didn't correctly set the VT_LVAL_xxx bits for 
arguments.  Fixed in mob.



Ciao,
Michael.

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

Re: [Tinycc-devel] codegen bug with tcc x86_64 ?

[Michael Matz]

Hi,

On Sun, 31 Dec 2017, foobar wrote:

please find attached code that exposes a codegen bug in tcc, resulting 
in an endless loop in libtom's embedded bigmath code on x86_64 musl 
linux.


(note: the code in main() under #if 0 exposes another problem, no 
endless loop, but wrong result)


it seems both problems are caused by this line: typedef unsigned long 
mp_word __attribute__((mode(TI)));


Meh, 128bit integer types :-/


when i remove the attribute, GCC exposes the exact same behaviour.


Due to the definition of DIGIT_BIT and MP_64BIT that rely on the 
128bit-ness of mp_word in the testcase.


so if tcc doesnt support this attribute (from [1] TImode - "Tetra 
Integer" (?) mode represents a sixteen-byte integer (128bit type)), 
wouldn't it be better to err out during the compilation, than generating 
unexpected code?


Actually TCC does warn, but only with -Wunsupported :-/  And the reason it 
warns is because of the unknown "mode" attribute.  If it had been __mode__ 
in the source it would have warned about the unknown TI mode used, even 
unconditionally:


% echo "typedef unsigned long int128 __attribute__((__mode__(TI)));" | tcc -c -
:1: warning: __mode__(TI) not supported

vs.

% echo "typedef unsigned long int128 __attribute__((mode(TI)));" | tcc -c 
-Wunsupported -
:1: warning: 'mode' attribute ignored

We should probably handle "mode" like "__mode__" in tcc (and hence always 
warn in this case).


Of course, proper support for QLONG (as TCC calls this), at least on 64bit 
architectures, would be nice.  The support is mostly there in TCC, as it's 
basically the same like supporting 64bit integers on 32bit architectures. 
Just the wiring is missing.



Ciao,
Michael.

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

Re: [Tinycc-devel] Werror-implicit-function-declaration

[Michael Matz]

Hi,

On Thu, 28 Dec 2017, foobar wrote:


$ cat test.c
int t(int x) { return f(x)+1; }

$ tcc test.c -c -Werror || echo error
test.c:1: warning: implicit declaration of function 'f'
error

$ tcc test.c -c -Werror-implicit-function-declaration || echo error
test.c:1: warning: implicit declaration of function 'f'

$ tcc test.c -c -Werror=implicit-function-declaration || echo error
test.c:1: warning: implicit declaration of function 'f'

-Werror by itself seems to work, though it unexpectedly prints "warning" 
instead of error.


neither -Werror-implicit-function-declaration nor 
-Werror=implicit-function-declaration work though (the difference is the 
equals sign after Werror), even though that warning type is implemented.


would it be hard to make it work ? would it be a welcome addition ? any 
other thoughts ?


If you can make it work with just a few lines of code (which I think 
should be possible) I personally would welcome such addition.



Ciao,
Michael.

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

Re: [Tinycc-devel] C99 static array indices in function args

[Michael Matz]

Hi,

On Tue, 26 Dec 2017, Michael B. Smith wrote:

No.  Warnings are never required diagnostics (and even if, what 
specifically would you want to warn about in this case?).  The only 
require diagnostics are from constraint violations.  Most other 
undefined behaviours don't need to be diagnosed (of course, if easily 
doable it's nice to diagnose them).


Here we disagree.


I was arguing from the point of standard conformance, just in case this 
wasn't clear.  I thought you did the same, but now I think you're arguing 
from a quality of implementation perspective.  If so I agree with you, 
such kinds of warnings are nice to have.  As often the case, though, you 
need to find the sweet spot between difficulty of implementing them and 
returned value of the warnings.


As this construct is nearly never used in the real world the value of such 
warning wouldn't be very large.  Implementing it to the fullest extent 
possible (i.e. for calls to functions in the same unit) entails storing 
the necessary meta-info, and hence comes at a non-trivial cost. 
Personally I don't think it's worth it.


More worth would be IMHO a mode where TCC doesn't stop after the first 
error and instead tries to recover.  Has its own set of problems but would 
make tcc more like other C compilers.



Ciao,
Michael.

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

Re: [Tinycc-devel] debug info broken

[Michael Matz]

Hi,

On Thu, 28 Dec 2017, grischka wrote:

Ok, I was able to reproduce the original problem on an suse 10.2 from 
2007.


He :)


It is that in debug mode, tcc includes all sections in the image,
that is also reloc sections that already have been applied.


Hah, finally a reason to fix this long standing issue.  I never came 
around doing anything about this as I thought it didn't matter in the end 
except for filesize, now there's a case where it does matter; super :)



Which is what gcc seems to do too.


Everything works like that (well, except tcc :) ), relocations that are 
applied must not be emitted into the output file.



Ciao,
Michael.

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

Re: [Tinycc-devel] C99 static array indices in function args

[Michael Matz]

Hi,

On Wed, 20 Dec 2017, Michael B. Smith wrote:


It's in 6.7.5.3/7 in C99 for 'static'.

It's in 6.7.3/5 in C99 for 'const'.

Using 'static' seems to have two implied contracts:

[1] don't allow NULL parameters
[2] verify, when possible, that the passed array has AT LEAST the number 
of elements defined


Using 'const' has an implied contract:

[3] treat the array as if were a const array (e.g., "char a[const] --> 
char * const a")


Recent versions of gcc and clang do 1 and 2 (as warnings). I can't find 
anything definitive about 3.


6.7.5.3 #7 is pretty clear, the type qualifiers applied are those from 
within the [ ].  TCC doesn't support this syntax properly right now.



'restrict' is allowed by tcc, but ignored. I think that that is a bug.


Why would you think so?  restrict is a type qualifier that is allowed to 
be applied only to pointer types, parmdecls of array type transform into 
pointer types hence "int a[restrict 3]" in a parmdecl is well defined and 
meaningful.


'restrict' has several defined (not just implied) contracts. This should 
require at least a warning.


No.  Warnings are never required diagnostics (and even if, what 
specifically would you want to warn about in this case?).  The only 
require diagnostics are from constraint violations.  Most other undefined 
behaviours don't need to be diagnosed (of course, if easily doable it's 
nice to diagnose them).



Supporting 'const' properly is actually pretty easy.

Supporting 'static' - well, [1] requires that tcc generate code (to 
handle both runtime and compile-time cases), and [2] may (or may not) be 
easy to do depending on the parameter. If we assume locally defined 
arrays, like VLAs, then it is easy.


There are no changes to emitted code necessary.  The [static 3] syntax is 
an assertion of the programmer, the compiler doesn't have to check it.  On 
the contrary, the compiler is allowed (but not required) to make use of 
this assertion, and assume there are at least 3 elements.  If the 
programmer then gives fewer its his problem, it's undefined behaviour, no 
diagnostic required.  (Of course TCC, not being an optimizing compiler 
wouldn't have much opportunity to make use of these kinds of assertion, 
the same that it doesn't make use of restrict qualitications).



Ciao,
Michael.

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

Re: [Tinycc-devel] TCC version 0.9.27 is out

[Michael Matz]

Hi,

On Mon, 18 Dec 2017, Michael B. Smith wrote:

[1] Other than _Complex/_Imaginary (which C11 now identifies as 
"optional") does anyone have a clear view of what is missing to be c99 
compliant? (I've read the standard and I can build a basic test suite, 
but I just wondered if someone already had the answer.)


c99 support should be relatively complete (as far as the compiler is 
concerned, for full c99 compat you need of course a conforming C library 
as well, if you don't merely want freestanding).  Of course bugs happen, 
so if you find anything, don't hesitate to report here.  Depending on 
circumstance we might want to fix them.


[2] Can 0.9.27 compile a current Linux kernel? Can it generate a 
bootable Linux kernel?


Yes, with some smallish changes to the kernel.  Note that the kernel has a 
much larger set of requirements than c99: it needs some optimizations to 
happen (generally dead code), it needs inline asm support, and it needs 
certain attributes to be implemented and data layout rule to be followed. 
But yes, one of my testbeds is a x86-64 4.6.0 linux kernel with an about 
1000 lines patch on top.  (And another is a ancient 32bit 2.4.37 kernel 
with custom build scripts).



[3] TODO seems ancient. What is the real TODO?


There's none.  Or, if you insist, then something along the lines of "fix 
reporte bugs, keep stuff small, hack on it to have fun" :)



Ciao,
Michael.

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

Re: [Tinycc-devel] "error: undefined symbol main" with -pthread on linux

[Michael Matz]

Hi,

On Sat, 23 Dec 2017, avih wrote:


I think maybe, instead of saying and doing:
-pthread   same as -D_REENTRANT and -lpthread

It should say and do something along these lines:
-pthread   same as -D_REENTRANT while compiling and -lpthread while linking


I decided to keep the help message as is (staying in <= 80 columns), but 
...


However, It seems to still not behave the same as gcc. Using the same 
test.c file as before:


tcc -pthread -c test.c # -> tcc: error: cannot specify libraries with -c

It's not unreasonable I think that tcc complains, but gcc is fine with it.


... I've fixed this behaviour.  I agree that -pthread shouldn't add the 
library with -c (or, well, at least not complain then :) ).



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

Re: [Tinycc-devel] NAN and INFINITY break in different ways

[Michael Matz]

Hi,

On Sat, 23 Dec 2017, avih wrote:


Alpine:
$ tcc test.c
testinfs.c:2: error: division by zero in constant

$ tcc test.c -E
...
static const double infs[] = { (0.0f/0.0f), 1e5000f };
...

So clearly tcc doesn't like musl's fallback definition (if not gcc) for NAN
in a constant, but tcc is fine with musl's INFINITY definition.


I think we could make an exception for 0.0/0.0 and always fold this into 
NaN (normally division by zero is indeed not allowable in constant 
expressions in c99).  That would handle the musl case at least.



Ubuntu:
$ tcc test.c
test.c:2: error: initializer element is not constant

$ tcc test.c -E
...
static const double infs[] = { (__qnan_union.__d), (__huge_valf.__f) };
...

Here it's less clear to me how come tcc doesn't complain about undefined 
symbols,


__qnan_union and __huge_valf are static variables defined in the 
respective headers, so it's no undefined symbols.  Nevertheless it 
wouldn't normally be acceptable in initializers, and with GCC it works 
only because there the headers use __builtin_nan and __builtin_inff.


But the following does seem to solve it relatively correctly I think. Is 
there an objection to install this as /lib/tcc/include/math.h ?


/* override NAN and INFINITY with tcc tokens */

#include_next 

#ifdef NAN
#  undef NAN
#endif
#define NAN __nan__

#ifdef INFINITY
#  undef INFINITY
#endif
#define INFINITY __inf__


I'd be fine with this.  I notice that the c99 NAN and INFINITY are 
supposed to be float constants and currently TCCs __nan__ and __inf__ are 
doubles.  As those tokens are currently not exposed in any headers (as you 
noticed) they're probably unused in the wild and hence can be made floats 
without many problems.  I've done this in mob.  I leave the header thingy 
to you.



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

Re: [Tinycc-devel] NAN and INFINITY break in different ways

[Michael Matz]

Hi,

On Sun, 24 Dec 2017, Vincent Lefevre wrote:


I think we could make an exception for 0.0/0.0 and always fold this into NaN
(normally division by zero is indeed not allowable in constant expressions
in c99).


AFAIK, the standard just implies that 0.0/0.0 is not specified as a
constant expression. But the standard also says: "An implementation
may accept other forms of constant expressions."

Moreover, if Annex F is supported, then FP division by zero is
well-defined. F7.4.2 gives examples with 0.0/0.0 in initializers,
such as:

 static float x = 0.0/0.0; // does not raise an exception

Nowadays, supporting Annex F is more or less a must.


Right you are.  There are differences in rules for accepting integer 
constant expressions and "mere" constant expressions used e.g. for static 
initializers.  They can (and with annex F have to) be accepted and FP 
exceptions be ignored at translation time.  (Not so for non-static 
initializers where the exceptions need to be raised at runtime).


Fixed in mob.


Ciao,
Michael.

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

Re: [Tinycc-devel] [PATCH] tcc: remove buggy nodata_wanted optimization

[Michael Matz]

Hi,

On Thu, 22 Feb 2018, grischka wrote:


However NODATA_WANTED does more than that, for example it also suppresses
the "hello" with
if (0) puts("hello");

Therefor I'd suggest a less radical change, such as:

@@ -6916,7 +6916,7 @@ static void decl_initializer_alloc(CType *type, 
AttributeDef *ad, int r,

align = 1;
}

-if (NODATA_WANTED)
+if (!v && NODATA_WANTED)
size = 0, align = 1;

if ((r & VT_VALMASK) == VT_LOCAL) {


Thus variable space will be allocated always but initializers are
still suppressed.  (Bypassing initializers with goto is not allowed).


For statics it is.  E.g. the following program is valid and must print 
42:


#include 
int main() {
  goto doit;
  if (0) {
static int a = 42;
doit:
printf ("%d\n", a);
  }
}

But the idea of supressing only nameless entities is a good one I think.


Ciao,
Michael.

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

Re: [Tinycc-devel] Get addr2line working with TinyCC

[Michael Matz]

Hi,

On Sat, 24 Feb 2018, Yakov wrote:


I cannot addr2line get working with tcc, here is what I am trying:

---
$ tcc -o exec main.c -lm -g -rdynamic

$ ./exec
exec(show_trace+0x24) [0x407690]
exec(obj_ctx_find+0xeb) [0x413733]
exec(dic_forEach+0xe9) [0x40758e]
exec(obj_serialize+0x120) [0x41577e]
exec(main+0x2e8) [0x41716a]

$ addr2line -e exec 0x41716a -i -p -s -f
main at ??:?

---

Any idea why I get ??:? instead of a line number?


Works for me:

% tcc -o hello hello.c -lm -g -rdynamic
% addr2line -e hello 0x40060f -i -p -s -f
main at hello.c:5

So we'd need a bit more information, e.g. your binary, or output of 
'objdump -gG' on the executable.  I know that some binary tools in some 
version have had problems when an executable mixes DWARF and .stabs debug 
info, which occurs when your crt files contains debug info.  I haven't 
seen such problems in a long time, but who knows.


Also, which version of tcc are you using exactly?  There were some changes 
related to debug info around last year switch.  See also:

  http://lists.nongnu.org/archive/html/tinycc-devel/2017-12/msg00019.html


Ciao,
Michael.

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

Re: [Tinycc-devel] [PATCH] tcc: remove buggy nodata_wanted optimization

[Michael Matz]

Hi,

On Thu, 22 Feb 2018, Mikulas Patocka wrote:

> I think that that nodata_wanted misoptimization should be removed at all 
> - in the C language, you can jump to any location in the function with 
> goto or switch-case statement - thus reasoning such as "all the 
> variables behind if (0) are unreachable" is incorrect.
> 
> If you wanted to do that optimization correctly, you'd need to build 
> control flow graph, and tcc is just too simple to do that.

You're right that as implemented the non-allocation of variables is wrong.  
But a full CFG isn't needed to fix this, the allocation merely needs to be 
postponed to the first real use.  Unfortunately that is somewhat 
complicated when there are initializers (which matter only for static vars 
in this case, but still).

So, yeah, the easy fix is to remove it, but with more work the 
optimization (or parts of it) could be retained, grischka?


Ciao,
Michael.

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

Re: [Tinycc-devel] Mis-parse in some situations involving a function pointer with attributes (breaks SQLite build)

[Michael Matz]

Hello,

On Sun, 22 Jul 2018, Jonathan Newman wrote:


Hi;I happened across this issue while trying to build SQLite. I've attached
a test case. To summarise:
* Start off with a function pointer, correctly assigned to a function that
has attributes, but cast to a void* (or indeed anything except the correct
function pointer type)
* Cast this void* to the correct function pointer type, and call it
* Observe that one cast+call syntax works correctly, and another results in
a misparse:
* tcc thinks the type of the entire expression (cast+call) is a pointer,
instead of the correct return type of the called function (here, an
integer).
* gcc happily accepts both syntaxes
* This breaks compilation of the sqlite.c amalgamation, at least on 32-bit
windows


Thanks for report and testcase; reproducable on linux.  The parser 
prematurely concluded that '__attribute__((foo)) *' can start a type 
(while '*' cannot).  Fixed in mob.



Ciao,
Michael.

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

Re: [Tinycc-devel] Small tcc bugs brought to you by american fuzzy lop

[Michael Matz]

H,

On Mon, 30 Jul 2018, John Scott wrote:


I fuzzed tcc for several hours and found some issues. I'm not familiar
with tcc's code and can't be of much help in resolving these, but they
do affect both 0.9.27 and the latest Git version, so I hope to bring
awareness to these bugs.


Well, in reality it's just a misplaced diagnostic; it's invalid source 
code and tcc rejects it.  But I guess emitting a proper error message 
earlier is nicer.  Fixed in mob, thanks for the report (don't waste too 
much time on fuzzing TCC though; it's generally more useful to test how 
TCC fares on real-world code, not on fuzzed garbage claiming to be C 
code).


Meanwhile, attempting to preprocess `##include<` in a C source file 
causes tcc to hang and consume arbitrarily large amounts of memory.


Can't reproduce this with mob, though:
% cat fuzz2.c
##include<
% ./tcc -E fuzz2.c
# 1 "fuzz2.c"
# 1 "/usr/local/lib/tcc/include/" 1
# 1 "fuzz2.c" 2

(using -c works as well, just to be sure).


Ciao,
Michael.

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

Re: [Tinycc-devel] preprocessor makes attributes disappear

[Michael Matz]

Hi,

On Fri, 6 Apr 2018, ra...@airmail.cc wrote:

I tried modifying my test program to use __attribute instead, in that 
case the code line 3345: case TOK_ALIGNED2: is being executed which is 
good. but again the output is not zeros. Perhaps a.aligned is being 
ignored for functions during codegen.


Ah, I admit of not having looked careful at your example program.  Yes, 
TCC can't align functions currently.  Well, until mob from a few minutes 
ago at least, so enjoy :)



Ciao,
Michael.

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

Re: [Tinycc-devel] preprocessor makes attributes disappear

[Michael Matz]

Hi,

On Thu, 5 Apr 2018, ra...@airmail.cc wrote:

I made this test program which I expect to print all 0's, but it 
doesn't.


I noticed that after tcc -E the attributes have all disappeared.

Any idea what is stopping this from working? the attribute is documented 
and code gen seems to respect TOK_ALIGNED. I wasn't able to understand 
how it vanishes by looking at tccpp.c so advice would be welcome.


Yes, you stumbled over an artifact of the glibc standard headers.  If used 
with a compiler that doesn't claim to be GCC (e.g. with TCC), you'll hit 
this snippet in /usr/include/sys/cdefs.h:


#if !defined __GNUC__ || __GNUC__ < 2
# define __attribute__(xyz) /* Ignore */
#endif

Et voila, all your __attribute__ uses are defined away.  Luckily the 
standard headers don't do the same with either __attribute (without the 
trailing double-underscore), so you can use that in your code. 
Alternatively you can do an '#undef __attribute__' after all standard 
headers are included.  None of that helps for the __attribute__ uses in 
the standard headers themself (although they are optional anyway), for 
that you'd have to define __GNUC__ to 2 at least.  But that has further 
ramifications as TCC is somewhat but not completely compatible with 
several GNU extensions.



Ciao,
Michael.

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

Re: [Tinycc-devel] The built-in memory and bounds checker cannot handle mmap'd memory and judges errno wrong

[Michael Matz]

Hi,

On Fri, 6 Apr 2018, George Gaarder wrote:

I just tried -b to see whether I forgot to free something, and I found that 
the memory and bounds checker will alert when I use the memory I mmap'd. Whi

le I was writing a demo for report, I found that the checker also reported o
ut of region when I accessed errno. I was to print errno to see if I really 
opened the file to be mmap'd.


I think the warning for the mmap'd memory is not a problem, just needed to b
e pointed out in the document. But the errno one is quite strange.


Add these snippets to your program:

#ifdef __BOUNDS_CHECKING_ON
void __bound_new_region(void *p, size_t size);
int __bound_delete_region(void *p);
#endif

... somewhere early in main, before forking, and before accessing errno ...

#ifdef __BOUNDS_CHECKING_ON
  __bound_new_region(, sizeof (errno));
#endif

Keep in mind that errno is a thread local variable (which is also the 
reason why it doesn't work out-of-box, like some other global vars like 
stdout work), so you would have to register each new errno location after 
you create a new thread.  With the above two functions you can also write 
a wrapper for mmap/munmap that suits you.


We could also register at least errno for the main thread at program start 
(in __bounds_init), but it'd still not be a complete solution for 
multi-threaded programs (let's ignore all other problems connected with 
TCCs bound checking and multiple threads), so I'm split-mind about this.



Ciao,
Michael.

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

Re: [Tinycc-devel] preprocessor makes attributes disappear

[Michael Matz]

Hi,

On Sat, 7 Apr 2018, ra...@airmail.cc wrote:

Thank you very much! Where may I find this patch? It has yet not shown 
up on http://repo.or.cz/tinycc.git/tree


Ahem.  I forgot to push the changes, they are there now.


Ciao,
Michael.

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

Re: [Tinycc-devel] Integer promotion issue?

[Michael Matz]

Hi,

On Sat, 31 Mar 2018, Patrick Pelissier wrote:


when compiled with TCC GIT c41caac02d53373b296ccb179b730ada62137cc0
produces the result on an linux/x86-64 platform:

N=9223372036854775810

whereas I was expecting

N=2


Indeed.  Thanks for the report.  Fixed in mob (f0a25ca).


Ciao,
Michael.

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

Re: [Tinycc-devel] Some patches

[Michael Matz]

Hi,

On Sat, 31 Mar 2018, Petr Skocik wrote:


The first takes symlinks into account with header file caching (I need
it with my build setup which uses a symlink in a weird way -- gcc and
clang don't have problems with it but tcc did).


Can you clarify what the problem is exactly?  Thing is: realpath isn't 
available on WIN32, and using it causes many additional syscalls (per 
directory component for each tried include path).  If that's really 
necessary then it'd be better to just open the file in question and use 
the mount id and inode number as differentiator instead of the filename. 
But to understand that I'd like to know what "weird way" means in your 
build setup.



The second fixes stringification with derived types. I noticed tcc
stringified them wrong (like
`void *(int)(int, void *(int))` where it should be `void (*(int, void
(*)(int)))(int)`).


I've pushed this and amended it a bit (actually the above output misses 
another indirection, but that was a problem in _Generics handling of 
types), i.e. added a testcase.



The last one makes tcc ignore static and restrict inside of []. C11
allows these inside parameter declarations (with implications only on
performance and compile-time checking), so I think tcc might as well
silently accept them.


I've also pushed this, with slight changes (adding volatile handling, a 
testcase and formatting fixes).



Thanks for considering the patches and thanks for the work on tcc.


And thank you for the contribution.


Ciao,
Michael.

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

Re: [Tinycc-devel] TCC segfault on Fedora 29

[Michael Matz]

Hi,

On Sat, 3 Nov 2018, Christian Jullien wrote:



BTW, I already reported this BUG in the past:

http://lists.nongnu.org/archive/html/tinycc-devel/2017-10/msg00033.html


I fixed this but that doesn't help the original bug report.  It's 
something specific to Fedora 29' /usr/lib64/crt1.o, so the reporter is 
probably right that it's the update to glibc 2.28 triggering the bug.  As 
I don't have such a new glibc yet I can't reproduce but will given some 
time.  Alternatively: somebody can send me their /usr/lib64/crt*.o files 
from a system where the segfault reproduces.  It's some unhandled 
situation with the section headers in that file.



Ciao,
Michael.



 

 

 

From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org]
On Behalf Of Christian Jullien
Sent: samedi 3 novembre 2018 16:35
To: tinycc-devel@nongnu.org
Subject: Re: [Tinycc-devel] TCC segfault on Fedora 29

 

Main is a special case.

While it is declared as returning an int, it is legal for this function and
only for this function, to NOT return. In this case, it is as if it
explicitly returned 0.

 

C.

 

From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org]
On Behalf Of Nikolajs Agafonovs
Sent: samedi 3 novembre 2018 16:28
To: tinycc-devel@nongnu.org
Subject: Re: [Tinycc-devel] TCC segfault on Fedora 29

 

You forgot return value of function.

 

сб, 3 нояб. 2018 г., 16:50 藍挺瑋 lant...@gmail.com:

  TCC works fine on Fedora 28, but it crashes on Fedora 29. It is
  easily
  reproducible because it cannot even compile a simple program.

  $ echo 'int main(){}' > dummy.c
  $ tcc dummy.c
  Segmentation fault (core dumped)
  $ gdb tcc core.\!usr\!bin\!tcc.signal-11.pid-303
  GNU gdb (GDB) Fedora 8.2-3.fc29
  Copyright (C) 2018 Free Software Foundation, Inc.
  License GPLv3+: GNU GPL version 3 or later
  
  This is free software: you are free to change and redistribute
  it.
  There is NO WARRANTY, to the extent permitted by law.
  Type "show copying" and "show warranty" for details.
  This GDB was configured as "x86_64-redhat-linux-gnu".
  Type "show configuration" for configuration details.
  For bug reporting instructions, please see:
  .
  Find the GDB manual and other documentation resources online at:
      .

  For help, type "help".
  Type "apropos word" to search for commands related to "word"...
  Reading symbols from tcc...Reading symbols from
  /usr/lib/debug/usr/bin/tcc-0.9.27-1.fc29.x86_64.debug...done.
  done.
  [New LWP 303]

  warning: Loadable section ".note.gnu.property" outside of ELF
  segments
  Core was generated by `tcc dummy.c'.
  Program terminated with signal SIGSEGV, Segmentation fault.
  #0  0x55e93017e05c in tcc_load_object_file
  (s1=s1@entry=0x55e931cb2260, fd=fd@entry=3,
  file_offset=file_offset@entry=0) at tccelf.c:2462
  2462                s->sh_info =
  sm_table[sh->sh_info].s->sh_num;
  (gdb) bt
  #0  0x55e93017e05c in tcc_load_object_file
  (s1=s1@entry=0x55e931cb2260, fd=fd@entry=3,
  file_offset=file_offset@entry=0) at tccelf.c:2462
  #1  0x55e93016286c in tcc_add_file_internal
  (s1=0x55e931cb2260,
  filename=0x7ffc2cf18c90 "/usr/lib64/crt1.o", flags=64) at
  libtcc.c:1028
  #2  0x55e930162967 in tcc_add_library_internal
  (s=s@entry=0x55e931cb2260, fmt=fmt@entry=0x55e93018c52f "%s/%s",
  filename=filename@entry=0x55e93018c567 "crt1.o",
  flags=flags@entry=0,
  paths=,
      nb_paths=) at libtcc.c:1109
  #3  0x55e930162b17 in tcc_add_crt (s=s@entry=0x55e931cb2260,
  filename=filename@entry=0x55e93018c567 "crt1.o") at
  libtcc.c:1125
  #4  0x55e930162c7f in tcc_set_output_type (s=0x55e931cb2260,
  output_type=2) at libtcc.c:978
  #5  0x55e93015fa4d in main (argc0=2, argv0=0x7ffc2cf19298)
  at tcc.c:312

  I guess it may be related to the Binutils 2.31 and GLIBC 2.28
  upgrades
  in Fedora 29. I also tested the latest version from git, and it
  crashed
  in the same way.

  ___
  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] Fixes to bugs in `type_to_str` and `compare_types`; patches to CLI options

[Michael Matz]

Hello,

On Mon, 12 Nov 2018, Petr Skočík wrote:

> My shot at the fixes is at https://github.com/pskocik/tinycc. It's 
> separated into addition of failing tests and fixes to those tests.

The fixes seem sensible, but I have some stylistic nits:
* please add testcases and fixes for them in the same commit, or the
  testcases after the fixes  (so that there are no revisions that have 
  known fails, which eases bisecting), in this case probably in the same
  commit
* if you're using  characters in your changes, please make sure your
  editor has set tabstops at eight characters; as is one of your changes 
  looks like this (tabs replaced by spaces to demonstrate):

}else if(bt1 & VT_ARRAY){
return type1->ref->c < 0 || type2->ref->c < 0
|| type1->ref->c == type2->ref->c;
}   else if (bt1 == VT_STRUCT) {
return (type1->ref == type2->ref);

  Also respect the surrounding style: space between '}' and 'else' (and 
  not a  or nothing).
* one change you had was:
if(varstr && '*'== *varstr){
  Surrounding style has spaces around comparisons.  (the '42 == x' style 
  is peculiar as well; I know the reasoning behind it, and in that 
  function there's precedent so I won't _really_ complain ;) )

> I've also thrown in a separate patch that allows `tcc -o -` to be
> treated as "write output to stdout".

That seems fine.

> (I had problems with -o /dev/stdout on some Cygwin IIRC) and another one
> that makes libc accept `-l lib` in addition
> to `-llib` (because gcc/clang do and POSIX specifically wants it).

And that as well, even though my first reaction was "sigh, POSIX" ;)

So only really minor things, but at least a bit of consistency is nice to 
have.  I'd say commit to mob, after fixing the above.


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

Re: [Tinycc-devel] Function pointers declared in a particular way result in a miscompilation

[Michael Matz]

Hello,

On Sat, 29 Dec 2018, Jonathan Newman wrote:


Hi,This seems to be the issue causing SQLite compilation to fail (or at
least part of it/related to it).

When a function pointer is declared in a particular way, it seems that
__stdcall (and presumably other attributes?) are ignored. As a result, TCC
thinks the function is caller-cleanup when it is not, and the stack gets
"cleaned" twice.

See the full test case attached. As a quick summary,

This works:
((int __stdcall (*)(int, int, int))some_stdcall_func) (2, 0, 0);

And so does this:
((int(*__stdcall)(int, int, int))some_stdcall_func) (3, 0, 0);

But this fails:
((int(__stdcall*)(int, int, int))some_stdcall_func) (4, 0, 0);


Aha, thanks for the investigation and testcase, that really helps.  This 
particular problem is now fixed on trunk.  Lacking win32 I can't 
check if it completely fixes SQLite, but at least your testcase works when 
cross compiled and run under wine.



Ciao,
Michael.

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

Re: [Tinycc-devel] Add gcc cleanup attribute support

[Michael Matz]

Hi,

On Wed, 2 Jan 2019, uso ewin wrote:


I've try to add support to cleanup attribute to TCC:
https://github.com/cosmo-ray/tcc/tree/cleanup

Are you interested in having this feature merge in mob ?
If yes it would be nice if someone could review my code


As you found out the one-pass nature of TCC makes implementing this 
somewhat awkward.  Though you found some inventive solution to this I 
don't particularly like it, specifically:


* your use of tokens instead of a symbol ID in the cleanup attribute seems
  wasteful: in principle a cleanup is an association of a function
  (representable as its name, as ID) with a decl (a Sym), so that should
  be the only necessary thing, not the token string representing
  "func()" (when the cleanup is function "func" on decl "foo").
* your way of dealing with the "goto forward" problem is to read and
  remember all tokens after the goto until you find the label (and if so
  do the cleanups), rereading all these tokens afterwards.

  This feels ugly and against the one-pass nature (and is quadratic if you
  have very many gotos); several alternatives come to mind, though I
  haven't tried any of them to see if they result in less ugly code: e.g.
  you could remember all potentially scope-exiting gotos and check them at
  scope exit (redirecting them to the cleanup and then further to the real
  destination).

I'm somewhat sympathetic to having that GCC extension, though it is one of 
the more arcane ones that isn't trivial to support and isn't used very 
often in the wild (did you have any software in mind that made you 
implement the extension?).  So the advantage of having that extensions 
needs to be weighed fairly lightly against the disadvantage of 
complicating TCCs sources.  IMHO your current implementation leans more on 
the disadvantage side.  But maybe you can rework it somewhat along the 
remarks above and it turns out more elegant?



Ciao,
Michael.

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

Re: [Tinycc-devel] TCC-0.9.27 Static linking with uClibc-0.9.30 workabout

[Michael Matz]

Hi,

On Sat, 5 Jan 2019, Kurt Nalty wrote:

   For the specific environment of uClibc-0.9.30, to enable static 
linking, I reverted the ELF_START_ADDR to 0x08048000 and ELF_PAGE_SIZE 
to 0x1000, as was done in TCC-0.9.26, and found success. However, this 
fix does not work for the musl libraries, and is contrary to the 
preferred x86_64 start address, so I don't recommend this change, merely 
report its success for one specific environment.


This must be only a side effect, neither the start address nor the page 
size should influence the functioning of the result, except if they 
expose any existing bugs in uClibc.  You'll have to dig a bit to learn 
what the real cause of the segfaults with uClibc are.  (It's an 
interesting data point, though)



Ciao,
Michael.

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

Re: [Tinycc-devel] Add max_align_t to stddef.h and C11

[Michael Matz]

Hi,

On Sun, 13 Jan 2019, Christian Jullien wrote:

> I don't agree with you for c11 flag.
> I participate to C++ standardization committee (which includes links to C).
> We really take care of visible names and available features. That's why C
> now includes more and more __STDC_xxx to detect what features are present or
> not.
> It greatly helps to write portable code.

Sure, I understand all that.  But if it leads to uglifying TCCs source 
code too much I'd rather just remove the C99/C11 claim from TCCs docu and 
replace it with "some random set of C99/C11 features that occur in the 
wild and let you allow to compile much code in practice" :-)

The thing is: conformance is a very hard goal to reach, the last 5% or so
(somewhere at which we are with TCC, I'd say) are extremely costly to get 
(either by size, beauty or performance of code), and the question is if 
TCC should pay that price.  I don't know the answer to that, of course, 
but I am wary.


Ciao,
Michael.

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

Re: [Tinycc-devel] Segfault with .skip

[Michael Matz]

Hi,

On Fri, 18 Jan 2019, Giovanni Mascellani wrote:

> while trying to compile some Linux kernel code, I found that tcc crashes
> when given the following .s file:
> 
> 
> .skip 2f-1f,0x90
> 1:
> 2:
> 
> 
> It works correctly with backward references. Is there any hope to fix it
> to accept forward references as well?

Everything could be fixed :-)  As it would require changes to the internal 
data structures and would mean ditching the single-pass nature of the 
assembler it's a very non-trivial fix, though.  You effectively would have 
to go to a frag model of potentially-unknown-sized chunks of bytes and a 
list of still unresolved addresses that you iterate over until all are 
resolved.  Like e.g. GNU assembler has.  Not tiny at all :)


Ciao,
Michael.

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

Re: [Tinycc-devel] TinyCC for bootstrapping (with patches)

[Michael Matz]

Hi,

On Sun, 13 Jan 2019, Giovanni Mascellani wrote:

> 2) I patched TinyCC so that it can be built by a compiler that does not
> support floating point numbers (as is the case for the C compiler in
> asmc that builds TinyCC). Basically I import in the TinyCC repository
> the code from the Berkeley SoftFloat library[3] and replace each
> operation between floating point numbers with the corresponding call to
> SoftFloat. SoftFloat is licensed under a permissive BSD-style license,
> so it should pose no problems to be linked with TinyCC. I also had to
> take some code from musl (mainly to implement strtod and variants),
> which is licensed under a MIT license.
> 
>  [3] http://www.jhauser.us/arithmetic/SoftFloat.html
> 
> In its current form the SoftFloat patch is totally not acceptable for
> inclusion in mob. It is quite messy and I doubt it works properly for
> non-Intel architectures. However, before fixing it up I would like to
> know what is your opinion on including this feature in TinyCC. If would
> definitely bring in a lot of new code, which might be against the KISS
> philosophy that TinyCC has.

Hmm, I wouldn't support including softfloat as is in the tcc repo (the 
historic messiness of BSD softfloat only being one reason; 
size and anti-KISS being others).

I would support changing tcc such that it's possible to use it as 
external(!) optional dependency.  You could also make the constant folding 
for float types conditional on ifdefs.  That would leave only the 
load/stores of float types and the dreaded string-to-float conversions.

> Thanks for reading and for working on TinyCC, and please let me know 
> what you think of my patches.


Ciao,
Michael.

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

Re: [Tinycc-devel] Missing C99 standard headers in win32

[Michael Matz]

Hi,

On Sun, 13 Jan 2019, Christian Jullien wrote:

> ISO/IEC 9899 :1999 (E) specifies that (Section 7.1.2 p. 165), Standard
> headers are:
> 
> Those already in win32 lack
> 
>  complex (and imaginary) support
>  restricted character set support via digraphs
>   type-generic math macros
> 
> To make tcc a little bit more C99 conformant I added 

Hmm?  TCC follows the traditional split between compiler and C library.  
You can only consider the combination of both to determine standard 
conformance.  Maybe you want to provide C99 compatibility somehow via some 
project, but I don't see why TCC should be that project.  But OTOH there 
are already project that provide that, e.g. mingw for Windows and 
$arbitrary-libc for everyone else.


Ciao,
Michael.

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

Re: [Tinycc-devel] not an issue, surely a mistake

[Michael Matz]

Hi,

On Sat, 24 Nov 2018, ian wrote:


None of my habits, but I'd like an advice. I didn't code in C for many many
years. But...
I did a few years ago correctly install tcc on my windows 7, but
unfortunately it went down (winscrap), and I only have my debian 8 x32 other
PC (kinda server for apache/php/mysql/pgsql/ and so on).

I did get the last release found, and I have this error while trying to
compile a simple "Hello World, exit=%d"...

I get almost the same kind of error while trying to compile gcctestsuite.c

tcc: file '/usr/lib/crt1.o' not found
tcc: file '/usr/lib/crti.o' not found
In file included from test.c:1:
In file included from /usr/include/stdio.h:27:
/usr/include/features.h:374: include file 'sys/cdefs.h' not found


You miss the development files for glibc, I think on debian it's libc-dev 
or libc6-dev.  (after installing those you probably need to 
reconfigure/build tcc, so that it searches in the correct dirs on debian).



Ciao,
Michael.

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

Re: [Tinycc-devel] x86_64, musl: generation of mixed C/C++ fails: undefined reference to `__va_start'

[Michael Matz]

Hello,

On Thu, 3 Jan 2019, Steffen Nurpmeso wrote:


Regardless of whether i use the AlpineLinux default tcc package,
or my version with the little path-resistancy patch, i cannot
create a binary from several C files which become compiled with
tcc -static and linked to an -ar chive, and some C++ files:

 ...
 clang -Dsu_USECASE_SU -I../../src -I../../include -Wall -pedantic -o .main.o 
-c .main.cc
 tcc -Dsu_USECASE_SU -I../../src -I../../include -static -g -O1 -Wall -pedantic 
-o avopt.o -c avopt.c
 ...
 tcc -ar .clib.a avopt.o core-code.o core-errors.o cs-alloc.o cs-ctype.o 
cs-dict.o cs-find.o cs-misc.o cs-toolbox.o cs-tools.o icodec-dec.o icodec-enc.o 
mem-alloc.o mem-bag.o mem-tools.o prime.o utf.o
 clang  -o .main cxx-core.o .main.o .clib.a
 /usr/bin/ld: .clib.a(core-code.o): in function `su_log_write':
 /home/steffen/src/nail.git/src/su/core-code.c:233: undefined reference to 
`__va_start'

The reason is of course that this symbol resides in
/usr/lib/tcc/libtcc1.a, but that is unknown to the linker.
That makes me feel quite dumb, i would not know nothing but
-static in order to address that myself (except for -ar checking
unreferenced symbols for this name, i have never looked into ar(1)
but would not think it goes that far)?


Well, you have to add the TCC support library into the link process. 
Either by using TCC as linker instead of clang or by explicitely listing 
it.


That's not different from other compilers, e.g. when compiled by GCC you 
need to link with libgcc.a (or libgcc_s.so), either by using gcc as link 
editor or by listing it explicitely.  I.e. compilers always come with a 
support library that implements whatever code is relied upon by their 
implementation (e.g. for GCC that could be functions for dealing with 
decimal float numbers), and you need to include those libraries when 
linking object files produced by those compilers.  Usually that's done by 
using the respective compiler as link editor which automatically adds the 
support library.  Obviously that won't work if you use multiple compilers: 
you can only choose one as the link editor (you chose clang) and hence 
have to list the support library of the other one explicitely (libtcc1.a 
for your case).


You seem to be under the impression that -ar somehow could deal with this: 
it can't.  ar does nothing more than essentially packing all object files 
you listed into one .a file.  In particular no symbol resolution or 
linking steps are involved, and so the reference to __va_start is left 
untouched.  In this case even listing libtcc.a wouldn't help as ar 
leaves other archives alone.  You would have to unpack libtcc.a and 
include its individual object files in the tcc -ar command.  (But then you 
can just as well just mention that library in the link editing step 
later).


I hope this clarifies the problem a bit.  In short: you have to list 
libtcc.a explicitely.



Ciao,
Michael.

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

Re: [Tinycc-devel] Add gcc cleanup attribute support

[Michael Matz]

Hi,

On Thu, 3 Jan 2019, uso ewin wrote:


* your way of dealing with the "goto forward" problem is to read and
   remember all tokens after the goto until you find the label (and if so
   do the cleanups), rereading all these tokens afterwards.

   This feels ugly and against the one-pass nature (and is quadratic if you
   have very many gotos); several alternatives come to mind, though I
   haven't tried any of them to see if they result in less ugly code: e.g.
   you could remember all potentially scope-exiting gotos and check them at
   scope exit (redirecting them to the cleanup and then further to the real
   destination).


Well, the problem with checking this at scope exit or at the label declaration
is that as TCC do single pass generation, I can't go back and
regenerate the goto.


Not the goto, but you can adjust where the goto goes to.  You wouldn't 
link these gotos in the label->jnext members, but in some on-the-side 
structure (also remembering the ultimate label they would have to go to, 
you could probably use the existing dynarray_* code). 
When you reach a label definition you remove all pending gotos for that 
label (they don't skip over the scope exit).  When you reach a scope exit 
all pending gotos must first go to the cleanup snippet and then to the 
ultimate label.



A way to solve this would be either to create a switch case after each label
that might need cleanup, or a dummy function for each goto in need.


That latter is what you're essentially having right now: you check if the 
current goto in question leaves the scope, and if so emit all the cleanup 
code first and then the goto.  I.e. for multiple gotos you repeat the 
cleanup code.  That seems a sensible approach (the switch approach might 
lead to smaller code, but this shouldn't matter much here and is more 
complicated).



Either way, the code needed to handle that would be a lot more complex
that current implementation which is ~30line for handling the forward goto case
and that is call only in scope that contain cleanup variable.


Remembering gotos would also only be done when there are pending cleanups.
It might be that you're right that it would take even more code.  But I'm 
not so sure.  The remembering and reiteration over tokens really gripes at 
me.  E.g. think about this code:


   { int a CLEANUP(foo);
 ...  goto later1; ...
 ...  goto later2; ...
 large chunk of code
   }
   later1:
   ...
   later2:

For both gotos you iterate over the large chunk of code shifting tokens 
back and forth between the token strings and the parser.  As I said, it's 
a cute trick to get what you need, but there has to be a better way.


We could also declare that forward jumps within scopes needing cleanups is 
simply not supported in TCC (with an appropriate error message).  I would 
prefer even that crippling of the support compared to the token sifting.



If I use Sym but keep the dual parsing that would happen only
when we have a goto forward and a scope containing cleanup,
would the balance switch to the advantage side ?


A bit, but the dual parsing makes me really unhappy :-)  Do you have 
cycles for trying an alternative approach to at least compare both?



Ciao,
Michael.

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

Re: [Tinycc-devel] Add max_align_t to stddef.h and C11

[Michael Matz]

Hi,

On Fri, 11 Jan 2019, Petr Skočík wrote:


Having __STDC_VERSION__ reflect the -std= command option is great.
However, I think that disallowing _Generic and _Alignof at lower
versions is unnecessarily pedantic (as in a behavior more suitable for
compiler runs invoked with `-pedantic`). Unlike max_align_t, _Generic
and _Alignof are reserved identifiers in any C version. They shouldn't
ever need to be hidden. Hiding them can unnecessarily break some project
builds that use tcc with  _Generic or _Alignof and without -std=c11.


Agreed.  We should remember the name: _tiny_ cc.  Pedantism stands against 
that.  If people want their code checked for conformance they should use a 
different compiler.  Already the changes between c11 and c99 seem too 
pedantic for my taste, I'd have left in the max_align_t typedef even in 
C99.  If people complain that this isn't conforming, then so what?  There 
are so many other things not being conforming in tcc that this seems like 
a useless corner case.


I certainly don't want to see TCCs sourcebase becoming sprinkled with a 
myriad of 'if (stdc11 || stdc99)' conditionals.


Having said this, I don't object to the patches that now went in.


Ciao,
Michael.




Petr S.


On 1/10/19 11:47 PM, uso ewin wrote:

On Thu, Jan 10, 2019 at 2:47 PM Christian Jullien  wrote:


Matthias,


I'm happy you like my patch. I was waiting for comments before pushing this
patch.
As you said, no one protested (or care), so it is committed in mod.

It let you add the logic for the C11.

Christian

-Original Message-
From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org]
On Behalf Of uso ewin
Sent: jeudi 10 janvier 2019 11:13
To: tinycc-devel@nongnu.org
Subject: Re: [Tinycc-devel] Add max_align_t to stddef.h and C11

On Tue, Jan 8, 2019 at 6:02 PM Christian Jullien  wrote:



Maybe add a global variable


Not global but a new member of TCCState, for example cversion

If (s->cversion >= 201112) {
  /* Hello C11 */
}

Diff becomes:

jullien@sims3:~/new-tcc $ git diff
diff --git a/libtcc.c b/libtcc.c
index df7adab..7883734 100644
--- a/libtcc.c
+++ b/libtcc.c
@@ -1790,8 +1790,16 @@ reparse:
 s->static_link = 1;
 break;
 case TCC_OPTION_std:
-   /* silently ignore, a current purpose:
-  allow to use a tcc as a reference compiler for "make test"

*/

+if (*optarg == '=') {
+++optarg;
+if (strcmp(optarg, "c11") == 0) {
+   tcc_undefine_symbol(s, "__STDC_VERSION__");
+   tcc_define_symbol(s, "__STDC_VERSION__", "201112L");
+   s->cversion = 201112;
+}
+}
+ /* silently ignore other values, a current purpose:
+allow to use a tcc as a reference compiler for "make

test"

*/
 break;
 case TCC_OPTION_shared:
 x = TCC_OUTPUT_DLL;
diff --git a/tcc.c b/tcc.c
index f780389..2d4e1ea 100644
--- a/tcc.c
+++ b/tcc.c
@@ -33,6 +33,8 @@ static const char help[] =
 "  -o outfile  set output filename\n"
 "  -runrun compiled source\n"
 "  -fflag  set or reset (with 'no-' prefix) 'flag' (see tcc

-hh)\n"

+"  -std=c99Conform to the ISO 1999 C standard (default).\n"
+"  -std=c11Conform to the ISO 2011 C standard.\n"
 "  -Wwarning   set or reset (with 'no-' prefix) 'warning' (see tcc
-hh)\n"
 "  -w  disable all warnings\n"
 "  -v -vv  show version, show search paths or loaded files\n"
diff --git a/tcc.h b/tcc.h
index cc85291..8416cc5 100644
--- a/tcc.h
+++ b/tcc.h
@@ -651,6 +651,7 @@ struct TCCState {
 int rdynamic; /* if true, all symbols are exported */
 int symbolic; /* if true, resolve symbols in the current module first
*/
 int filetype; /* file type for compilation (NONE,C,ASM) */
+int cversion; /* supported C ISO version, either 0 (199901), 201112,
... */

 char *tcc_lib_path; /* CONFIG_TCCDIR or -B option */
 char *soname; /* as specified on the command line (-soname) */



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


I like the version with cversion in tcc state.

As no one protest, I guess you can push.
Do you want to patch existing C11 code too ?
if not I can do it, but I need this patch to be merge.

Matthias,

___
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


Hi,

I've push the patch to allow _Alignof and _Generic only when -std=c11 is use.

Matthias,

___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org

Re: [Tinycc-devel] x86_64 static link fix

[Michael Matz]

Hi,

On Wed, 9 Jan 2019, Kurt Nalty wrote:


After firing up gdb, and tracing through a few combinations of static and 
dynamically linked object files, I have determined that the segfaults were due 
to usage of procedure linking tables
(.plt) with the statically linked process. The plt addresses are not corrected  
when static loaded, but are corrected during dynamic linking. File 
x86_64-gen.c, lines
630-634 were

#ifdef TCC_TARGET_PE
   greloca(cur_text_section, vtop->sym, ind + 1, R_X86_64_PC32, 
(int)(vtop->c.i-4));
#else
   greloca(cur_text_section, vtop->sym, ind + 1, R_X86_64_PLT32, 
(int)(vtop->c.i-4));
#endif

and are replaced by
   greloca(cur_text_section, vtop->sym, ind + 1, R_X86_64_PC32, 
(int)(vtop->c.i-4));

This restores correct static linking in uClibc-0-9.30 and musl 
environments. Dynamic linking is unaffected, and continues to use 
procedure link table jumps and calls.


It's still wrong.  The relocation to use really should be PLT32, even 
though it doesn't often make a difference (*).


I've now found time to look into this, i.e. static linking with uClibc.  I 
fixed some problems in mob and reverted your patch again.  A simple hello 
world now works statically with uClibc.  Would be nice if you can retry 
(and maybe with bigger examples :) ).



Ciao,
Michael.
* it's a historic mistake of the initial x86-64 psABI implementations that 
PC32 relocs are sometimes used in place of PLT32 relocs (or from a 
different point of view, that both relocations exist, and not only PC32).


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

Re: [Tinycc-devel] Implementing .macro gas syntax

[Michael Matz]

Hi,

On Sat, 26 Jan 2019, Giovanni Mascellani wrote:

as part of my bootstrapping project that I have already mentioned a few 
emails ago, I would like to be able to compile Linux with tcc, trying to 
patch Linux as little as possible.


Btw, I still owe you an answer.  I've finally pushed my somewhat changed 
tcc-compatible linux 4.6 kernel to github:


  https://github.com/susematz/linux

branch tcc46.

See README.tcc therein for hints.  Should work out-of-box as is within 
qemu on x86-64 with the provided configs and initrd.  (Using the faster 
multi-boot hacks with qemu might require changes in qemu itself depending 
on the used version).


Currently Linux uses the .macro syntax for the gas assembler, that I 
would therefore like to implement in tcc.


16bit code gen, and certain other assembler constructs are still missing 
as well (e.g. the easier .incbin), but yes, .macro is a large part of 
what's still missing.



migrated there. Is this correct? In particular, I suppose that all new
state should go into TCCState, not into other globals.


If at all possible without going through hoops, yes.


2. C preprocessor macros are kept in the table_ident global array and
manipulated with define_push and similar functions. Each of them has a
type that can be MACRO_OBJ or MACRO_FUNC. I am undecided whether gas
macros should be implemented as an additional macro type (e.g.,
MACRO_GAS) and kept in the same array, or a new array should be created
for them. The pro in the first case is that helper functions (like
define_push and similar) are already there; however that would mean that
the C preprocessor code must be modified so that it does not get
confused by the appearance of a third macro type. What do you think
about that?


Interesting idea.  There's a small complication: the assembler source 
might be preprocessed itself, so there might be both a preproc macro named 
foo, as well as an assembler macro named foo.  Requires chaining and 
associate changes in the preprocessor to ignore the new type, as you say, 
which might slow it down a tiny bit.  I'd say, implement that idea and see 
how it looks like in the end, it's especially worth it if you really can 
reuse some of the existing routines.


One other problem might be the handling of backspace to refer to macro 
args within macro bodies, which the tokenizer might act up on.  Haven't 
tried yet (supporting .macro was on my TODO somewhere down :) ).



Ciao,
Michael.

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

Re: [Tinycc-devel] tcc fails UBSan and ASan

[Michael Matz]

Hi,

On Sat, 26 Jan 2019, Giovanni Mascellani wrote:


This already prints lots of errors when tcc compiles libtcc1.a, mostly
about unaligned struct access. An example:


tcctools.c:189:21: runtime error: member access within misaligned address 
0x564f628c4d3c for type 'struct Elf64_Shdr', which requires 8 byte alignment
0x564f628c4d3c: note: pointer points here
  00 00 00 00 01 00 00 00  01 00 00 00 06 00 00 00  00 00 00 00 00 00 00 00  00 
00 00 00 40 00 00 00
  ^


Uninteresting problem.  TCC supports only architectures where 
non-naturally aligned accesses are fine (or at least 4-byte aligned 
accesses).



tcctest.c: In function ‘switch_test’:
tcctest.c:1969:6: error: case label does not reduce to an integer constant
  case 4LL << 61:
  ^~~~


That's tcctest.c.  It intentionally contains several non-standard 
constructs.



Some use-after-free are found in 07_function, 25_quicksort,
26_character_constants and 80_flexarray.


Also testcases.  They shouldn't be changed to cater for such checking (or 
if, then only carefully so, so that they afterwards indeed still test what 
they were supposed to).



I can try to fix them, but maybe people more knowledgable than me might
be quicker and produce a more correct fix.


If you can fix the misaligned accesses without using memcpy or similar 
100% portable means that just busily change code to please automatic 
tools then fine.  Please don't change the testcases for automatic tools.



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

Re: [Tinycc-devel] Implementing .macro gas syntax

[Michael Matz]

Hi,

On Sun, 27 Jan 2019, Giovanni Mascellani wrote:


16bit code gen, and certain other assembler constructs are still missing
as well (e.g. the easier .incbin), but yes, .macro is a large part of
what's still missing.


For my project I might be in a slightly easier situation: I already have
tcc running at ring 0 in protected mode (without pagination), and what I
want to do is to compile and load Linux directly (using tcc_relocate()).


Ah, yes, that definitely eases things.


generate a bzImage. Of course I will need to understand Linux 32 bits
boot protocol and fill appropriately boot_params when jumping in Linux,
but that still seems to be easier than generate the whole bzImage and
perform the 16 bits boot protocol.


You should be able to start from the multiboot startup I've added to my 
linux repo, it takes over from whatever multiboot loader in 32bit 
protected mode, i.e. that code is fully compilable by TCC, and the 32bit 
asm parts shouldn't be much hassle once .macro is there.


With these assumptions, it seems that the big missing thing in tcc is 
.macro, and that's why I directed my attention on it at once. Also 
because, on the other hand, using gcc is a compromise I cannot afford: I 
wish I was already able to build gcc at that level of bootstrap...


You need to start from a GCC version that still was written in C.  A 
couple years ago x86-64 TCC was able to compile the last C variant of GCC, 
version 4.7.x.



I guess my idea was to error out when preproc and gas defined two macros
with the same name...


Also a possibility, depends on which one is easier and lighter on the fast 
paths in the preprocessor.



Ciao,
Michael.

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

Re: [Tinycc-devel] TCC segfault on Fedora 29

[Michael Matz]

Hi,

On Mon, 4 Mar 2019, Christian Jullien wrote:

> Ooops, not quite.
> I missed this line on log file (from Fedora 29).
> Btw, as suggested by ./configure,  Fedora 29 requires --with-selinux
> 
>  dlltest 
> ../tcc -B.. -I../include -I.. -I.. -DCONFIG_LDDIR="\"lib64\""
> -DTCC_TARGET_X86_64 -DHAVE_SELINUX -DLIBTCC_AS_DLL ../libtcc.c -lm -ldl
> -shared -o libtcc2.so
> make[1]: *** [Makefile:132: dlltest] Segmentation fault (core dumped)

Different bug?  I don't have fedora 29 so can't debug this myself, what 
does the gdb backtrace look like for the coredump (to make that easier, 
build tcc with '-O0 -g', not the default -O2, i.e. change CFLAGS in 
config.mak).


Ciao,
Michael.


> 
> -Original Message-
> From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org]
> On Behalf Of Michael Matz
> Sent: lundi 4 mars 2019 16:58
> To: tinycc-devel@nongnu.org
> Subject: Re: [Tinycc-devel] TCC segfault on Fedora 29
> 
> Hi,
> 
> On Fri, 1 Mar 2019, Klaus Ebbe Grue wrote:
> 
> > Is there news on the Fedora 29 segfault problem?
> 
> No, as nobody provided the breaking crt*.o files ...
> 
> > > some time. Alternatively: somebody can send me their /usr/lib64/crt*.o
> > > files from a system where the segfault reproduces. It's some unhandled
> > 
> > I have included my /usr/lib64/crt*.o files, if that helps (I hope the 
> > mailing list accepts attachments).
> 
> ... until now.  Fixed in mob.
> 
> 
> 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 mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] TCC segfault on Fedora 29

[Michael Matz]

Hi,

On Fri, 1 Mar 2019, Klaus Ebbe Grue wrote:

> Is there news on the Fedora 29 segfault problem?

No, as nobody provided the breaking crt*.o files ...

> > some time. Alternatively: somebody can send me their /usr/lib64/crt*.o
> > files from a system where the segfault reproduces. It's some unhandled
> 
> I have included my /usr/lib64/crt*.o files, if that helps (I hope the 
> mailing list accepts attachments).

... until now.  Fixed in mob.


Ciao,
Michael.

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

Re: [Tinycc-devel] Undefined symbol '__ashldi3'

[Michael Matz]

Hi,

On Wed, 13 Mar 2019, Andy Goth wrote:

> Thank you for all your help. I have succeeded in resolving the issue. As I
> stated in my first email, I am using gcc to compile tcc. gcc is indeed
> putting underscores at the beginning of symbol names and is using the PE
> object file format. To work around this, I patched the tcc4tcl build
> process to run objcopy on libtcc1.a to remove the underscores and convert
> the archive members to ELF. The patch is probably not of interest to anyone
> else here because it includes no changes to tcc itself.

Ah, newer TCCs always compile libtcc1 with TCC itself (except if using a 
non-default explicit make target), so this should be specific to the old 
TCC version used by tcc4tcl.  Cute hack^Wwork-around with objcopy :)


Ciao,
Michael.

> 
> See also: http://wiki.tcl.tk/tcc4tcl
> 
> On Wed, Mar 13, 2019, 08:33 Michael Matz  wrote:
> 
> > Hi,
> >
> > On Tue, 12 Mar 2019, Andy Goth wrote:
> >
> > > So there's the big clue. The code is asking for ashldi3 with two leading
> > > underscores, but the archive index contains ashldi3 with three leading
> > > underscores. Thus, the archive object libtcc1.o doesn't contain the
> > > requested symbol and therefore is not loaded.
> >
> > Well, so there's a mismatch in configuration between whatever compiled
> > your libtcc1.o and your TCC used as code generator, I think it's best to
> > resolve this instead of trying to make it work in presence of this
> > mismatch.
> >
> > > I read that on 32-bit (but not 64-bit) Windows, "cdecl" function names
> > > are prefixed by an underscore. (Also I see _tclStubs, which is a global
> > > variable, has an underscore prefix too.) There's a fair bit of code in
> > > tcc to address this, for example in pe_find_import(), but there's no
> > > analogue in tcc_load_alacarte().
> > >
> > > It seems odd adding PE-specific symbol mangling code to
> > > tcc_load_alacarte() which lives in tccelf.c. Instead, I feel it makes
> > > more sense for the PE-specific part of put_extern_sym2() to handle
> > > FUNC_CDECL when can_add_underscore is true.
> > >
> > > This... works? Kind of? When I try it, it indeed calls
> > > tcc_load_object_file() because ___ashldi3 now matches. But then it fails
> > > with an "invalid object file" error, since tcc_load_object_file() chokes
> > > on the object file not starting with the ELF header magic number. And it
> > > makes perfect sense that it would fail, since the object file is in PE
> > > format, not ELF.
> > >
> > > How is this expected to work? Is it wrong to put PE object files in an
> > > "ar" archive? That's how the makefile does it on all platforms, so
> > > clearly that's intended.
> >
> > TCC can only load ELF object files (and archives), also on Windows.
> > (Well, it can also load the export table of Windows PE DLLs).  So if you
> > want to load libtcc1.a it must be produced by a compiler producing ELF
> > files (on Windows it's probably easiest if it's produced by TCC).
> >
> > Maybe that's where your mismatch comes from?  That your libtcc1.o/a is
> > compiled by something else than the TCC you have?
> >
> >
> > Ciao,
> > Michael.
> >
> > >
> > > On Tue, Mar 12, 2019, 12:50 Louis Botha  wrote:
> > >
> > > > Hi Andy,
> > > >
> > > >
> > > >
> > > > I have a Windows application that loads libtcc1-32.a or libtcc1-64.a
> > > > dynamically, all I did was to call both with of these:
> > > >
> > > >
> > > >
> > > >tcc_set_lib_path
> > > >
> > > >tcc_add_library_path
> > > >
> > > >
> > > >
> > > > before calling tcc_compile_string (not sure if both of these are needed
> > > > but that’s what I did originally).
> > > >
> > > > The path that I passed to those functions has a sub-folder called lib
> > that
> > > > contains libtcc1-32.a and libtcc1-64.a,
> > > >
> > > >
> > > >
> > > > Not sure it’s that simple in tcc4tccl but hope that helps.
> > > >
> > > >
> > > >
> > > > Best regards,
> > > >
> > > > Louis
> > > >
> > > >
> > > >
> > > > *From:* Tinycc-devel  > > > nextivityinc@nongnu.org> *On Behalf Of *Andy Goth
> > > > *Sent:* Monday, March 11, 2019 9:28 PM
>

Re: [Tinycc-devel] TCC crash with incorrect syntax in compound literal

[Michael Matz]

Hello,

On Sun, 17 Mar 2019, Pascal Cuoq wrote:

The attached patch makes the program above rejected without crash, does 
not seem to break “make test” (I think I know what it looks like when 
the tests are broken because my first fix did break them), and it makes 
the following program accepted too (and compiled to a binary that 
behaves as intended):


It might be close to the right fix.


It's not incorrect, but I chose to fix the problem differently on mob; 
sprinkling checks for wrong tokens here and there doesn't really fix the 
root cause: in presence of invalid source code we can't rely on the next 
token to determine if we have or haven't seen an initializer element 
already, we do need to track this explicitely.



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

Re: [Tinycc-devel] Undefined symbol '__ashldi3'

[Michael Matz]

m saying sounds alien to
> > the design of tcc, let me know so I can bug the tcc4tcl author instead.
> >
> >
> >
> > I tried hard to use gdb to debug dynamic loading, but it's proving to be a
> > nightmare in Windows. gdb is not showing me my arguments, it's claiming all
> > functions are defined in some unrelated C++ header file, and I had to find
> > and build debugbreak.c just to be able to Ctrl+C my process and get back to
> > the gdb prompt. And stdout isn't working for me either. So I'm really not
> > sure how to debug. Nevertheless, I do see that pe_add_runtime() is being
> > called, which in turn tries and fails to load libtcc1.a using
> > tcc_add_dll(). I wish I could inspect the arguments being passed to
> > tcc_add_file_internal(), but gdb is not cooperating, despite me compiling
> > everything with -ggdb3 and forgoing the strip stage of the Tcl build
> > process.
> >
> >
> >
> > On Fri, Mar 8, 2019, 08:04 Michael Matz  wrote:
> >
> > Hi,
> >
> > On Fri, 8 Mar 2019, Andy Goth wrote:
> >
> > > On Fri, Mar 8, 2019, 00:46 Andy Goth  wrote:
> > >
> > > > With tcc4tcl 0.30 (tcc 0.9.26) compiled with MXE GCC 5.4.0, I get the
> > > > following error:
> > > >
> > >
> > > I left out a critical detail. This is 32-bit Windows MXE GCC. I haven't
> > > tried 64-bit Windows yet, but it works fine in both 32- and 64-bit Linux.
> >
> > Yes, only 32bit code emits calls to this function, on both Windows and
> > Linux.  The function is defined in either libgcc.a or libtcc1.a which
> > TCC automatically should link against (either of them).  Somehow this is
> > not happening, I can't say why, you'll have to figure it out.
> >
> > Alternatively, if there are reasons why you don't link against libtcc1.a
> > or libgcc.a you will have to provide an implementation of this function
> > yourself, you could look into lib/libtcc1.c source for that.
> >
> > There are other helper functions that TCC might also generate calls for
> > in the i386 backend:
> >
> > __divdi3   long ret,x,y;  ret = x / y;
> > __udivdi3  ulong ret,x,y; ret = x / y;
> > __moddi3   long ret,x,y;  ret = x % y;
> > __umoddi3  ulong ret,x,y; ret = x % y;
> > __ashrdi3  long ret,x,y;  ret = x >> y;
> > __lshrdi3  ulong ret,x,y; ret = x >> y;
> > __floatundisf   ulong -> float
> > __floatundidf   ulong -> double
> > __floatundixf   ulong -> long double
> > __fixunssfdifloat -> ulong
> > __fixunsdfdidouble -> ulong
> > __fixunsxfdilong double -> ulong
> > __fixsfdi   float -> long
> > __fixdfdi   double -> long
> > __fixxfdi   long double -> long
> >
> > So it's probably easier to just figure out why libtcc1.a isn't linked
> > automatically with your program.
> >
> >
> > 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 mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] TCC segfault on Fedora 29 Klaus Ebbe Grue

[Michael Matz]

Hello,

On Mon, 4 Mar 2019, Connor Nolan wrote:

> It seems to be fixed now, but when running the created executable it 
> errors: "./test": error: Android 5.0 and later only support 
> position-independent executables (-fPIE). Does tinycc not support PIE, 

Right now TCC can't create position independend executables.  On x86-64 it 
shouldn't be too hard, as some support for shared libs is there, but 
nobody got to it.


Ciao,
Michael.

> and if not how on tell it does? Rerunning with -fPIE does not change 
> anything. The contents of test.c are:
> 
> #include 
> int main() {
>   printf("Hello World\n");
>   return 0;
> }
> 
> 
> 
> From: Tinycc-devel  
> on behalf of Connor Nolan 
> Sent: Sunday, March 3, 2019 5:37 PM
> To: tinycc-devel@nongnu.org
> Subject: Re: [Tinycc-devel] TCC segfault on Fedora 29 Klaus Ebbe Grue
> 
> This also happens when running it on Android. It works with -run, it doesn't 
> when compiling. This uses NDK r19's crt*.o files.
> 

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

Re: [Tinycc-devel] Undefined symbol '__ashldi3'

[Michael Matz]

Hi,

On Fri, 8 Mar 2019, Andy Goth wrote:

> On Fri, Mar 8, 2019, 00:46 Andy Goth  wrote:
> 
> > With tcc4tcl 0.30 (tcc 0.9.26) compiled with MXE GCC 5.4.0, I get the
> > following error:
> >
> 
> I left out a critical detail. This is 32-bit Windows MXE GCC. I haven't
> tried 64-bit Windows yet, but it works fine in both 32- and 64-bit Linux.

Yes, only 32bit code emits calls to this function, on both Windows and 
Linux.  The function is defined in either libgcc.a or libtcc1.a which 
TCC automatically should link against (either of them).  Somehow this is 
not happening, I can't say why, you'll have to figure it out.

Alternatively, if there are reasons why you don't link against libtcc1.a 
or libgcc.a you will have to provide an implementation of this function 
yourself, you could look into lib/libtcc1.c source for that.

There are other helper functions that TCC might also generate calls for
in the i386 backend:

__divdi3   long ret,x,y;  ret = x / y;
__udivdi3  ulong ret,x,y; ret = x / y;
__moddi3   long ret,x,y;  ret = x % y;
__umoddi3  ulong ret,x,y; ret = x % y;
__ashrdi3  long ret,x,y;  ret = x >> y;
__lshrdi3  ulong ret,x,y; ret = x >> y;
__floatundisf   ulong -> float
__floatundidf   ulong -> double
__floatundixf   ulong -> long double
__fixunssfdifloat -> ulong
__fixunsdfdidouble -> ulong
__fixunsxfdilong double -> ulong
__fixsfdi   float -> long
__fixdfdi   double -> long
__fixxfdi   long double -> long

So it's probably easier to just figure out why libtcc1.a isn't linked 
automatically with your program.


Ciao,
Michael.

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

Re: [Tinycc-devel] Use of uninitalized automatic variable in TCC when parsing “int f ( int ( )”

[Michael Matz]

Hello Pascal,

On Fri, 8 Mar 2019, Pascal Cuoq wrote:

> the simplest way to make this problem visible is to instrument the 
> functions type_decl and post_type:

Thanks for the report, fixed in mob.


Ciao,
Michael.

> 
> diff --git a/tccgen.c b/tccgen.c
> index 87ec798..7fa6c72 100644
> --- a/tccgen.c
> +++ b/tccgen.c
> @@ -4374,7 +4374,7 @@ static int post_type(CType *type, AttributeDef *ad, int 
> storage, int td)
>  Sym **plast, *s, *first;
>  AttributeDef ad1;
>  CType pt;
> -
> +n = 0xf00f0011;
>  if (tok == '(') {
>  /* function type, or recursive declarator (return if so) */
>  next();
> @@ -4410,6 +4410,7 @@ static int post_type(CType *type, AttributeDef *ad, int 
> storage, int td)
>  }
>  convert_parameter_type();
>  arg_size += (type_size(, ) + PTR_SIZE - 1) / 
> PTR_SIZE;
> +if (n == 0xf00f0011) printf("using n uninitialized\n");
>  s = sym_push(n | SYM_FIELD, , 0, 0);
>  *plast = s;
>  plast = >next;
> @@ -4583,7 +4584,7 @@ static CType *type_decl(CType *type, AttributeDef *ad, 
> int *v, int td)
> parse_attribute(ad);
> post = type_decl(type, ad, v, td);
> skip(')');
> -   }
> +   } else printf("*v left uninitialized\n");
>  } else if (tok >= TOK_IDENT && (td & TYPE_DIRECT)) {
> /* type identifier */
> *v = tok;
> 
> 
> The function post_type declares an automatic variable n and does not 
> initialize it. Setting it to 0xf00f0011 allows to see that it has not been 
> assigned when it is used later in this function (ored with SYM_FIELD and 
> passed as argument to the function sym_push). When “using n uninitialized” is 
> printed in the instrumented version of TCC, it means that n would have been 
> used uninitialized in the uninstrumented version of the compiler.
> 
> $ cat cr.i
> int f ( int (  )
> $ ./tcc cr.i
> *v left uninitialized
> using n uninitialized
> cr.i:2: error: ',' expected (got "")
> 
> Some inputs cause “*v left uninitialized” to be printed but not “using n 
> uninitialized”:
> 
> $ cat cr.i
> int f(void) { ( int (  )
> $ ./tcc cr.i
> *v left uninitialized
> cr.i:2: error: ')' expected (got "")
> 
> I have not found any syntactically correct input that caused “*v left 
> uninitialized” to be printed but not “using n uninitialized”, so a solution 
> *might* be to make TCC error out at the point where I made it print out “*v 
> left uninitialized”, but this is for someone with better understanding of the 
> code than me to decide.
> 
> Pascal
> 
> ___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Compiling to Bare Metal and to Unusual Targets ?

[Michael Matz]

Hi,

On Mon, 11 Mar 2019, Patrick wrote:

> I have a couple of experiments I want to run. I would like to compile a self
> hosted executable to run on a BeagleBone or Raspberry Pi without an OS.
> 
> I built with --enable-cross so I have a Linux to Arm tcc compiler installed.
> 
> Could I confirm,  I use:
> 
> --oformat,binary

-Wl,--oformat,binary, but yes, that will give you a binary blob without 
any file headers.  You might need to set -Wl,-Ttext to the correct address 
as well, and you need to remember to use -static for linking.

I haven't heard of anyone trying this on arm, so you might run into bugs.

> I also like Minix3. I haven't used it in quite a while but one thing I 
> didn't like was the complex build.sh, borrowed from NetBSD. You can 
> build the kernel and userland all in one go but it's hard to modify as 
> it's so huge and complex.
> 
> I was thinking that I would use the tcc compiler on Linux but I would 
> use the C libraries/system libraries from Minix. Both are i386 so I am 
> hoping that I will be able to build a cross compiler by simply adding 
> the right libraries and everything will just work. I realize that I will 
> have to build them before I link them.

Minix3 seems to use ELF as basic executable and library format, so that's 
one thing already.  But probably there are details that are different 
between Linux and Minix3 executables that need to be cared for, for 
instance the dynamic linker (if minix3 supports shared libraries) will be 
in a different place.

So most likely it won't be as simple as just pointing to the right headers 
and libraries to get a working result.

> I am a little mixed up, ./configure --help offers these options:
> 
> Is this how I include a path to an alternative set of headers?
> 
> "--sysincludepaths=...    specify system include paths, colon separated"
> 
> Is this how I add a path to an alternative set of shared objects or static
> archives? ?
> 
> "--libpaths=...   specify system library paths, colon separated"

Yes, but before doing that I'd try some experiments: when you add 
'-nostdinc -nostdlib' to you compile/link cmd lines TCC won't look into 
any standard paths for includes and link with no standard libraries, so 
you have everything under your control via -I and -L -lfoo 
options.  If you build a hello world with that you most probably will find 
that you can't just call the so produced executable under minix3.  That 
would need to be fixed first before using the above options makes sense.

> The following is for libraries already included in the tcc tarball right? If
> we wanted to compile to Minix or BSD, this is not going to help right?
> 
> "--config-uClibc,-musl,-mingw32... enable system specific configurations"

No, it's rather about how to integrate with different runtime 
environments like the dynamic linker and which features the C library 
provides.  Minix3 would be another such set, but depending on circumstance 
it's more like a new operating system, or more like a new runtime 
environment (the border is blurry between them).


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