Re: [Tinycc-devel] Do we want a BSD license for tinycc?
On 04/30/2013 02:14:58 PM, Marc Andre Tanner wrote: On Tue, Apr 30, 2013 at 03:40:43PM +0200, grischka wrote: ... and since I got permission from Fabrice to use his original tcc code under a BSD license ... Actually it's a long standing offer from Fabrice, also repeated lately on the occasion of the 0.9.26 release. I don't know about longstanding offer but I did ask him about it a year ago: http://landley.net/notes-2012.html#14-05-2012 Specifically I wanted to do a kickstarter to hire _him_ to glue tcc and tcg together, and asked him to name his price. He said he wasn't interested. The PS I didn't reproduce in that blog entry was (rummages in email...) Message-ID: 4fb0ccef.1040...@bellard.org Date: Mon, 14 May 2012 11:14:23 +0200 From: Fabrice Bellard fabr...@bellard.org To: Rob Landley r...@landley.net Subject: Re: Contract query: How much to glue tcg to tcc and update tccboot? Hi, I had the same idea when I was working on TCC and QEMU. The code generator of QEMU is not generic enough to do it, but at that time I began to modify it to handle the missing bits. Unfortunately it is a large project and I lost interest in it. Maybe someday I'll be interested again in compilers (perhaps to do a mix between C Javascript), but now I have other projects which have a higher priority, so I cannot help you now. Regarding the licensing, I'd like to change the TCC license to BSD since a long time, so I see no problem with that. I would have to look at my old repository to see from which version it is safer to start. Best regards, Fabrice. On 05/11/12 20:55, Rob Landley wrote: Hello Mr. Bellard, I'd like to run a kickstarter to hire you to: 1) Adapt qemu's Tiny Code Generator to work as the back-end for your old Tiny C Compiler, to create a new qcc (QEMU C Compiler) that can produce output for the various targets qemu supports. 2) Resurrect tccboot with the result, and get it to boot a current (3.x) kernel to a shell prompt. (Another modified subset is fine, as long as it boots to a shell prompt.) 3) Release the result under a BSD license. Does this sound doable? If so, how much would you charge (so I know how much to ask the kickstarter for), how long do you think it might take (ballpark), and when might you be available to start (if we can get you the money by then)? (I.E. it would take me a dozen fortnights, cost my weight in canadian 'toonie' coins, and the next open slot in my schedule is 37 years from now.) --- Optional details: My notes on this project, from when I tried to do it myself, are at: http://landley.net/code/tinycc/qcc/todo.txt I can maintain this after it works, I just don't know enough to make it work in the first place, and have been trying to find time to learn for years now but keep growing _other_ projects instead (toybox, aboriginal linux, I accidentally became linux-kernel Documentation maintainer...) I have no particular interest in the current no releases in 3 years tcc mob branch, and am just as happy for you to start with your old code if you prefer. If you want anything out of my old tcc fork, I hereby grant it to you under the same BSD license as tcc/tcg. It doesn't need multilib, being able to build arm-tcc and similar would be fine, and probably the common case given the need for libc, libtcc, crtbegin, and so on. (Being able to specify code generation with the same granularity as qemu's -cpu option would be nice, but not a huge deal in the absence of any real optimization.) Eventually I'd like to busyboxify tcc/qcc, I.E. make it so the front-end recognizes whether it's called as cc/cpp/ld/as/strip and reacts accordingly. But I can handle that part later, and make its command line parsing understand more gcc-isms if necessary. I wrote some notes about that years ago here: http://landley.net/code/tinycc/qcc/commands.txt I don't care about C++. The missing C99 bits from your old tccboot notes would be really nice, though. Simple dead code elimination would be really nice. (Busybox depends on it to avoid linker calls to undefined functions.) Just detecting if (0) constructs after constant propogation and suppressing output (or diverting output to a ram buffer that gets discarded) would be plenty. But if that sounds out of scope, I could probably tackle that after the fact too... Thanks for your time, Rob This was the first public statement from him I could find on the matter. (If he mentioned this before then, could you point me at where?) So the questions is: Do you people want, is it possible, what would it take - to change our tinycc code's license from LGPL to a BSD-like one (such as below). I am interested in a quality C compiler which
Re: [Tinycc-devel] Do we want a BSD license for tinycc?
On 04/30/2013 11:53:31 AM, Daniel Glöckner wrote: On Tue, Apr 30, 2013 at 05:43:03PM +0200, Thomas Preud'homme wrote: As I already said privately, I'm fine with BSD-2-clause. Does that mean you prefer it over the LGPL? http://www.youtube.com/watch?v=SGmtP5Lg_t0#t=15m10s What about you, grischka? Which one do you prefer? Why on earth would that matter? I identified a dozen people I have to talk to just to get a clean version of the code in _my_ fork. You guys have been doing a mob branch for years, with random drive-by commits from people you don't even know, who have zero ongoing relationship with the project. What makes you think you _can_ relicense your version? Rob ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Do we want a BSD license for tinycc?
On 04/30/2013 12:35:30 PM, Jared Maddox wrote: Date: Tue, 30 Apr 2013 16:03:43 +0200 From: Daniel Gl?ckner daniel...@gmx.net To: tinycc-devel@nongnu.org Subject: Re: [Tinycc-devel] Do we want a BSD license for tinycc? Message-ID: 20130430140343.ga14...@minime.bse Content-Type: text/plain; charset=us-ascii On Tue, Apr 30, 2013 at 03:40:43PM +0200, grischka wrote: So the questions is: Do you people want, is it possible, what would it take - to change our tinycc code's license from LGPL to a BSD-like one (such as below). Please discuss. I don't see anything good coming from a change from LGPL to BSD. It just encourages people to create private forks for binary-only releases. And I have yet to hear anyone complain on this list that they can't use TinyCC in their product because they can't link dynamically to the library. Daniel I actually agree with staying with LGPL, but there is something to bear in mind. While I don't think Apple would let an app with TCC onto the iPhone anyways, if they did then it would HAVE TO be statically linked. Be that as it may, static linking could be taken care of with a license exception. Android has an official No GPL in Userspace policy (which includes LGPL). A vendor who adds GPL software to their install image cannot use the Android trademark to describe the result. FYI, Rob ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Recent changes segfault on Linux ARM
On 04/26/2013 02:27:25 PM, James Lyon wrote: Hi, I don't have an ARM test system available but it is a new test... wget http://landley.net/aboriginal/bin/system-image-armv5l.tar.bz2 tar xvjf system-image-armv5l.tar.bz2 cd system-image-armv5l ./dev-environment.sh Now you do. (I also note that http://landley.net/qcc is my next todo project after toybox's 1.0 release, and since I got permission from Fabrice to use his original tcc code under a BSD license once I audit the third party contributions, I'm not going to be basing it on anything this project's done since then. *shrug*) Rob ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Allow configuration of tcc libraries search path
On 09/30/2011 05:50 PM, grischka wrote: Rob Landley wrote: There were a functions named g() and o() which were IMPOSSIBLE to grep for... Because you don't know how to use grep. Because I don't want to drop out of my text editor and grep from the command line, and doing the search as a regex isn't just space or tab before the function, you can have if(g()o()) and z=4+g() and there are such things as function pointers, spaces between the function name and the parentheses, function declarations cuddling the left edge of the screen so you may need to match start of line... The part I boggle at is that you honestly believe that single character global function names are a good idea, which scale to large codebases. This is one of many reasons why I think your technical judgement sucks. The existence of _workarounds_ does not make something a good idea. For the patches in question, I'm pretty sure he _specifically_ told me that he _didn't_ want colon separated search paths. I'm pretty sure we never talked about that or anything else such specific. My email archies from that time are on another machine, so I'll assume you're right and it was somebody else. But I changed the license because the zombie CVS tree was following me, and I didn't want to encourage it: You're faking history. The big gap between 0.9.23 (2005) and 0.9.24 (2008) was the period in which I started my tree. After I stopped my tree, tcc has gone two and a half years without a release. In june, this mailing list had a grand total of three messages, one of which was spam. When I started with my first commit 2007-10-30: http://cvs.savannah.gnu.org/viewvc/tinycc/tinycc/tccelf.c?revision=1.33view=markup http://repo.or.cz/w/tinycc.git/shortlog/2bcc187b1bbb6e3240400652af1a73cd799f250c you had already changed license (2007-10-29): http://landley.net/hg/tinycc/shortlog/492 I do a thing, you respond the next day, and you offer this as evidence that you _weren't_ responding to my actions? Ok... In fact I watched you fighting zombies (while turning the code into a broken mess of a battlefield) for quite some time until I decided that I want to preserve a tinycc that actually works. You've already established that you never understood what I was trying to do. You already told me this back in 2009: http://lists.nongnu.org/archive/html/tinycc-devel/2009-03/msg00026.html Fact is that there was a phase where we analyzed your fork and ripped as much as we were able to understand. This phase is over now and TinyCC is moving on. This thread restarted because yet another of the bits you failed to understand turns out, years later, to be relevant. Look: I don't care. Have the last word. Go about your business. TCC is no closer to building an unmodified linux kernel/busybox/uclibc today than it was when tccboot came out seven years ago. Your project, as maintained by you, will apparently never do those things, and is not _interested_ in doing those things, thus by my definition it is stalled and dead and uninteresting. Have fun with it. Rob ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Allow configuration of tcc libraries search path
work on windows stuff (and on getting gcc to build under it)... but it never added _up_ to anything. I started by collecting together various out of tree patches, and then poured hundreds of hours of my own effort into it, but nobody wanted to build on my work becaue it wasn't official. Instead a windows developer turned it into a windows-only project, and he has such a poor understanding of open source development that he doesn't even do code review or control access to the repository. Do you have any idea how WRONG that is? Alan Cox once told me A maintainer's job is to say no. And he's right: they're like the editor of a magazine, going through the slush pile to find the best bits, polish them up, stich them into a coherent next issue, publish, and repeat. This is not a new task, this is basic editorial judgement that people have been doing since Gutenberg invented the printing press. Publishing the raw slush pile is NOT INTERESTING. Fighting off Sturgeon's Law is what editors _do_. It doesn't matter if we're talking about the four levels of Linux developers (developer, maintainer, lieutenant, architect) bouncing back patches with comments, or Cannonical leaving 98% of sourceforge OFF their install CD, or sites like Slashdot and Fark publishing a tiny number of headlines from the thousands they get each day, or Google giving you a page of ten most interesting hits from an internet approaching a trillion pages of spam, porn, and emo blogs with cat pictures. Grischka has not set direction for the project, let alone goals. Where's the list of problems that need to be solved? Where's the and now we build package X announcements? Where's the RELEASE SCHEDULE? http://video.google.com/videoplay?docid=-5503858974016723264 This project is still unmaintained, it's just unmaintained by Grischka. The last release on tinycc.org was TWO AND A HALF YEARS AGO. Even uClibc never got quite that bad. Sometimes people need time to de-cvs'ify themselves and adopt good distributed vcs practices. I agree about somewhat funny current mob rules, but it would be a very pity again if that would be a blocker for cooperation. I do not trust Grischka's technical judgement, his committment to the project (I put way more time into my fork than he's put into the official version), his leadership abilities, or his organizational skills. I spent three years of my life improving this project (not just coding but documentation and testing and design and so on), and the result was esentially discarded at the whim of somebody who DIDN'T UNDERSTAND WHAT I WAS DOING. The fact the rest of you are now finally realizing that some of the problems I already solved years ago were, in fact, real issues, is mildly amusing to me in a morbid way. If you have competent developers on this lsit you don't NEED my patches, you can figure out how to do it from the _idea_ in a couple hours. If you need more details, I discussed the general idea somewhat at length at the OLS compiler BOF in 2008: http://free-electrons.com/pub/video/2008/ols/ols2008-rob-landley-linux-compiler.ogg I doubt my patches will remotely apply to the git codebase anyway, I changed a _lot_. Rob Seven packages. This is to replace binutils and gcc. FWL needs: ar as nm cc gcc make ld - Why gcc (shouldn't cc cover it? What builds?) - Need a make. Separate issue, busybox probably. Loot tinycc fork to provide: cc - front-end option parsing multiplexer (swiss-army-executable ala busybox) cross-prefix, so check last few chars: cc,ld,ar,as,nm Calls several automatically (assembler, compiler, linker) as necessary. Pass on linker options via -Wl, Merge in FWL wrapper stuff (ccwrap.c) call out again? distcc support? Path logic: compiler includes: ../qcc/include system includes: ../include compiler libraries: ../qcc/lib system libraries: ../lib tools: built-in (or shell out with same prefix via $PATH) command line stuff: current directory ld - linker #include elf.h which qemu already has. Support for .o, .a, .so - exe, .so Support for linker scripts ar - library archiver Busybox has partial support (still read-only?) ranlib? cc1 - compiler preprocessor (-E) support output (.c-.o) support as - assembler nm - needed to build something? binutils provides: ar as nm ld - already covered strip, ranlib, addr2line, size, objdump, objcopy - low hanging fruit readelf - uClibc has one strings - busybox provides one Probably not worth it: gprof - profiling support (optional) c++filt - C++ and Java, not C. windmc, dlltool - Windows only (why is it installed on Linux?) nlmconv - Novell Netware only (why is this installd on Linux?) QCC - QEMU C Compiler. Use QEMU's Tiny Code Generator as a backend for a compiler based on my old fork of Fabrice Bellard's tinycc project. Why? QEMU's TCG provides support for many different
Re: [Tinycc-devel] Is the CVS repository dead yet?
On Thursday 19 March 2009 10:30:53 Joshua Phillips wrote: Rob, I feel your pain :( I have had a look at the tcc git repository and it has many duplicated commits (rebased?) and is a complete and utter mess. Unfortunately, in my opinion, CVS (and SVN, too, because it is CVS done right) are just remote filesystems with an additional rollback feature. They are not worthy of the title SCM, imo. Linus Torvalds spends rather a lot of his google tech talk on git explaining why he despises CVS. Personally, I just have trouble _using_ the thing. The main things I use source control are 1) tracking what's changed, 2) tracking down a change (either binary searching for regressions or doing some kind of annotate to find a changeset with associated who did it and why info). CVS doesn't provide changesets. It tracks files individually. You can sort of retrofit the concept of changesets on top of it the way you can shoehorn long filenames on top of FAT's 8.3, but the result is even worse than vfat. (Trying to binary search through these not quite changesets is left as an exercise to the reader.) I think, if one wants to work on tcc (I don't, right now), one should completely fork it and ignore CVS and ignore *absolutely everything* to do with CVS, including other people trying to contribute to the project who insist on CVS. Seems a waste, but there doesn't seem to be an alternative :( Been there, done that. If someone puts your changes into CVS, ignore them. If someone asks you to pull from a git-cvs mirror, ignore them. Etc. If someone cuts a release from that CVS that has the tinycc.org domain name and gets covered by Linux Weekly News, the majority of which seems to be changes ported from your tree? (I changed the license on my tree to prevent that from happening _again_, but it still meant the semi-dead project had its first release in three years and would take another three years to get as stale again.) Grischka primarily seems to do Windows development, the PE backend. I don't do Windows development, but there's a whole bunch of users there. No matter what the actual compiler part is like, if the other version supports windows and mine doesn't the other one still has a reason to exist and be popular, and that will attract the attention of the Linux community to it. (They may not do much _development_, but their mailing list is the one that'll get the bug reports.) Even when they can't copy my code verbatim, it stimulates them to try, and do so badly. For example, supporting long long constant propogation http://landley.net/hg/tinycc/rev/2768f7c24156 should be ONE code path. If you want to make 64 bit long long support on 32 bit platforms a ./configure option that's one thing, but duplicating a large and complicated code path in the name of optimization is STUPID. It was the WRONG APPROACH. Similarly, I implemented -v -v -v to let you see what the compiler's search paths: the #include search path, and the linker search path, and what symbols the linker found while searching. http://landley.net/hg/tinycc/rev/d72f42753974 When tcc copied it, did they realize _why_ I did it? Or did they just export random debug statements that seemed like a good idea at the time with no obvious systematic purpose? (Three guesses.) By the way, did they ever come up with a correct fix to this one? I can't get a log of changesets to see for myself: http://landley.net/hg/tinycc/rev/c8a874736ed2 Has anybody but me ever tried to do any cleanup passes on this code? Things like: http://landley.net/hg/tinycc/rev/d8b3fa09ca5d http://landley.net/hg/tinycc/rev/9414324cc68a http://landley.net/hg/tinycc/rev/1f1a692f7563 http://landley.net/hg/tinycc/rev/7ddeaeed4e94 http://landley.net/hg/tinycc/rev/2d9e5cc32ea9 http://landley.net/hg/tinycc/rev/7fc19a001568 http://landley.net/hg/tinycc/rev/04ef85a39cf4 Yes, I occasionally broke stuff and had to fix it, but you can't grep for anything in tcc! Single character global variable/function names are a BAD THING. It needs to be FIXED. I was doing that, back before the 0.9.24 release rendered anything that _wasn't_ based off the 0.9.24 release (and never would be) obsolete and unofficial. Let alone breaking out option parsing into a separate file, moving the code generators into per-target subdirectories, creating tcc.h in the first place... Nobody's doing infrastructure work on this thing. Nobody's trying to build real packages with it and fixing the bugs. Nobody's filling in the missing C99 features like variable sized arrays. Nobody's worried about powerpc or mips support, or trying to come up with a libtcc.a for arm. (Lots of code refactoring to make multiple backends easy to do systematically. Notice how I was doing lots of code refactoring?) It's similar to the code refactoring to make tcc produce ld and strip and as commands in multicall binary fashion ala busybox. I suggested that would be a good
Re: [Tinycc-devel] Is the CVS repository dead yet?
On Friday 20 March 2009 10:46:47 grischka wrote: Grischka as well takes care of mirroring cvs on http://repo.or.cz/w/tinycc.git Ah, a mirror. So CVS is the official repository and git is just a mirror. Actually no. I'm using GIT for TinyCC ever since pre 0.9.24. There's no mention of it on tinycc.org. (There _is_ still a link to the CVS repository.) Where is it, by the way? It is just that I run a script from time to time that updates the CVS at Savannah from the master branch and also updates the cvs branch-label in the GIT. Why? Rob ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Is the CVS repository dead yet?
On Friday 20 March 2009 11:48:02 Rob Landley wrote: On Friday 20 March 2009 10:46:47 grischka wrote: Grischka as well takes care of mirroring cvs on http://repo.or.cz/w/tinycc.git Ah, a mirror. So CVS is the official repository and git is just a mirror. Actually no. I'm using GIT for TinyCC ever since pre 0.9.24. There's no mention of it on tinycc.org. (There _is_ still a link to the CVS repository.) Where is it, by the way? The first google hit for tcc git was http://packages.ubuntu.com/en/source/hardy/tcc (well, the nl language version of that page, anyway), and that links to: $ git clone git://git.roxor.cx/git/tcc.git/ Initialized empty Git repository in /home/landley/tinycc/tcc/.git/ git.roxor.cx[0: 194.50.78.214]: errno=Connection timed out fatal: unable to connect a socket (Connection timed out) Another hit is: http://www.mail-archive.com/frugalware-...@frugalware.org/msg25074.html Then there's some unintelligible links to something called github, a typo in some OCRed genetic code quoted in a PDF, and a link to the Tree Climbing Championships... Rob ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Is the CVS repository dead yet?
On Friday 20 March 2009 13:32:29 grischka wrote: - Original Message - From: Rob Landley r...@landley.net To: Joshua Phillips jp.sittingd...@gmail.com Cc: tinycc-devel@nongnu.org Sent: Friday, March 20, 2009 5:44 PM Subject: Re: [Tinycc-devel] Is the CVS repository dead yet? On Thursday 19 March 2009 10:30:53 Joshua Phillips wrote: Rob, I feel your pain :( I have had a look at the tcc git repository and it has many duplicated commits (rebased?) and is a complete and utter mess. I don't think it is an utter mess, in that sense. I mean, if occasional duplicate commits make someone feel bad they can just delete them from their personal repo. Similarly, I implemented -v -v -v to let you see what the compiler's search paths: the #include search path, and the linker search path, and what symbols the linker found while searching. http://landley.net/hg/tinycc/rev/d72f42753974 When tcc copied it, did they realize _why_ I did it? What makes you think other people don't know what they are doing? Not knowing what they're doing and partially copying a feature without realizing why the feature was added are two different things. (Mostly I just disagree with the design decisions.) And anyway why should other people have had the same reason why? After all your reason why must be seen in the context of a fork that is dead by now. Because I chose to stop working on it, yes. By the way, did they ever come up with a correct fix to this one? I can't get a log of changesets to see for myself: If not you then everyone else at least can at http://repo.or.cz/w/tinycc.git. Forgive me for not realizing that a repository that hasn't been updated for 3 and 1/2 months was the active one. I've downloaded it and am reading through it. Yes, I occasionally broke stuff and had to fix it, but you can't grep for anything in tcc! Single character global variable/function names are a BAD THING. It needs to be FIXED. I was doing that, back before the 0.9.24 release rendered anything that _wasn't_ based off the 0.9.24 release (and never would be) obsolete and unofficial. Actually everything essential from your fork went into the last release, Ok, one random example. The tcc ./configure still attempts to identify the host processor, and arbitrarily dies if you attempt to build on an armv5l or sh4 host. This is despite the fact that the host compiler #defines preprocessor variables for the target so at build time the C code can easily test what target you're building for without having to grovel around for it. So this is a) unnecessary, b) wrong. (And despite caring so much about what host you're building on, you still enable -run in cross compilers.) Don't get me started on the path logic rant (although that's old news here, but still not addressed): http://www.mail-archive.com/tinycc-devel@nongnu.org/msg01141.html http://landley.net/hg/tinycc/rev/510 http://landley.net/hg/tinycc/rev/511 except the array [restrict] fix as recently mentionned by someone on that list. You are welcome to push that on our mob branch, if you want to. Not if you're going to push it from there into CVS. And when I left off the array stuff was in progress. I forget what specifically was pending. (I remember it was leading up to implementing resizeable arrays properly with both sizeof() and for(;;) loops not leaking 'em, but it was a multi-step process and it's been a year.) Any formal changes however were recjected. There is absolutely no need to change variable names at this time. So single letter variable and function names which you can't actually grep for aren't considered a bad thing, then? The current source code does not need to be cleaned up or refactored, in your opinion? I blogged extensively about the worked I was doing, and the reasons for it: http://landley.net/notes-2007.html#28-12-2007 I didn't post it _here_ because A) the cvs archive was still official, B) this list's spam filter blocked me for a while in early 2007 and I fell out of the habit: http://landley.net/notes-2007.html#11-01-2007 As for a different file structure with subdirs, well, that may come, eventually. Not at this rate. I just wanted to have the 0.9.24 release with the same file structure as before because like that it is easier to see the real changes. That's all. The 0.9.24 release was in april of 2008. That was just about a year ago now. Anyway, of course we appreciate and thank you for the work you did. It is just that you work was filtered and reviewed one more time. I think that is a good thing after all. I'm all for the work being reviewed and filtered. I'll happily engage in design discussions to try to explain my thinking. It was the CVS is the only way thing. Let alone breaking out option parsing into a separate file, moving the code generators into per-target subdirectories, creating tcc.h in the first place... Nobody's doing
Re: [Tinycc-devel] Is the CVS repository dead yet?
On Wednesday 18 March 2009 15:10:32 Daniel Glöckner wrote: On Fri, Mar 13, 2009 at 05:05:09PM -0500, Rob Landley wrote: On Thursday 12 March 2009 16:20:28 Marc Andre Tanner wrote: grischka and Daniel you are the ones who actually committed code during the last few months, what do you think? I'm fine with whatever RCS is used. It's not like I touch the code on a daily basis.. I used to. I stopped _because_ of CVS. And as has been mentioned the last time this issue came up, one can easily keep a local git tree in sync with cvs. No, it's easy to mirror cvs to git, one way. You can't take branch merges and renames and stick them into CVS without losing a lot of information. (You can turn an egg into an omelette, kind of hard to go the other way.) I maintained a mercurial archive for over a year. Grischka copied the changes out of my archive and checked them into CVS, and then checked additional changes into CVS which were never posted to the list. A lot of which was windows stuff that I didn't even have a test environment for, some of which was fixes to bugs that had never been reported to the list, some of which was just noise but you had to look at the CVS commit to figure that out, and CVS won't give you a list of changesets. I stopped my development, development in CVS stopped. I started up again, CVS started up again. I lost count of how many times it happened (more than three). I will not publish another line of code for tinycc until CVS _dies_. Grischka put out the last release, therefore Grisckha is the maintainer. Grischka as well takes care of mirroring cvs on http://repo.or.cz/w/tinycc.git Ah, a mirror. So CVS is the official repository and git is just a mirror. Thanks for answering my question. Rob ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Re: Tinycc-devel Digest, Vol 71, Issue 4
On Sunday 15 March 2009 10:01:25 Joshua Phillips wrote: Rob said he's waiting for the CVS repository to be dead. Tcc isn't entirely dead. Merely pining for the fijords. The project is so healthy that my question about the status of the repository a _week_ ago has yet to receive an authoritative response. I got an email on Sunday from a professor with a post-doc who's planning to hook my abandoned tinycc fork up to the http://www.cminusminus.org/ backend. Basically asking if I would be available to answer questions about it (sure, I'm just not going to put much more time into it). Why use my fork? He explicitly said: I have no interest in dealing with the 'official' fork or with suffering any more CVS torture. We are currently using git, have used darcs, and probably could be persuaded to try Hg on the grounds that it would be good for our educations. I feel _bad_ about this. Keep in mind, my fork was publicly abandoned six months ago, and I'm still getting email about it. These two are planning to dive in and refactor the code so it talks to a code generation backend through a documented interface. That's really cool! That's what we need to hook up TCG from QEMU, and suddenly have support for arm, cris, i386, m68k (well, coldfire), mips, mips64, ppc, ppc64, sh4, sparc, and x86-64. Plus several different variants of each one (For example, arm supports armv4, armv5, armv6, armv7, each both little and big endian). If they do nothing but _document_ the existing interface, that's a big plus. It would make _sense_ for knowledgeable, energetic people like that to be able to use the official version and contribute back to it. I myself could turn tcc into a swiss army knife executable (ala busybox, which I maintained for a year and a half) over a weekend, the way I mentioned in my previous message to this list. There's work this project desperately needs, and has needed for years now, which isn't getting done. But the official version is CVS, and having to work with CVS is like having to do development under DOS. It was already a bad idea in the 1990's, now it's just crazy. I am not the only person driven away from this project by the boat anchor of CVS around its neck, but until CVS stops being the official repository that releases will be cut from (and at this point I won't trust that zombie's dead until that respository GOES AWAY), tcc is dead to me. Rob ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Re: TinyCC CVS, Rob's fork, the future (was: [PATCH 5/5] Fix gv for long longs)
On Sunday 07 September 2008 12:50:58 Daniel Glöckner wrote: Today I wrote a shell script that parses the output of cvs log and generates a diff for every commit. It prepends the log message and a list of affected files. There were 47 commits after your automated import to Mercurial. If one day you feel like syncing your fork, you can use the attached script or just use the tar ball of the diffs at http://www.stud.uni-hannover.de/~daniel/tcc/tcccvs-20060220-20080907.tar.bz 2 (I can only guarantee for this homepage to exist for the next two months.) The thing is, I'm tired of stopgaps. I could roll the boulder up the hill one more time, but I've synced my fork multiple times, and it just falls out of sync again. I'm tired of maintaining _a_fork_. I'm tired of my gut response to other people's checkins being dread (ala darn it, more work for me to reverse engineer this) rather than happiness that the project has been made better. And I'm really tired of banging on a project nobody else cares about. However intermittent, this is the mailing list where the users and other developers are. There were once valuable contributors here (you, grischka, David Wheeler) doing things I either don't know how to do or will probably never get around to doing. Plus there are still almost twice as many bug reports posted here than get emailed to me directly. (Add in the various distro bugzilla variants I've checked for tcc bug reports and this list falls to below half of the bug reports I find, although not by much.) But those other developers have chosen CVS. And given a choice between dealing with CVS and not working on the project at all, it's no contest. CVS and hobby do not show up in the same sentence for me. It's a question of KILLING OFF THE CVS ARCHIVE, which will never happen. Well, Savannah does have Subversion, Git, and Mercurial. If we bug the right people, the repository might get converted. I'm all for converting savannah to mercurial. I happily vote in favor of this if anybody's taking votes. I do not, however, have the authority to do this thing, and never have. Fabrice's original new maintainer call was in terms of CVS access: http://lists.gnu.org/archive/html/tinycc-devel/2006-09/msg00024.html Almost immediately, he explicitly dismissed a change of source control type as being important: http://lists.gnu.org/archive/html/tinycc-devel/2006-09/msg00058.html I stopped particularly expecting a move off CVS to ever happen back in February 2007, after I cc'd Fabrice on this email: Rob Landley wrote: On Wednesday 21 February 2007 1:56 pm, Geert Janssen wrote: Dear Rob, Are you the tcc maintainer? Dunno. Ask Fabrice. I maintain my own mercurial repository, which I converted from the CVS repository back on October 7th (at which point CVS hadn't been touched since February). I've applied a couple dozen patches to it since then, and have at least a dozen more todo items I should make time for. However, on October 16th and 18th, Fabrice showed up after a long absence and committed some stuff to the old CVS repository (in both cases, variants of patches I think I'd already committed to my repository, the -E thing and stuff from Dave Dodge's patch list), which took most of the wind out of my sails. This put my mercurial repository in an awkward position, as a clearly unofficial branch. If Fabrice showed any desire to take an interest in the project again, I wasn't going to stand in his way, so I stopped actively working on my version at that point. Went on to focus on other things (toybox and firmware linux, mostly). However, it's now been about 4 months since Fabrice's last commit, and he hasn't even tried to catch up with my tree. I'm still not puting much time into it, and I really haven't properly come up to speed on most of the tcc internals, but I've been bookmarking various tcc patches as I find them and I'm slowly working my way through the backlog. So all I can say right now is I maintain _my_ version. I merge patches and try to respond to bug reports. I'm not planning a release (unless somebody really wants one), I have several other demands on my time, I really don't understand the internals of the program half as well as I'd like, and I haven't currently got the three solid months to dedicate to coming up to speed to my satisfaction. I doubt this answers your question. I think I'm maintaining a fork. If so, I stumbled on some problems too. Sure, I'm all ears. tcc had trouble with the struct tags being used at nested scope levels. Do you have a code snippet that can reproduce the problem? Also, I have a program that compiles and runs fine on multiple architectures but with tcc is simply hangs. Again, got something I can reproduce? (If I can reproduce it, I'll at least _try_ to fix it, if somebody reminds me often enough. :) A couple weeks back somebody sent me
Re: [Tinycc-devel] [PATCH 5/5] Fix gv for long longs
On Saturday 06 September 2008 05:41:21 KHMan wrote: Laurens Simonis wrote: You could also use bzr, which can also easily import cvs repo's, and even still be a server for read-only cvs access, for those who still want that. Check out the CVS section on http://bazaar-vcs.org/BzrMigration My preference for hg is a personal preference, I also use git for projects that use that, and I even use subversion for a few projects that I'm not active enough on to bother creating a mercurial mirror. Those are the top three source control systems these days (and really the only three worth looking at), and the only reason to look at svn is because Savannah already supports it and can convert your cvs repository into it (the way the qemu project went from cvs-svn) just by asking the admins to do so. I note that the subversion developers themselves don't recommend subversion for new open source projects. They recommend a distributed source control system like git or mercurial. Instead, they continue to develop subversion for enterprise use, because closed-source development projects strongly prefer to be centralized so they can limit access to the code. One of the subversion developers themselves wrote a nice summary about it here: http://blog.red-bean.com/sussman/?p=90 That said, I can work with subversion. Busybox, uClibc, and qemu are all still using subversion for legacy reasons. (Yeah, they're behind the times, but not _crippingly_ so. Still using CVS in 2008 is like still using the 8.3 single case filename limit of DOS. There's no excuse for it, it's a symptom that the project was already dead) A distributed mercurial/git approach has advantages, but it can't _prevent_ people from checking stuff into (and cutting releases from) the old cvs archive. Which is what will continue to happen if anybody else does anything interesting, and thus nobody else will do anything interesting for long unless they have the stomach to synchronize their work with a cvs archive. I suppose git is the most popular. Here's a goggle tech talk where Linus Torvalds explains why he created git: http://www.youtube.com/watch?v=4XpnKHJAok8 We do have a sorta 'parallel' repository on Mercurial (hg) on ShareSource. Detlef is in charge, IIRC. But we haven't heard much of the hg repo on this list. I see mostly grischka running the show. Using bzr or git won't solve anything. We'd still need someone who is 'actively' in charge of the proceedings. Anybody can set up a modern distributed source control system. I set up my own mercurial mirror of the tcc cvs back in 2006, which is how my fork started in the first place. Unfortunately the tool I used to do it with (tailor I think) was based on some python cvs library or some such that stopped working when I upgraded to Ubuntu 6.06. If I tried to deal with a cvs archive with more than 255 entries, it truncated the commit list. So when I moved off of Hoary Hedgehog, CVS support got left behind. And nobody ever fixed the cvs package the converter depended on, because nobody cares about CVS anymore. (Heck, even subversion use is rapidly declining in the open source world. Booming in the enterprise market, though.) Meanwhile, people kept checking new commits directly into CVS, without putting them on the mailing list, and I got tired of fishing them out. Our priority should not be revision control systems. Our problem is that we need two or three active devs can act on patches and discussions quickly, to provide that semblance of movement. Once upon a time I was doing that. And I'd put some effort into the project, and in response everything I did got copied into the CVS repository and them more changes got checked directly into CVS. This happened three times before I took steps to prevent it from ever happening again. That's why I changed the license on my fork. I'd have no trouble granting LGPLv2 on my tinycc copyrights again, except that if I did that it'd all get sucked into CVS and then working on sheer momentum another half dozen changes would get checked in on top of that... And I'd wander off again and the project would grind to a halt yet again. It's pretty darn cyclical, and I'm tired of it. If we have that, RCS issues will seem much less pressing. I think those interested and able to review patches should lobby to get cvs credentials. I'm pretty sure I'm not the only person who has zero interest in working on cvs. Otherwise, my complaints wouldn't be _interesting_, because of the flood of other developers willing do it instead. How many patches have been posted here over the years with no follow-up? We need what any good novel has -- movement, or action to the effect that it creates the perception that the show is trundling along at a brisk clip. My fork got up a good head of steam three times (and I was taking other people's patches), and then the cvs started up again and I walked
Re: [Tinycc-devel] [PATCH 5/5] Fix gv for long longs
On Friday 05 September 2008 14:08:48 Daniel Glöckner wrote: At this point I would like to remind those who pick up the patches that there are two other mails by me with uncommitted fixes: http://lists.gnu.org/archive/html/tinycc-devel/2003-10/msg00044.html http://lists.gnu.org/archive/html/tinycc-devel/2008-08/msg7.html Well, I'm no longer picking up patches. When the 0.9.24 release came out, I pretty much lost interest in my fork. My objection all along has been that CVS is not a real source control system, and no modern project should be burdened with it. CVS doesn't even understand changesets. You were kind enough to post your patches to the list: if they went directly into CVS (as Grischka does, although he only really seems to care about the windows target), I couldn't see what files got touched in what groups, because CVS simply wasn't designed to track that information. I can't even go how many changes were checked into the project in the month of August, because cvs thinks about individual files, and doesn't understand that a project is made up of ore than one, or that the same change can touch more than one file. (According to http://cvs.savannah.gnu.org/viewvc/tinycc/?root=tinycc the project hasn't had a checkin in four months, although that's just a guess from looking down the list at the age field of EVERY DARN FILE), including the windows subdirectory. I have an enormous todo list for tinycc. No modern compiler can be relevant without generating x86-64 code, but there are simpler and more fundamental things it needs just as badly. For example, I wanted to redo the command line parsing logic to work like busybox: call it like ld and it understands linker arguments, call it like as and it jumps straight to the inline assembler. It can easily work as strip, and it would be easy enough to grab the uClibc code for readelf and ldd and whip up an nm and objdump and ar... (And if you do all that, adding support for -Wl,--dynamic-linker,/blah becomes trivial. And without doing that, adding support for that is an amazingly ugly hack.) All that's not actually very hard, I've done it before and most of the code is already there. But before I touch tinycc again, I need to deal with the fact that my fork isn't based on 0.9.24. There are changes in CVS that I need to look at to make what I'm working on relevant again, but that involves dealing with CVS. And it wouldn't be the last time. And I just haven't been able to bring myself to care. If this project decides to move off of CVS, let me know. But it's 2008, CVS is dead, and I've run out of the patience necromancy requires. Daniel Rob ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Using TinyCC with GPL
On Sunday 15 June 2008 22:36:48 KHMan wrote: Ivo is right. Please read Yann Renard's original post again. Ah, I thought he was talking about libtcc.h instead of tcclib.h. (I found those names _deeply_ confusing and renamed them both. In my version the code generation library header is libtinycc.h and the script #include is include/tinyinc.h. Takes a bit more work to confuse 'em.) No, hang on, he _was_ talking about the script #include: I'm thinking of using Tiny CC to include C as a scripting language for a software I'm currently working on. But I'm not a licence expert, so I got in licence consideration. Using TinyCC as a scripting lanquage will most probably use of the tcclib.h. I mean the script code uses the tcclib.h. As TinyCC is GPL, should the created scripts become GPL also ? I just checked it in the repository and tcclib.h is the one you #include from the script to avoid needing stdio.h and friends. libtcc.h is the one you #include to use the code generator. (Just triple-checked to be sure, because I honestly can't keep 'em straight.) Either way, if he's linking gpl code into his app, obviously the gpl applies. If he's just calling a gpl executable, it doesn't affect his script any more than using bash (GPL) to run a shell script would make the shell script GPL. Including a header to make use of a documented API doesn't make his script GPL; all the symbols it exports are all standard symbols (C99 in this case). The only thing we could possibly copyright is their selection and organization, and the file has a comment inviting them to add their own and users don't care what order they occur in inside the header, so that's actually pretty clear from a derived work standpoint. Please correct me if I am wrong. I'm not sure you are, but I'm not interested in pursuing the thread. (I haven't been paying close attention to this list, just saw my name mentioned. Wouldn't have replied otherwise.) I'll wander off again... Rob -- One of my most productive days was throwing away 1000 lines of code. - Ken Thompson. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] TCC as portable module compiler
On Tuesday 18 March 2008 09:44:14 Basile STARYNKEVITCH wrote: Kenneth Forsbäck wrote: Damn, there goes my bright idea... People wanting a portable module compiler (if I understand what that should be) should very much consider using LLVM http://llvm.org/ since it is portable (targetting several machines) and able to generate code and of course free software (MIT-like license). Also llvm is rather well documented, and alive (much more than tinycc, which seems almost dead). Actually, I use tcc to refer to the project in the old CVS and tinycc to refer to the new one I'm doing at http://landley.net/code/tinycc;. And by that metric, tinycc is doing just fine, thanks. I released 1.0.0-pre2 last week and I'm aiming for a -pre3 in April (before the cross compiling tutorial I'm giving at CELF) and then a -pre4 in July (before the compiler BOF I'm hosting at OLS). Most of the agenda going forward is mentioned in http://landley.net/code/tinycc/todo.txt If you're just looking for gcc alternatives, the pcc project just had a 0.9.9 release and both OpenBSD and NetBSD aim to switch over when it's ready: http://lwn.net/Articles/28/ http://pcc.ludd.ltu.se/ LLVM with clang is another one, that's loosely backed by Apple. http://clang.llvm.org/ Those might someday be able to build the Linux kernel. Intel's ICC is the only compiler other than gcc that's already built a current unmodified Linux kernel, but that's A) closed source, B) only supports Intel targets. http://www.intel.com/cd/software/products/asmo-na/eng/compilers/clin/277618.htm I say current and unmodified there because tccboot built a 2.4 kernel (not 2.6), building only a subset of the full kernel sources, and it was a modified subset to work around constructs that tcc didn't understand. (I plan to revive tccboot with tinycc, but first I'd like to get tinycc to build a User Mode Linux kernel that works.) But, all these other compilers are only tangentially on topic here (as a brief mention for comparison purposes)... Rob -- One of my most productive days was throwing away 1000 lines of code. - Ken Thompson. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Release Candidate - please test
On Monday 10 March 2008 13:11:32 grischka wrote: Well, then maybe OS X uses a different object format and TCC needs a new linker backend in order to work with it. Yes, it's called mach-o, it's got four interesting flavors (x86, x86-64 for Leopard, PPC-32, and arm for the iPhone), and it's been on my to-do list since the middle off last year. This should get you started: http://en.wikipedia.org/wiki/Mach-O http://0xfe.blogspot.com/2006/03/how-os-x-executes-applications.html I never could get darwin booted under qemu (keyboard controller didn't work) but now that qemu can run actual MacosX I need to give it another try. (This is assuming I don't break down and get an iPhone. :) Rob -- One of my most productive days was throwing away 1000 lines of code. - Ken Thompson. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] TCC built using NOSTDLIB crashes on linux
On Thursday 31 January 2008 21:23:49 KHMan wrote: Mike wrote: I was trying to compile TCC using the -nostdlib option. (Here's my command (which works)) bash$ gcc -nostdlib -o tcc tcc.c /usr/lib/crt1.o /usr/lib/crti.o -ldl -lc -lgcc bash$ (Here's my result (which is a crash)) bash$ ./tcc qwert Segmentation fault (core dumped) bash$ Do you get this same error? What's the cause? (My system specs are Ubuntu 7.10, gcc 4.1.3) Time out. I think you should adjust your expectations a little bit. We are just a community list, and tcc has a severe lack of developer resources. I don't think the list should be in the business of providing tech support. People who dare to jump in and try out tcc must at least have a fair bit of self-sufficiency. Perhaps you can help us by diagnosing the problem (you can build it, so would you like to try some debugging?) and give us a useful lead so that one of the active developers on this list can issue a patch with the minimum of fuss. You can also try Rob Landley's fork and see if the same issue appears. My build system's totally different, but I'm happy to help him with his issue. (I don't post much on a list I was asked to leave, but as long as my name's come up anyway...) Did you try building a hello world program with that command line, to see if _that_ segfaults? Rob -- One of my most productive days was throwing away 1000 lines of code. - Ken Thompson. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Buiding binutils 2.17 (needs dynamic arrays).
On Thursday 04 October 2007 3:08:49 pm Simon 'corecode' Schubert wrote: Actually I think you should send your grumpy comments to yourself and leave this list (alone). *shrug* Ok. Bye. Rob -- One of my most productive days was throwing away 1000 lines of code. - Ken Thompson. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Re: patches for libtcc
On Thursday 04 October 2007 8:51:20 pm Rob Landley wrote: I had this window open to reply to, but I was uninvited from the project and have stopped working on it now. If you want to talk to somebody about it, there's always the mailing list... Rob Sorry, didn't mean for that to go to the list. :( Rob -- One of my most productive days was throwing away 1000 lines of code. - Ken Thompson. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Buiding binutils 2.17 (needs dynamic arrays).
On Wednesday 03 October 2007 12:07:21 am Antti-Juhani Kaijanaho wrote:
On Tue, Oct 02, 2007 at 12:19:18PM -0500, Rob Landley wrote:
Any opinions on how to tackle this one?
No. But I'll summarise (NOT quote) the C99 rules, in case it's helpful.
Feel free to ask questions :)
The C99 term is variable length array (VLA).
Is it? I thought it was a gcc extension. Ok...
Searching through my copy of the c99 draft for variable length array...
Ah, fun, I forgot about initializing char [] = fruitbasket; so [] is valid
and _that_ already uses n=-1, so I need to set n=-2 for variable length array
to indicate pop something off the stack to get this value. Right...
Why is it using recursion here? It does mean the symbols are pushed last to
first, but why is that important? (The length value pushed onto the stack is
done first to last, because it happens before the recursion. That's unlikely
to work. Right now it hits an error() in that case, but that's just a
placeholder...)
Sigh...
6.5.3.4 #7 applies sizeof() to a variable length array, and yup it's got to
calculate this at runtime. Suckage...
Argh! And you can do char thing[a][b]; too, and take sizeof(thing)...
int a[*] (the asterisk is literal) is allowed in parameter declarations
in function prototypes but not in function definitions. The array is a
VLA and its length is unknown.
What does the asterisk is literal here mean? I'm familiar with int blah[]
= {1,2,3}; but if I stick a * between the [] I get:
temp.c:5: warning: GCC does not yet properly implement ‘[*]’ array declarators
And if gcc 4.x doesn't implement it, no Linux program anywhere uses it.
The expression inside [ ] in a variable (or typedef) declaration needs
not be a constant expression. If it is not constant, then the array is
a VLA. If the VLA declaration defines a function parameter in a
prototype, the effect is the same as if the expression had been replaced by
asterisk.
The effect being that even gcc doesn't support it, so I shouldn't worry about
it? (I don't really care what the standard says, I care about what actual
programs do.)
When testing array types for compatibility, array sizes are compared
only if both are present and constant.
If a typedef includes VLA types (for example, typedef int foo[n], where
n is not a constant), then the non-constant size expressions are
evaluated when the typedef declaration is encountered during execution.
Thus the size of a VLA typedef is fixed while the typedef name is in
scope. The standard gives an example in 6.7.7:8:
Where the heck would N come from here, variable length arrays can't have
static storage duration, they can only be automatic (I.E. local) variables...
EXAMPLE 5 If a typedef name denotes a variable length array type, the
length of the array is fixed at the time the typedef name is defined,
not each time it is used:
void copyt(int n)
{
typedef int B[n]; // B is n ints, n evaluated now
n += 1;
B a; // a is n ints, n without += 1
int b[n]; // a and b are different sizes
for (int i = 1; i n; i++)
a[i-1] = b[i];
}
That's sick and evil and pointless. What the heck is the point of a typedef
with local scope??? Use int B already. I might start caring about that
case if I run into real software that does that, but until then the standards
body seems to be hallucinating another edge case. (Support for this might
fall out naturally from the existing tcc typedef handling, but if it doesn't
throwing an error upon encountering that construct is fine by me. I'll
accept a patch but not come up with one on my own...)
A VLA cannot be initialized explicitly.
Currently only [] arrays can be. Even if I say 'char blah[42]=abc;' gcc
tells me [*] is unimplemented.
When a local VLA variable is declared, the non-constant size expressions
are evaluated at that time.
And thrown on the stack using a hidden symbol? Yeah, I can see that. (Kind
of what I was thinking of doing, I just have to keep multi-level arrays in
mind here. Wheee...)
VLAs are not allowed as struct and union members.
Good!
Only local variables may be VLA variables.
Yup, I'd noticed that one.
It is not allowed to jump over a VLA declaration by goto, switch or
setjmp-longjmp. The compiler must diagnose violations of this by goto
and switch.
You know, with tcc being a one-pass compiler, there's a certain amount of suck
in that statement. I'll have to think about it...
Size expressions of VLA parameters are evaluated when the function is
called.
How would that work? (Do you have an example here?)
I'm still somewhat confused by VLA parameters. The expression would almost
have to consist of globals, unless you mean:
int blah(char a, char b[a]) {
thingy();
}
except I thought
Re: [Tinycc-devel] Buiding binutils 2.17 (needs dynamic arrays).
On Wednesday 03 October 2007 12:10:17 am Antti-Juhani Kaijanaho wrote:
On Tue, Oct 02, 2007 at 06:26:58PM -0500, Rob Landley wrote:
Confirmed that gcc makes sizeof() a runtime function in this case:
#include stdio.h
int main(int argc, char *argv[])
{
int walrus[atoi(argv[1])];
printf(%d\n, sizeof(walrus));
return 0;
}
Running ./a.out 42 produced 168.
Oh yeah, that's gonna be fun...
As far as I can tell, it's supposed to be implemented as the equivalent of:
size_t walrus_sizeof = atoi(argv[1]);
int walrus[walrus_sizeof];
printf(%d\n, walrus_sizeof);
return 0;
Obviously, walrus_sizeof should not actually be named in such a way but
to be a fresh compiler-generated name.
A hidden internal symbol. Right, that's doable.
For right now, I just want to implement enough to make the binutils build
happy, and worry about the corner cases as I hit software that uses them.
Considering that this is one of the blocking issues for building an
unmodified Linux kernel, I suspect there are more corner cases to come, but
for now...
Thanks for the analysis. Now I have to figure out more existing tcc
infrastructure...
It wouldn't be so bad if there were more comments, and if they weren't so...
Well... Example.
/* Parse a type declaration (except basic type), and return the type
in 'type'. 'td' is a bitmask indicating which kind of type decl is
expected. 'type' should contain the basic type. 'ad' is the
attribute definition of the basic type. It can be modified by
type_decl().
*/
static void type_decl(CType *type, AttributeDef *ad, int *v, int td)
It can be modified? Which it? type? ad? Both? What are the side effects?
(I notice that this calls stuff that pushes stuff onto the symbol stack, but
the comment just mentions the return value...) Yeah, I think I've figured it
out now, but the comment was surprisingly little help...
Rob
P.S. I'm still boggling you can do int a[42], b(char *c); But apparently,
yes you can. Unfortunately, in tcc you can _also_ do:
int blah(char a)(char b);
And it happily takes it. (I note that gcc has a specific error for this. Of
course gcc has a specific error for everything.)
Sigh. So... many... corner... cases...!
--
One of my most productive days was throwing away 1000 lines of code.
- Ken Thompson.
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Buiding binutils 2.17 (needs dynamic arrays).
On Wednesday 03 October 2007 2:24:23 am Antti-Juhani Kaijanaho wrote:
On Wed, Oct 03, 2007 at 01:59:47AM -0500, Rob Landley wrote:
int a[*] (the asterisk is literal) is allowed in parameter declarations
in function prototypes but not in function definitions. The array is a
VLA and its length is unknown.
What does the asterisk is literal here mean?
That I'm not using it as a footnote marker or whatever :) I mean that
there actually is an asterisk between the brackets.
I'm familiar with int blah[]
= {1,2,3}; but if I stick a * between the [] I get:
temp.c:5: warning: GCC does not yet properly implement ‘[*]’ array
declarators
[*] is only allowed in parameter declarations anyway, and even there
only in function declarations (not definitions).
For example:
int foo(size_t, int [*]);
...
int foo(size_t n, int arr[n])
{
...
}
The former is a valid declaration of the latter function. The asterisk
just says that the array is a VLA, not a normal array (which you could
declare as int []).
And if gcc 4.x doesn't implement it, no Linux program anywhere uses it.
True :)
A VLA cannot be initialized explicitly.
Currently only [] arrays can be. Even if I say 'char blah[42]=abc;'
gcc tells me [*] is unimplemented.
Um, char blah[42] = abc should work in GCC too.
Indeed, it does:
You're right, I had another line in there it was compaining about.
It is not allowed to jump over a VLA declaration by goto, switch or
setjmp-longjmp. The compiler must diagnose violations of this by goto
and switch.
You know, with tcc being a one-pass compiler, there's a certain amount of
suck in that statement. I'll have to think about it...
Correction: What is not allowed is jumping from outside a VLA's scope to
inside its scope. You may jump in the other direction :)
If you jump inside its scope you must initialize it (call alloca). Sounds
like you can't jump over the initialization.
I think you just need to keep a list of all gotos with targets you haven't
seen yet,
Yes, to implement goto.
and if that's nonempty at a VLA declaration, yell.
No, they could be jumping entirely past the block with the VLA in it. When
declaring a new label inside a VLA, mark it hot somehow, and any attempt to
use that target from a goto that's either before the declaration or which
occurs after the end of the block, error() out. (Note that according to c99,
the declaration doesn't have to be at the start of the block, and due to the
non constant size calculation, this unfortunately matters...)
(Similar for
switches.) Bah, that doesn't handle the following scenario:
int n = 42;
{
int a[n];
...
foo:
...
}
...
goto foo;
I guess you need to also keep a list of all labels in the scope of a VLA
declaration (with an associated list of those declarations).
You only need to keep track of this from the label perspective, and then when
using those labels to resolve a goto, determine whether or not it's ok.
Something similar is needed for dead code elimination of blocks anyway. A
label can switch one of those back _on_. (Which isn't implemented yet but
which is a todo item of mine and can still be done in a single pass if you
conditinally output the block to a temporary buffer and then either dump the
whole thing to cur_text_section or discard it when you reach the end.)
Size expressions of VLA parameters are evaluated when the function is
called.
How would that work? (Do you have an example here?)
I'm still somewhat confused by VLA parameters. The expression would
almost have to consist of globals, unless you mean:
int blah(char a, char b[a]) {
thingy();
}
THat's what I mean, yes.
except I thought the order of evaluation of function parameters wasn't
guaranteed, and does that mean char b[a] gets declared before char[a]
does?
No, declaration is left-to-right, which means that any parameters
defined before a parameter are in scope when that parameter is being
defined. Still the function *arguments* (the epressions in the call
site) are evaluated in an unspecified order.
Consider the following code fragment:
int foo(size_t n, int arr[n++])
{
...
}
In the absence of code I care about actually doing this, I'm not even going to
try to support that. Just use int *arr and copy the darn thing with alloca()
if you need to. This is getting _way_ too fancy at the language level...
...
foo(k-1, kraah+1)
So what happens is, when the call is executed:
k-1 and kraah+1 are evaluated in an unspecified order
the result of k-1 is assigned to the paramerter n, and the result of
kraah+1 is assigned to the parameter arr
n++ (the size expression) is evaluated
the function body is executed
as far as I can tell.
kraah+1 resolves to a pointer, that should be what gets passed on the stack,
and if the function wants to copy if the function can copy
Re: [Tinycc-devel] Buiding binutils 2.17 (needs dynamic arrays).
On Wednesday 03 October 2007 7:49:53 am Daniel Glöckner wrote:
On Wed, Oct 03, 2007 at 01:59:47AM -0500, Rob Landley wrote:
It boils down to a funky call to alloca()...
One thing to note is that memory for VLAs is freed when the block ends.
GCC does this by saving the stack pointer before allocating the VLA and
restoring it at the end of the block.
This approach doesn't work if we mix VLAs with alloca.
#include stdlib.h
void f(char *,char *);
void g(int n)
{
while(n--) {
char p[n];
char *q=alloca(n*7);
f(p,q);
}
}
void h(int n)
{
while(n--) {
char *q=alloca(n*7);
f(q,q);
}
}
In g GCC will free the alloca'ed memory at the end of each iteration while
in h it will free the memory at the end of the function.
Does that strike anybody else as an enormous non-obvious side effect?
I thought alloca() memory died at the end of the current block anyway. Here
you're saying you can't _guarnatee_ it'll survive beyond the end of the
current block, you might as well treat it as if it does...
The GCC approach has the benefit that it won't force you to have 0,5TB of
memory if one calls
void e(int n) {
while(n--) {
char p[n];
f(p,p);
}
}
If you need to use gcc, you know where to find it. If you want to improve
alloca(), patches welcome.
Otherwise:
void e(int n) {
char p[n];
while(n--) {
f(p,p);
}
}
Rob
--
One of my most productive days was throwing away 1000 lines of code.
- Ken Thompson.
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Buiding binutils 2.17 (needs dynamic arrays).
On Wednesday 03 October 2007 2:28:17 am Antti-Juhani Kaijanaho wrote: On Wed, Oct 03, 2007 at 02:12:27AM -0500, Rob Landley wrote: P.S. I'm still boggling you can do int a[42], b(char *c); But apparently, yes you can. Sure you can. Of course, I wouldn't allow any of my students write stuff like that :) Unfortunately, in tcc you can _also_ do: int blah(char a)(char b); And it happily takes it. (I note that gcc has a specific error for this. Of course gcc has a specific error for everything.) That's, I *think* declaring a function that returns a function. Yes, there should be an error message :) I can't see what case needs post_type() to recurse after a function declaration. After an array, yes. Considering that array of function pointer syntax is: int (*wubba[42])(char *a); That's still not a valid postfix on a function declaration... This doesn't solve int *wubba[42](char *a) ... Ok, I redid the code in that area, split post_type() into two new functions, and checked in the result... Sigh. So... many... corner... cases...! The standard is useful in that it tells you how to handle (most) of them :) The draft standard I have is 1.5 megabytes of ascii text (ok, html) that reads like it was written by lawyers. I use it to break ties, not as an implementation guide. The reason nobody's apparently noticed that tcc doesn't complain about a function returning a function before is because when you feed it legal code it works. Making it complain properly when fed illegal code is a luxury, which I'll implement if it doesn't bloat it too much. Either way, you feed it bad code, you get bad behavior. An error message is just more easily diagnosed bad behavior. Rob -- One of my most productive days was throwing away 1000 lines of code. - Ken Thompson. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Buiding binutils 2.17 (needs dynamic arrays).
On Wednesday 03 October 2007 10:30:12 pm Antti-Juhani Kaijanaho wrote:
On Wed, Oct 03, 2007 at 05:17:23PM -0500, Rob Landley wrote:
If you jump inside its scope you must initialize it (call alloca).
I'm a little worried about the use alloca thing you have here (in
general, not just this particular quote). alloca has all sorts of nasty
problems, which is a reason why it's not in the standard and VLAs are.
Of course, it's just a worry, I don't have a specific objection.
Just allocate the array from the stack. Decreasing ESP by the size and
then using the resulting ESP as the array start pointer ought to work,
as far as I can see. Not having looked at the tcc code I'd assume
that's what tcc does when allocating auto variables in any case.
I need to look into the local variable allocation code some more no matter
what I do...
Soundsw like you can't jump over the initialization.
Yes, I believe that's the intent.
BTW, are you aware of the C99 rationale document? It explains why
some stuff is in the standard and why some other stuff is not, and why
the stuff that is in there is the way it is.
http://www.open-std.org/jtc1/sc22/wg14/www/C99RationaleV5.10.pdf
No, I'd never heard of it. Opened now, but it's 200+ pages and not something
I'm likely to finish reading today. :)
int foo(size_t n, int arr[n++])
{
...
}
In the absence of code I care about actually doing this, I'm not even
going to try to support that. Just use int *arr and copy the darn thing
with alloca() if you need to. This is getting _way_ too fancy at the
language level...
alloca is not portable, VLAs (theoretically) are.
I meant that there is some alloca() code in tcc right now, and I might be able
to turn the VLA allocation into a call to the alloca() that's there right
now. (Or there might be a better way to do it, but this is an area of the
code I'm not familiar with. There's no shortage of those.)
not portable is a strange argument to make when talking about how tcc
chooses to call other bits of tcc, internally...
But I agree, not
supporting everything is not a problem, as long as the compiler doesn't
assign non-standard semantics for the stuff.
kraah+1 resolves to a pointer, that should be what gets passed on the
stack,
That *is* what gets passed. The VLA degenerates to a pointer like any
other array parameter.
So why the heck are they allocating space for it in the function definition?
The contents of that pointer then get copied into the new local variable?
and if the function wants to copy if the function can copy it.
Yes.
Darn silly to try to make the language do this. This is C, not python...
I believe the appropriate comparison in this case is This is C, not
Fortran. VLAs (like _Complex) has a significant (potential) user base
in the scientific computing community.
I don't think I've encountered a package that tries to use _Complex yet, and
I'd expect that to live in the C library anyway. (The standard may say
otherwise, but so what?)
Rob
--
One of my most productive days was throwing away 1000 lines of code.
- Ken Thompson.
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Segmentation fault compiling jslong.c
On Tuesday 18 September 2007 11:17:17 am Sanghyeon Seo wrote: Hi, I'm trying to get Spidermonkey built on TCC, which didn't go well. How to reproduce: wget http://ftp.mozilla.org/pub/mozilla.org/js/js-1.60.tar.gz tar zxf js-1.60.tar.gz cd js/src make -f Makefile.ref CC=tcc Ok, I think I've fixed the last of this now. This package compiled to the end for me with tcc. I don't know if the result works, but the test suite checks out... Rob -- One of my most productive days was throwing away 1000 lines of code. - Ken Thompson. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
[Tinycc-devel] Buiding binutils 2.17 (needs dynamic arrays).
So if I do:
tar xvjf binutils-2.17.tar.bz2
cd binutils-2.17
CC=tcc ./configure --disable-nls --disable-shared --disable-multilib \
--program-prefix=withtcc-
make
So it dies with:
tcc -c -DHAVE_CONFIG_H -g -I. -I.././libiberty/../include -Wc++-compat \
.././libiberty/cp-demangle.c -o cp-demangle.o
.././libiberty/cp-demangle.c:3825: constant expression expected
And the offending line is:
cplus_demangle_init_info (mangled, options, len, di);
{
#ifdef CP_DYNAMIC_ARRAYS
__extension__ struct demangle_component comps[di.num_comps];
^^^ that one
__extension__ struct demangle_component *subs[di.num_subs];
I.E. it's dying due to lack of dynamic arrays.
We have alloca() now, so in the compiler can implement this as something
vaguely like:
struct demangle_component *__hidden_comps_ptr = \
alloca(sizeof(struct demangle_component)*di.num_comps);
#define comps (*__hidden_comps_ptr);
Except that sizeof(comps) will return sizeof(struct demangle_component *)
instead of the size passed to alloca().
Any opinions on how to tackle this one?
Rob
--
One of my most productive days was throwing away 1000 lines of code.
- Ken Thompson.
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Buiding binutils 2.17 (needs dynamic arrays).
On Tuesday 02 October 2007 12:19:18 pm Rob Landley wrote:
Any opinions on how to tackle this one?
Confirmed that gcc makes sizeof() a runtime function in this case:
#include stdio.h
int main(int argc, char *argv[])
{
int walrus[atoi(argv[1])];
printf(%d\n, sizeof(walrus));
return 0;
}
Running ./a.out 42 produced 168.
Oh yeah, that's gonna be fun...
Rob
--
One of my most productive days was throwing away 1000 lines of code.
- Ken Thompson.
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] tcc_free is still used in tccpe.c and tcccoff.c
On Tuesday 02 October 2007 8:57:36 pm Hanzac Chen wrote: Hi, I found that tcc_free is removed but still used in these two files ... Bye ... Ah, sorry. Just committed a fix. I'm trying to implement dynamic arrays before cutting a release. It's making my brain hurt... Rob -- One of my most productive days was throwing away 1000 lines of code. - Ken Thompson. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Re: Please comment this patch, if you have the time.
On Sunday 30 September 2007 2:13:37 pm Jakob Eriksson wrote:
Anybody else understand what this is doing?
By the way, this is (almost) the patch Rob was referring to.
regards,
Jakob
And here's what I told him at the time:
On Tuesday 25 September 2007 3:54:23 pm Jakob Eriksson wrote:
diff -r a62ad123624a arm-gen.c
--- a/arm-gen.c Sat Sep 22 04:39:52 2007 -0500
+++ b/arm-gen.c Tue Sep 25 22:40:44 2007 +0200
@@ -1695,6 +1695,37 @@ void ggoto(void)
vtop--;
}
+int gen_0x850f(int ind)
+{
+ o(0x1A00 | encbranch(ind, 0, 1));
+
+ return ind;
+}
What's 0x850f? Seems a somewhat non-informative name for a function.
+int target_len(void)
+{
+ return
+#ifdef TCC_ARM_EABI
+ 8
+#else
+ 4
+#endif
+ ;
+}
Oh wow that's ugly. Why have a function for this instead of a global variable
or a #define?
+int tcc_define_symbols_platform(TCCState *s)
+{
+ tcc_define_symbol(s, __ARM_ARCH_4__, NULL);
+ tcc_define_symbol(s, __arm_elf__, NULL);
+ tcc_define_symbol(s, __arm_elf, NULL);
+ tcc_define_symbol(s, arm_elf, NULL);
+ tcc_define_symbol(s, __arm__, NULL);
+ tcc_define_symbol(s, __arm, NULL);
+ tcc_define_symbol(s, arm, NULL);
+ tcc_define_symbol(s, __APCS_32__, NULL);
+}
Hmmm, not a bad idea. Might be better to have a structure we can iterate over
in a loop instead. (Are any of these platform symbols ever defined to
something other than NULL?)
/* end of ARM code generator */
/*/
diff -r a62ad123624a i386/i386-asm.c
--- a/i386/i386-asm.c Sat Sep 22 04:39:52 2007 -0500
+++ b/i386/i386-asm.c Tue Sep 25 22:42:02 2007 +0200
@@ -1207,3 +1207,9 @@ static void asm_clobber(uint8_t *clobber
}
clobber_regs[reg] = 1;
}
+
+int gen_0x850f(int ind)
+{
+ return psym(0x850f, 0);
+}
Again, is there a better name for this?
diff -r a62ad123624a i386/i386-gen.c
--- a/i386/i386-gen.c Sat Sep 22 04:39:52 2007 -0500
+++ b/i386/i386-gen.c Tue Sep 25 22:42:09 2007 +0200
@@ -1018,6 +1018,24 @@ void gen_bounded_ptr_deref(void)
put_extern_sym(sym, NULL, 0, 0);
rel-r_info = ELF32_R_INFO(sym-c, ELF32_R_TYPE(rel-r_info));
}
+
+void inline pop_fp_r (int r)
+{
+ if (TREG_ST0 == r) {
+ o(0xd9dd); /* fstp %st(1) */
+ }
+}
*shrug* ok...
+int target_len(void)
+{
+ return 4;
+}
Could still be a global variable.
+int tcc_define_symbols_platform(TCCState *s)
+{
+ tcc_define_symbol(s, __i386__, NULL);
+}
+
#endif
So arm has 8 symbols, i386 has one. Ok...
/* end of X86 code generator */
diff -r a62ad123624a tcc.c
--- a/tcc.c Sat Sep 22 04:39:52 2007 -0500
+++ b/tcc.c Tue Sep 25 22:43:29 2007 +0200
@@ -3756,12 +3756,9 @@ void save_reg(int r)
sv.r = VT_LOCAL | VT_LVAL;
sv.c.ul = loc;
store(r, sv);
-#ifdef TCC_TARGET_I386
- /* x86 specific: need to pop fp register ST0 if saved */
- if (r == TREG_ST0) {
- o(0xd9dd); /* fstp %st(1) */
- }
-#endif
+
+ pop_fp_r (r);
+
I didn't see a stub for pop_fp_r() in the arm patch, nor does this call seem
to be inside the bounds checker only...
/* special long long case */
if ((type-t VT_BTYPE) == VT_LLONG) {
sv.c.ul += 4;
@@ -4197,12 +4194,9 @@ void vpop(void)
{
int v;
v = vtop-r VT_VALMASK;
-#ifdef TCC_TARGET_I386
- /* for x86, we need to pop the FP stack */
- if (v == TREG_ST0 !nocode_wanted) {
- o(0xd9dd); /* fstp %st(1) */
- } else
-#endif
+ if (!nocode_wanted) {
+ pop_fp_r (v);
+ }
You dropped an else.
Also, the other pop_fp_r call wasn't nocode_wanted? (Not a complaint, I see
that you're leaving the current context alone. I'm trying to figure out
where the nocode_wanted stuff kicks in, actually. There's declaration of
symbols, there's evaluation of constants, and there's generation of code.
Possibly some of this could be reorganized at a higher level...)
if (v == VT_JMP || v == VT_JMPI) {
/* need to put correct jump if or || without test */
gsym(vtop-c.ul);
@@ -4449,16 +4443,7 @@ void gen_opl(int op)
if (a == 0) {
b = gtst(0, 0);
} else {
-#if defined(TCC_TARGET_I386)
- b = psym(0x850f, 0);
-#elif defined(TCC_TARGET_ARM)
- b = ind;
- o(0x1A00 | encbranch(ind, 0, 1));
-#elif defined(TCC_TARGET_C67)
- error(not implemented);
-#else
-#error not supported
-#endif
+ b = gen_0x850f (ind);
I take it c67 won't build until it gets a stub for this?
}
}
/* compare low. Always unsigned */
@@ -5141,17 +5126,7 @@ static int type_size(CType *type, int *a
*a = LDOUBLE_ALIGN;
[Tinycc-devel] Re: Please comment this patch, if you have the time.
On Tuesday 25 September 2007 3:54:23 pm Jakob Eriksson wrote:
+int gen_0x850f(int ind)
+{
+ o(0x1A00 | encbranch(ind, 0, 1));
+
+ return ind;
+}
Getting back to that's a horrible name for this proposed function...
Let's see, according to http://sandpile.org/ia32 the opcode 0x85 is TEST
Eb,Gb and 0x0f is the prefix to indicate a two byte opcode follows. At a
guess the function name indicates an x86 test and jump.
Except that the function _contents_ start by sticking 0x1a at the start of it,
which is SBB Gb, Eb and I have no _IDEA_ what that means, but google
probably will... http://en.wikipedia.org/wiki/X86_assembly_language
says subtraction with borrow. Ok...
Anybody else understand what this is doing?
Rob
--
One of my most productive days was throwing away 1000 lines of code.
- Ken Thompson.
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] __GNUC__ and GLIBC header mess
On Saturday 29 September 2007 6:14:59 am Antti-Juhani Kaijanaho wrote: On Fri, Sep 28, 2007 at 02:59:29PM -0500, Rob Landley wrote: Does the c99 spec say that undefined is 2? (Probably, I'm a bit rushed just now, and likely to be out of touch this weekend. Visiting grandparents.) In #if directives, undefined identifiers get replaced with zeros. (see C99 6.10.1:3) Ok, this is very definitely a glibc bug then. Not ours. __GNUC__ 2 triggers when __GNUC__ isn't defined, and that's wrong here. Rob -- One of my most productive days was throwing away 1000 lines of code. - Ken Thompson. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] [PATCH] GNU __attribute__ extension handling with parenthesis
On Friday 28 September 2007 5:15:56 am Jakob Eriksson wrote: Marc Andre Tanner wrote: However it seems that they haven't yet made it to the repository. I am wondering why those peoples don't sent the patches to the mailing list in the first place. What do you all think? Should we start doing that, it could get really noisy though. I think I can live with the noise of patches posted to a development mailing list. :) Rob -- One of my most productive days was throwing away 1000 lines of code. - Ken Thompson. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] [PATCH] Parentheses handling within struct/union initialization
On Friday 28 September 2007 11:47:09 am Marc Andre Tanner wrote: The following can't be compiled, tcc complains: ',' expected. I've bumped into a few of those. I also don't think I ever got around to fixing: char blah[] = (thingy); Which is the result of using the gnu _(ugh) internationalization macros... I've bookmarked this but probably won't have time to look at it before monday... Rob -- One of my most productive days was throwing away 1000 lines of code. - Ken Thompson. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] [PATCH] GNU __attribute__ extension handling with parenthesis
On Wednesday 26 September 2007 1:06:17 pm Marc Andre Tanner wrote: cat bug.c EOF void warn ( const char * format , ... ) __attribute__ ( ( format ( printf , ( 1 ) , ( 2 ) ) ) ) ; EOF I did a smaller version of this patch. Close enough? Yep works, unsurprisingly since it is essentially the same. Thanks for committing. Thanks for helping me debug this thing. I'm pondering cutting another release, I'm just not sure where a good dividing line is. No more known bugs isn't likely to happen any time soon, and I have so many pending patches to look through at this point I'm fairly certain I'm going to forget some when I go back to apply them. (The tiny amount of time I've stolen to work on this has focused on tracking down bugs I have a test case for, not applying cleanups despite the serious need for them...) Marc Rob -- One of my most productive days was throwing away 1000 lines of code. - Ken Thompson. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Segmentation fault compiling jslong.c
On Thursday 27 September 2007 7:01:29 pm Rob Landley wrote: Anyway, bug #1 should be fixed, bug #3 I'm working on, and afterwards I can tackle bug #2 and _then_ you should be able to compile jslong.c. :) I _think_ I just got bug #3 fixed. My brain is kind of fried right now though, (and I have a looming day job deadline), so #2 has to wait a bit... Rob -- One of my most productive days was throwing away 1000 lines of code. - Ken Thompson. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] [BUG] Nested array/struct/union initialization problem
On Tuesday 25 September 2007 11:37:01 am Marc Andre Tanner wrote:
Hi,
Okay this is currently way too complicated for me to solve on my own.
The follwoing code sniped demonstrates the issue. Tcc exits with:
bug.c:13: identifier expected
The call to expect comes from within unary () at tcc.c:6587 where t = '.'
Um, yes. Evil.
struct format_option {
union {
const char * fo_str ;
int fo_int ;
int fo_time ;
} ;
unsigned int empty : 1 ;
enum { FO_STR , FO_INT , FO_TIME } type ;
char ch ;
} ;
static struct format_option track_fopts [ 11 ] = {
{ { . fo_str = ( ( void * ) 0 ) } , 0 , FO_STR , 'a' } ,
{ { . fo_str = ( ( void * ) 0 ) } , 0 , FO_STR , 'l' } ,
{ { . fo_int = 0 } , 0 , FO_INT , 'D' } ,
{ { . fo_int = 0 } , 0 , FO_INT , 'n' } ,
{ { . fo_str = ( ( void * ) 0 ) } , 0 , FO_STR , 't' } ,
{ { . fo_str = ( ( void * ) 0 ) } , 0 , FO_STR , 'y' } ,
{ { . fo_str = ( ( void * ) 0 ) } , 0 , FO_STR , 'g' } ,
{ { . fo_time = 0 } , 0 , FO_TIME , 'd' } ,
{ { . fo_str = ( ( void * ) 0 ) } , 0 , FO_STR , 'f' } ,
{ { . fo_str = ( ( void * ) 0 ) } , 0 , FO_STR , 'F' } ,
{ { . fo_str = ( ( void * ) 0 ) } , 0 , 0 , 0 }
} ;
Would be great if someone could take a look at it.
That would probably be me. :)
I currently have about 5 tcc issues backlogged (including your ' in #warning
thing), and didn't give tcc any time this weekend because I was backlogged on
day job stuff (linux-kernel documentation, http://kernel.org/doc/master.html
is finally starting to shape up and http://kernel.org/doc/ols/2004 is at
least no longer _blank_, if not as detailed as the first half of
http://kernel.org/doc/ols/2002 ...)
Anyway, the first thing I'd do is try to pare the test case down to something
smaller. The bug thingy is implying it's dying on the _first_ of the 11
assignments, so the others could theoretically go away and still reproduce
the bug.
I'm currently looking at unary() for one of the other issues (the segfault
when generating code in a global before the first function in a file, due to
const_wanted and nocode_wanted both being ignored and code being generated
anyway, and if you trace down from expr_lor_const() and see how _many_
different places code generation is called from, it's not surprising that a
lot aren't guarded.
I suspect the easy way to fix this is for nocode_wanted to just swap
cur_text_section to point to a dummy output section, and then either discard
the result or check if anything was generated and barf if it was illegal for
it to do so. Then all the nocode_wanted tests can go away. Might waste a
little ram at runtime, but it does that anyway, and something like that gives
us the possibility of doing dead code elimination for if(0) intelligently yet
revert to outputting code after the fact if there's a jump target label in
there... :)
Thanks,
Marc
Rob
--
One of my most productive days was throwing away 1000 lines of code.
- Ken Thompson.
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] [PATCH] Preprocessor: ignore everything after #error or #warning
On Wednesday 26 September 2007 2:52:27 am Dave Dodge wrote: On Wed, Sep 26, 2007 at 01:23:32AM -0500, Rob Landley wrote: Hmmm... What about #warning as last line of the file with no newline at the end of the line? FWIW, the grammar for most preprocessing directives explicitly includes a newline. gcc accepts a #warning with no newline but emits an additional warning about the missing newline. I was more worried about next() falling off the end of the file and either segfaulting or looping endlessly... Rob -- One of my most productive days was throwing away 1000 lines of code. - Ken Thompson. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Segmentation fault compiling jslong.c
On Friday 21 September 2007 6:36:57 pm Dave Dodge wrote: On Fri, Sep 21, 2007 at 06:04:01PM -0500, Rob Landley wrote: I have a draft of the spec itself, in html format. BTW (this has probably been mentioned before) n1124 is a newer freely-available draft, which is closer to the C99 final than n869 (which is what I assume your HTML version is based on). The downside is that n1124 only comes in PDF format. I still go to n869 first myself since I can search/browse it in a text editor. Where would I find info on the legal status of these drafts? I'd love to mirror both versions on kernel.org/doc but not if I can't nail down that the terms are... Rob -- One of my most productive days was throwing away 1000 lines of code. - Ken Thompson. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] New fun bug! #include regex.h
On Friday 21 September 2007 11:12:18 pm Antti-Juhani Kaijanaho wrote: I get identical results for the following from gcc 4.1 and gcc 3.1: $ tcc -E temp.c | gcc -xc - stdin:301: error: ‘restrict’ undeclared here (not in a function) For some reason, I can't reproduce this here (there is no restrict in the tcc output in my machine), but it doesn't matter. You probably have a different glibc version that's producing different headers. I'm using the ones that came with Ubuntu 7.04. You're asking gcc to compile the code as C90 with GNU extensions. No wonder it barfs about restrict, as it is a C99 thing! Try with -std=c99. *shrug* Either way I applied a patch to ignore it which fixed the problem I actually saw. Rob -- One of my most productive days was throwing away 1000 lines of code. - Ken Thompson. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] New fun bug! #include regex.h
On Friday 21 September 2007 4:58:37 am Antti-Juhani Kaijanaho wrote: On Fri, Sep 21, 2007 at 10:02:19AM +0200, Marc Andre Tanner wrote: Rob Landley wrote: tcc knows how to handle restrict when it's applied in other contexts, but in this context it seems to make about as much sense as int array[long]; According to the comment in sys/cdefs.h this is valid C99 don't know whether this is true or not. /* ISO C99 also allows to declare arrays as non-overlapping. The syntax is array_name[restrict] GCC 3.1 supports this. */ All type qualifiers and static are allowed there. The syntax is: Really? I get identical results for the following from gcc 4.1 and gcc 3.1: $ tcc -E temp.c | gcc -xc - stdin:301: error: ‘restrict’ undeclared here (not in a function) Note that temp.c is one line: #include regex.h This is why my checkin called it a bug workaround. In the absence of gcc version symbols, the glibc headers a resolving to something that gcc can't parse either. Rob -- One of my most productive days was throwing away 1000 lines of code. - Ken Thompson. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Segmentation fault compiling jslong.c
On Friday 21 September 2007 8:41:58 am Gregg Reynolds wrote: Seriously. It is a reference book on C written to complement KR and has been used as such since the first edition in the eighties (predating the standard). Rob, you'd probably find it well worth the money. In particular it discusses the differences between the different versions of C, so if you want to support pre-C99 code you'll probably find it indispensable. I have a draft of the spec itself, in html format. I build some code, it breaks, I figure out why. (Or somebody else reports to me that _they_ build some code, it breaks, I reproduce it and figure out why.) When I run out of stuff to do on that front, I'll let you know. don't remember ever hearing anyone refer to projection, so when you refer to it as a vital theoretical concept and imply that this name is commonly used for it, I tend to stop paying attention to the rest of the paragraph... Always a good reading strategy. Using the absence of something over a 17 year period, and a corresponding lack of recent change in the subject matter, to judge that it can't possibly be as important as they're attempting to imply? Yeah, I'd consider that a viable classification strategy. Why risk learning something when you've got real work to do? ;) Why do you assume you have something to teach me? What is this guy blathering about? != I cannot comprehend his brilliance. FYI. The long version: I always have this reaction to ungrounded theory. It comes from three attempts at a master's in computer science running into ivory tower academics who are trying to do things like teach their 30 years of research into parallel algorithms, which turnsout not to have anything to do with SMP but a theoretical machine with an infinite number of processors advancing their clocks in lockstep and able to read and write from memory simultaneously without any propogation delay, so you can avoid ever having to lock by counting the number of instructions and timing everything carefully. The fact such a machine is physically impossible to build in a universe where the speed of light is a limiting factor in signal popagation never entered into it, they were still teaching this in 1996. Or the guy who was trying to mathematically prove the correctness of a specific implementation of the Java 1.0 compiler (by porting it to a Lisp dialect and then having a team of multiple people spend five years on it, by which time Java 1.2 was out, I'd seen several systems die in the field due to bad memory or a dodgy power supply in ways that presented as software problems, I'd had to abandon a Java project because Java 1.0 didn't have any way to truncate an existing file which had _nothing_ to do with the assumptions matching the implementation...) I am an engineer, not a mathematician, and a pragmatist rather than an idealist. The difference between theory and practice is that in theory there is no difference, in practice there is. I've developed an allergy to ivory towers for this reason: go too deep into the theory without grounding it in something useful and it just stops being interesting. I don't care what pure theory says because I've seen reality disagree too much. I dig into complexity to look for the simple behind it, or else to find a nasty corner case I can't avoid dealing with. I'm only interested in a complex solution if there's some concrete _advantage_ over a simple solution that outweighs the cost of the complexity, and that extends to the analytical models used in the design. The short version: Start climbing an ivory tower, I stop listening. Seriously, I didn't mean to sound pedantic. I should have added the caveat that I'm trying to find clear language for expressing C semantics, *shrug* I'm weird, I'll admit it. You managed to hit some of my hot buttons by accident. As for trying to find clear language, neither the c89 or c99 specs, nor the C FAQ resulting from literally decades of discussion on comp.lang.c, have managed to do this already? http://www.faqs.org/faqs/C-faq/faq/ I think it's possible to do this, if one is willing to jettison the traditional metalanguage used to discuss C, but it's a work in progress and not to everyone's taste. If the result sounds like a lecture, well, I'll have to be more careful. There is a difference between what I'm capable of understanding, and what I consider important. I did get an english minor (Rutgers, '95). I have in fact _had_ courses on etymology and the history of the english language and so on. The result is that I'm waiting for gonna to become an official contraction of going to, am happy that we're now allowed to boldly split infinitives that no man hath split before (thanks be to star trek, yea verily alelujiah amen and gesundheit), and even voluntarily use ain't from time to time. Gotta know the rules before you can break 'em. :) Go back far enough and
Re: [Tinycc-devel] New fun bug! #include regex.h
On Friday 21 September 2007 3:02:19 am Marc Andre Tanner wrote: Rob Landley wrote: On Thursday 20 September 2007 4:00:33 pm Marc Andre Tanner wrote: And since recent tcc sets __STDC_VERSION__ to 199901L __restrict_arr is defined as restrict which causes the problem because tcc doesn't know how to handle this. gcc doesn't know how to handle this either. If I save the tcc -E output and then feed it to gcc, gcc dies at the exact same point with an equivalent error. Yes, but if you run gcc -E this results in: regmatch_t __pmatch[__restrict] That's because if you do this: $ tcc -D__GNUC__=4 -E temp.c | grep pmatch regmatch_t __pmatch [ ] , See the problem? The headers change behavior when they think it's GCC. According to the comment in sys/cdefs.h this is valid C99 don't know whether this is true or not. /* ISO C99 also allows to declare arrays as non-overlapping. The syntax is array_name[restrict] GCC 3.1 supports this. */ Since gcc 3.4 and 4.1 both barf on that, I suspect the comment is wrong. However, unless we want to selectively pretend to be gcc, we have to work around bugs in things that have never been tested against anything that _didn't_ at least pretend to be gcc. Rob -- One of my most productive days was throwing away 1000 lines of code. - Ken Thompson. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Segmentation fault compiling jslong.c
On Thursday 20 September 2007 7:32:09 am Gregg Reynolds wrote: On 9/20/07, Rob Landley [EMAIL PROTECTED] wrote: The constant propagation thing is relatively straightforward, the int thingy=printf(); thing I'm not 100% sure about, is that allowed in c99? I know c++ has constructors that run before main() does, can you do something equivalent in C? I note that gcc complains initializer is not constant for the attempt to initialize a global with int thingy=printf();, so I'm guessing it's _not_ allowed. But I'd appreciate somebody more familiar with the expected behavior here to pipe up, if they can... According to Harbison and Steele, initialization of a static or extern int requires a constant expression. Ok. Automatic and register vars can be initialized with any expression. Both of which can only be local variables. Vars with no explicit storage class default to extern, which implies static. (5th ed., 4.6.1) extern implies static? Hang on, so if I say extern int thingy; in a header, and declare a global int thingy; in a .c file, I can't use that thingy in another .c file that #includes that header? I'm fairly certain that's not the case. I think you have to say static if you want something to be, you know, static. However, I thought static and extern were diametrically opposed. We may be talking about something different here... The c99 draft says All the expressions in an initializer for an object that has static storage duration shall be constant expressions or string literals. (6.7.8, constraint 4). So static storage duration != static keyword applied to a global, limiting its scope to the current file? Who named these? Right, ok, can only initialize globals with constants. Check. I need to add a new error() case and a return somewhere, and _then_ fix the darn constant propogation for 64-bit shifts... -gregg Rob -- One of my most productive days was throwing away 1000 lines of code. - Ken Thompson. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Is there any more stabler release of TCC?
On Friday 14 September 2007 9:35:05 pm ShangHongzhang 62185 wrote: Hi, all Recently I want use TCC as a source code scanner for my project, so Im only concern with the part of semantic analysis. In this case, which release is more suitabler for me? any suggestion will be very appreciated. Thanks. The most recent version of my mercurial tree at http://landley.net/code/hg is the best one I know about. You can grab a tarball of the source from the links at the top of the page (zip, bzip2 or gzip format). I have some things to merge into it this weekend, and after that I'll probably cut a release on general principles. Maybe early next week. Rob -- One of my most productive days was throwing away 1000 lines of code. - Ken Thompson. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Local procedures
On Thursday 13 September 2007 4:49:04 am Bernhard Fischer wrote: busybox trunk, find's parse_params() has a nested function alloc_action(). I don't like nested functions ;) This makes me even less likely to ever upgrade from busybox 1.2.2 then. It's incentive to just replace whatever broken bits it has by implementing the appropriate command in toybox. :) Rob -- One of my most productive days was throwing away 1000 lines of code. - Ken Thompson. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Local procedures
On Thursday 13 September 2007 3:48:31 am [EMAIL PROTECTED] wrote: C is the universal assembly language? That really hit my sweet-tooth (^_^) However, would it not be good if someone tried to make a simple set of standard extensions? - range checking, You mean like tcc's bcheck.c? or at least a new lengthof keyword that returns the length, IMHO that would be lexicaly appropriate, sort of the complement to sizeof...didn't tcc already have some range checking algorithm? - local procedures tcc.h alrady has: #ifndef offsetof #define offsetof(type, field) ((size_t) ((type *)0)-field) #endif #ifndef countof #define countof(tab) (sizeof(tab) / sizeof((tab)[0])) #endif I'm unsure what you're asking for. - maybe a simple way to have array pointers, not an array of pointers, but a pointer that points to an array an has n elements, so instead of pointing to each single element you point to an array and a position in that array, pointer[n] thus points to the n-th element from where the array pointer points to. Er, that would be simple pointer arithmetic? int blah[1000]; int *that = blah+50; that[9]=123; At which point blah[59] == 123. I don't have a black belt in C, so perhaps there are some simpld tricks to the last list item. These are basically the only things about C that I think shold be improved on, but then again, I may be proven wrong even about these things, although I honestly believ these would be good extensions. Bounds checking is your problem. There are a bunch of standard solutions for it, but if you write code to do something stupid in C, it does. The solution is generally not writing code to do something stupid, not asking the computer to figure out what you _meant_ to do. Rob -- One of my most productive days was throwing away 1000 lines of code. - Ken Thompson. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Local procedures
On Wednesday 12 September 2007 4:21:24 am [EMAIL PROTECTED] wrote: I've always been a hardcore supporter of C, and found Torvald's recent outlash against pissant C++ to be just awesome! Really? I missed that. (Googles...) Heh. http://thread.gmane.org/gmane.comp.version-control.git/57643/focus=57918 http://article.gmane.org/gmane.comp.version-control.git/57983 http://article.gmane.org/gmane.comp.version-control.git/57960 Gee, where have I heard this before? http://www.penguicon.org/pipermail/penguicon-general/2007-May/003731.html Too often have I been harrassed just for favouring plain old C. Only a few improvements I'd like to see though, but ended up thinking it was better making it a separate language/dialect and leave plain C alone. Thought tcc would be quite useful for that (^_^) I hope to make tcc more useful for that, but mostly C is a really nice, neat, compact language that hit a sweet spot (it's the univeral assembly language) and became a category killer. http://catb.org/~esr/writings/taoup/html/ch14s04.html http://catb.org/~esr/writings/taoup/html/ch04s03.html#c_thin_glue Rob -- One of my most productive days was throwing away 1000 lines of code. - Ken Thompson. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Local procedures
On Wednesday 12 September 2007 5:54:16 am Zdenek Pavlas wrote:
Antti-Juhani Kaijanaho wrote:
You only need the trampoline if you cannot make the function pointer fat
(ie. if you need to be binary compatible with vanilla C compilers).
Which, of course, describes tcc's situation fairly well.
Even if you really need a trampoline, you don't need a fancy compiler
for that. It's easy to implement (at least on i386) using the existing
support for attribute(regparm). Real closures in C- way more fun than
gcc's nested functions, which are quite limited and (rightfully, IMO)
seldom used.
#include stdio.h
#include malloc.h
#include sys/mman.h
void* closure(void *code, void *data) {
char *c = malloc(10);
c[0] = 0xb8, *(int*)(c + 1) = (int)data; // mov eax, ...
c[5] = 0xe9, *(int*)(c + 6) = (char*)code - c - 10; // jmp ...
mprotect((void*)((int)c ~0xfff), 1, PROT_READ|PROT_WRITE|PROT_EXEC);
return c;
}
You assume that c[0] and c[5] are on the same page.
(And please put a ; in there instead of a comma, it took me three times longer
than it should have to figure out what you're doing. :)
void __attribute__((regparm(1))) /* expect arg #1 in eax */
add_to(int *data, int i) {
*data += i;
}
int main() {
int sum = 0, i;
void (*fun)(int) = closure(add_to, sum);
for (i = 0; i 10; i++) fun(i);
free(fun);
printf(%d\n, sum);
}
Ok, the question here is _why_ would you want to do that? :)
Rob
--
One of my most productive days was throwing away 1000 lines of code.
- Ken Thompson.
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Local procedures
On Tuesday 11 September 2007 11:17:51 pm Antti-Juhani Kaijanaho wrote: I, myself, am not interested in doing the work, as I won't be using local functions in C as they are non-portable (because they were not included the standard). I'm just correcting your misconceptions about the feature :) *Shrug* I've never used this feature. I used the equivalent one in java once but the result was so ugly in terms of what it crapped into the .jar file that I never did it again. (And stopped bothering with Java around 2001, due to Sun screwing over the Blackdown developers...) Rob -- One of my most productive days was throwing away 1000 lines of code. - Ken Thompson. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Local procedures
On Tuesday 11 September 2007 6:24:53 am [EMAIL PROTECTED] wrote: What are the chances of tcc having support for local procedures sometime in the near future? What are local procedures? (Does GCC, or any other C compiler, currently support them?) Rob -- One of my most productive days was throwing away 1000 lines of code. - Ken Thompson. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Local procedures
On Tuesday 11 September 2007 12:18:00 pm Peter Lund wrote: On Tue, 2007-09-11 at 12:04 -0500, Rob Landley wrote: What are local procedures? (Does GCC, or any other C compiler, currently support them?) Yes, see: http://people.debian.org/~aaronl/Usenix88-lexic.pdf That's a C++ feature, not a C feature. I knew about that one. I'm asking about a C compiler. Rob -- One of my most productive days was throwing away 1000 lines of code. - Ken Thompson. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Local procedures
On Tuesday 11 September 2007 1:45:47 pm Peter Lund wrote: On Tue, 2007-09-11 at 13:22 -0500, Rob Landley wrote: Yes, see: http://people.debian.org/~aaronl/Usenix88-lexic.pdf That's a C++ feature, not a C feature. I knew about that one. I'm asking about a C compiler. Okay, let's try it from another angle. Fire up pinfo or info or xemacs or whatever and look at the info file for gcc. From the first page, select the link C Extensions (it is #5 here). From that page, select the link Nested functions::As in Algol and Pascal, lexical scoping of functions (#4 in the menu, #5 overall on the page). Translation: gcc calls this nested functions, which is why it didn't come up when I googled for gcc local procedures. Rob -- One of my most productive days was throwing away 1000 lines of code. - Ken Thompson. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Local procedures
On Tuesday 11 September 2007 6:24:53 am [EMAIL PROTECTED] wrote: What are the chances of tcc having support for local procedures sometime in the near future? Ok, back to the original question, I think you're asking for this: http://gcc.gnu.org/onlinedocs/gcc/Nested-Functions.html Which seems somewhere between an inline function and a macro. And although I'm not averse to merging a patch for this, I'm not too interested in doing the work myself at the moment because I'm focused on getting tcc to compile existing programs (like busybox, uClibc, and the Linux kernel). I don't know of any existing programs that make use of this. I'm guessing you have an example? :) Rob -- One of my most productive days was throwing away 1000 lines of code. - Ken Thompson. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
[Tinycc-devel] Re: Sinus tcc
On Sunday 09 September 2007 5:41:24 pm Jakob Eriksson wrote: May God antibiotics remove your sinus infection. I said a prayer for you. Thanks. I'm leaning towards the antibiotics myself, since presumably they're what's changed recently. The rest of this message should probably be on the mailing list, mind if I repost my reply there? [Note: I got permission.] --- I try to decrease the number of #if-defs in C code. What do you think of the concept I try to explain with this little patch? I'll give it a look... I try to draw conclusions from your denouncement of make. (I agree with you 100%, BTW.) There are two main thoughts here: 1) I include directly what a define tells me. Makes sense, but #include blah.c seems bad form. What programs _should_ do is tcc file1.c file2.c file3.c -o blah, so you have the option of building the files individually and linking them in a separate pass. The reason it's being done now is so that make test2 can go tcc -run tcc.c. The problem is that -run is currently defined to take exactly one C file argument and all the rest are arguments to that that C file, so although you can build an executable out of multiple C files with a single command line, you can't run the result immediately. Changing the semantics of -run aren't an option because A) it's an established UI that's easy to use, B) shell scripts starting with #!/usr/bin/tcc -run are _going_ to put the filename and arguments at the end of the command line in that order, and that's the main use for this feature. We can't add a -- either: shell scripts won't, it would break existing usage, and actually _requiring_ -- is just too ugly. Testing if the next argument ends in .c is too brittle: lots of programs other than tcc can operate on C source as arguments. I suppose we could add a new --multirun that's a positional parameter going after all the arguments to the compiler, so any arguments after that are to the program to be run. Or we could have a runtcc.c file that #includes all the other source files and either make the C files ok with that (make sure all the #includes are guarded and there aren't any conflicting statics) or else make some kind of #reset directive to go between #includes that says we're starting a new file, forget everything you know (see the cleanup at the end of tcc_compile()), which seems ugly. Hmmm... If TCC_TARGET_GEN is defined to i386.c, that file is included. Possibly just #define TCC_TARGET i386 and use that? What does the _GEN tell us that _TARGET doesn't? And we can add .c and .h to i386 as necessary, and rename the .c and .h files if that helps. If it is defined to armv.c, that file is included. These files should all contain functions with the same names, but with different implementations depending on platform, sort of like a HAL. I haven't played with hal, but lots of things do that sort of thing. Also, the C preprocessor gets to play a little part of the same role that make used to play. (Conditional compile depending on what is defined.) I still like the idea of cleanly separated and separately compilable files, if nothing else to keep complexity contained. 2) Instead of calling different functions with different names, depending on some random define, the same function is always called. Only it has different implementations depending on how TCC was configured. (Target CPU etc.) *shrug* Works for me. TCC already makes a separate executable for each target type, and if we wanted to have them share code there's libtcc. (Making one executable do multiple output formats is an implementation detail that would be easy enough to retrofit and not really that useful anyway.) If this sounds O.K. with you, I can clean up tcc more and send more patches. I'm interested in seeing the patches, but won't guarantee applying them until I've seen them. Can you start with some small ones? :) If not, I would still like to help with TCC in some way, because I would also like self hosting embedded systems. I also have this weird idea of using C much as you would any scripting language. That is tcc's strongest point so far. You could write register C files as a MISC binary in the kernel and let tcc handle it. You don't even have to do that, the kernel knows about scripts starting with #! and #!/usr/bin/tcc -r works just fine today. Heh, now I'm pondering source code as shared library. /usr/lib/zlib.c. That would require some tweaks to the shared library loader... regards, Jakob Rob -- One of my most productive days was throwing away 1000 lines of code. - Ken Thompson. diff -r 7909d3c7e712 tcc.c --- a/tcc.c Sat Sep 08 17:30:03 2007 -0500 +++ b/tcc.c Mon Sep 10 00:26:42 2007 +0200 @@ -38,12 +38,14 @@ static int do_bounds_check = 0; static int do_bounds_check = 0; #ifdef TCC_TARGET_I386 -#include i386/i386-gen.c +#define TCC_TARGET_GEN i386/i386-gen.c #endif #ifdef TCC_TARGET_ARM #include
Re: [Tinycc-devel] Today's bug...
On Friday 07 September 2007 7:59:26 am Bernhard Fischer wrote: On Thu, Sep 06, 2007 at 06:56:37PM -0500, Rob Landley wrote: On Thursday 06 September 2007 5:30:56 pm Dave Dodge wrote: On Thu, Sep 06, 2007 at 05:42:35AM -0500, Rob Landley wrote: That definition comes from /usr/include/features.h, and to make a long story short we get it by #defining __STDC_VERSION__ 199901L Since we _do_ support c99, this shouldn't break anything. I think... we _partly_ do. Variable sized arrays (IIRC), to just name a missing part.. We need to add that to support compiling the kernel, anyway. Rob -- One of my most productive days was throwing away 1000 lines of code. - Ken Thompson. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] 4 bugfixes for Rob Landley's revision 470
On Wednesday 05 September 2007 10:31:20 pm Dave Dodge wrote: On Wed, Sep 05, 2007 at 08:46:30PM -0500, Rob Landley wrote: On Wednesday 05 September 2007 7:14:30 pm Simon 'corecode' Schubert wrote: Like the majority of internet protocols. Actually, if you fopen() a text file with mode rt it does convert \r\n to \n. On Linux? That's not in the man page... No, the t is a Windows thing. In Standard C: So it's not in c99, and it's not in susv3. Microsoft can unilaterally define any standards it wants. (So can I, I have a text editor. :) EBCDIC is a standard too. It's generally not relevant... On Windows: rt open for reading in text mode rb open for reading in binary mode r whether you get text or binary mode depends on the current setting of the global _fmode. Note that the default value for _fmode depends on how the application was linked. My first C platform was Turbo C for dos. I'm familiar with this. Luckily, it's the C library's job to ignore that one. Rob -- One of my most productive days was throwing away 1000 lines of code. - Ken Thompson. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
[Tinycc-devel] Today's bug...
#include stdio.h
#include sys/stat.h
int main(int argc, char *argv[])
{
struct stat stat;
stat.st_dev = 42;
printf(%ld\n, stat.st_dev);
return 0;
}
Works find with gcc, with tcc it goes:
test.c:8: cannot cast 'int' to 'struct anonymous'
Yeah, slightly dodgy, but bear with me.
The _reason_ is that the glibc's /usr/include/bits/types.h has:
/* quad_t is also 64 bits. */
#if __WORDSIZE == 64
typedef long int __quad_t;
typedef unsigned long int __u_quad_t;
#elif defined __GLIBC_HAVE_LONG_LONG
__extension__ typedef long long int __quad_t;
__extension__ typedef unsigned long long int __u_quad_t;
#else
typedef struct
{
long __val[2];
} __quad_t;
And since __GLIBC_HAVE_LONG_LONG isn't defined, it falls through to the struct
definition. That definition comes from /usr/include/features.h, and to make
a long story short we get it by #defining __STDC_VERSION__ 199901L
Since we _do_ support c99, this shouldn't break anything. I think...
Rob
--
One of my most productive days was throwing away 1000 lines of code.
- Ken Thompson.
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Today's bug...
On Thursday 06 September 2007 5:59:15 am Joshua Phillips wrote: Why can't we set __GLIBC_HAVE_LONG_LONG, since we do indeed have support for long longs? Because I don't want to hardwire a macro with the string GLIBC into tcc? (I've used it against uClibc before, it doesn't depend on a specific C library...) It seems that the right thing to do is set __STDC_VERSION__ to show we have c99, which I did, although now includes of regex.h are barfing. This might be a glibc bug, or might be that we need to understand restrict, I'll play with it in the morning... Rob -- One of my most productive days was throwing away 1000 lines of code. - Ken Thompson. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] 4 bugfixes for Rob Landley's revision 470
On Thursday 06 September 2007 5:14:56 am Simon 'corecode' Schubert wrote: Then do so. I am not interested in that. I'm interested in taking something that works now (tcc) and making it better. If you want to start over from scratch, you do not need my permission. Are you unfriendly by principle or is this just general I-don't-like-the-state-of-the-world grumpiness? I just don't find Hey tcc developers, the best thing you can do is start over from scratch a helpful point of view, or particularly on-topic here. And the politeness with which I express my lack of interest in things tends to decrease with the number of repetitions. Rob -- One of my most productive days was throwing away 1000 lines of code. - Ken Thompson. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] 4 bugfixes for Rob Landley's revision 470
On Thursday 06 September 2007 5:32:49 pm Gregg Reynolds wrote: On 9/6/07, Basile STARYNKEVITCH [EMAIL PROTECTED] wrote: If you consider starting TCC from scratch you might look into other small open source compilers like http://sourceforge.net/projects/nwcc/ Good Lord, it never ends. Just what I need, another interesting little project to lead me down yet another path! (...must resist, must resist...) Seriously, it would be worth taking a look at such projects. I've looked at a few before (briefly). But the main thing the draws me to tcc is speed. It's partly speed, and partly that it's - - this close to working on all the code I can throw at it. (I also like the fact it's self-contained and doesn't need other projects installed to provide linkers or preprocessors...) If it's X times faster than gcc, that adds up to enormous savings in the development cycle. If we can study it and describe it structurally, so we can categorize it in terms of abstract implementation design choices, so much the better. Now, if one of those other projects competes with tcc for speed, And features, and simplicity of implementation so we can understand what it's doing. well, you'd have to look at it seriously to see how, at least. But rewriting from scratch is too much for me, at the moment anyway. I earnestly hope that I can get tcc running on cygwin in the near future, after which I'll want to use it, but probably not develop it - too many other irons in the fire. Tell me about it. :) Goes off to mess with other irons... Rob -- One of my most productive days was throwing away 1000 lines of code. - Ken Thompson. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Today's bug...
On Thursday 06 September 2007 5:30:56 pm Dave Dodge wrote: On Thu, Sep 06, 2007 at 05:42:35AM -0500, Rob Landley wrote: That definition comes from /usr/include/features.h, and to make a long story short we get it by #defining __STDC_VERSION__ 199901L Since we _do_ support c99, this shouldn't break anything. I think... Well you can always just define it unconditionally, and then if anyone complains about some broken C99 feature you can fall back on the same rationale that gcc uses for defining __STDC__ unconditionally ;-) Actually I was thinking define it unconditionally and then take bug reports if this causes problems... Rob -- One of my most productive days was throwing away 1000 lines of code. - Ken Thompson. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] More fun with comparison between pointer and integer...
On Wednesday 05 September 2007 5:27:46 am Gregg Reynolds wrote:
On 9/5/07, Rob Landley [EMAIL PROTECTED] wrote:
On Wednesday 05 September 2007 1:02:03 am Dave Dodge wrote:
I fixed the ptr || ptr bit not working (check hg), and I just made
it stop warning me about comparison between pointer and int for
and ||, but now it's saying initializer element not constant.
Well looking at 6.6, I'm having a hard time figuring out how to fit
the above into one of the described forms of constant expression.
It's the use of pointers at all that causes the problem; most of the
ways of defining such expressions seem to be constrained to using only
arithmetic types.
It's a pointer to a constant string. It's in a read-only section of
memory. More to the point, the or is testing whether or not it's nonzero,
so the actual _value_ of the pointer goes away and all we need to retain
is that it wasn't NULL.
Well, the source does say
/* XXX: better constant handling */
static void expr_eq(void) {
which calls:
/* XXX: fix this mess */
static void expr_lor_const(void)
...
So you've probably discovered why.
Yup. Not how to fix it yet, but I might have time to bang on that this
evening...
Rob
--
One of my most productive days was throwing away 1000 lines of code.
- Ken Thompson.
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] 4 bugfixes for Rob Landley's revision 470
On Wednesday 05 September 2007 3:28:57 pm Joshua Phillips wrote:
I have made some fixes to tcc that may be useful...
Cool! Thanks.
I'd like to apply these individually, and add test cases to the test suite,
but I think I can break 'em up myself...
Fixed variable-length array in struct:
struct foo {
int a;
void *b[];
};
sizeof(struct foo) is now 4 instead of 0.
Cool.
Added opcode definition for 8-bit sign-extended immediates in 16/32-bit
arithmetic
not really a fix (hence not counted as one of the four), but I was a bit
frustrated when asm (addl $4,%esp) produced the long, 6-byte opcode. I
fixed this to use the shorter opcode where possible.
Ok.
Fix backslash parsing between a false #if/ifdef..#endif
as described in http://www.landley.net/code/tinycc/bugs/preprocessor.c
Cool.
Hmmm, could you give me some more information about the handle_stray_noerror()
thing? It seems like rather than special-casing \r\n, we might want to just
handle any trailing whitespace after a \ line extender? (This isn't specific
to your patch, this is the underlying function being more brittle than I'm
comfortable with.)
Yeah, I know c99-draft 5.1.1.2 #1 pargraph 2 says that only \n immediately
after a backslash gets removed, but we're already breaking that looking for
\r...
Heh. The obvious way to code this is:
/* handle '\[\r]\n' */
static int handle_stray_noerror(void)
{
while (ch == '\\') {
inp();
skip_spaces();
if (ch == '\n') {
file-line_num++;
inp();
} else return 1;
}
return 0;
}
And then have handle_stray() do: if(handle_stray_noerror() error(blah);
Except that doesn't work, naievely because skip_spaces hasn't been declared
yet, but more fundamentally the because skip_spaces() doesn't call inp(), it
calls cinp(). What's cinp()? It's a #define to minp(). (WHY???) And
minp(), of course, is defined as:
static void minp(void)
{
inp();
if (ch == '\\')
handle_stray();
}
Congratulations, we have achieved recursion.
Grrr. I note also that is_space() is shadowing the global ch with its local
declaration of ch. And that ch is hardish to grep for because it appears
in char.
Right... Fix committed, lemme handle the rest in another email.
Rob
--
One of my most productive days was throwing away 1000 lines of code.
- Ken Thompson.
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] 4 bugfixes for Rob Landley's revision 470
On Wednesday 05 September 2007 3:28:57 pm Joshua Phillips wrote:
I have made some fixes to tcc that may be useful...
Fixed variable-length array in struct:
struct foo {
int a;
void *b[];
};
sizeof(struct foo) is now 4 instead of 0.
Applied, and added a test to the testcase.
Fix bug when casting between integer pointers of different sizes
as described in http://www.landley.net/code/tinycc/bugs/gildabah.c
Huh. You know, on arm this test is going to go boom anyway due to unaligned
access, but oh well. We don't have to be able to run the _tests_ on all
platforms, just the compiler. :)
Fix dereferences used in inline assembly output
as described in http://www.landley.net/code/tinycc/bugs/asm.c
Added, with test case.
I have tested these changes, and make test still works 100%.
I have the changes under Mercurial (repository cloned from
landley.net), which I'd prefer to use, for now I've attached a diff
with all the changes to revision 470.
Try revision 475. :)
Thank you very much,
Rob
--
One of my most productive days was throwing away 1000 lines of code.
- Ken Thompson.
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] More fun with comparison between pointer and integer...
On Wednesday 05 September 2007 5:32:06 pm Dave Dodge wrote: On Wed, Sep 05, 2007 at 12:46:00PM -0500, Rob Landley wrote: On Wednesday 05 September 2007 3:25:59 am Dave Dodge wrote: Pretty much the only way it seems to allow using a pointer/address to an object _anywhere_ in a constant expression is in sizeof context, or when the final expression is an address A constant string is an address once the (dynamic) linker's done with it. Yes, but it's only guaranteed to be a constant expression by the Standard if the final expression produces an address. Things like this are well-defined and portable Hang on, so when char *a is constant, (int)a is _not_ constant? How does that work? static char * foo = bar; static char * foo = bar + 1; but your case is not, because your final expression produces an integer. The c89 standard didn't insist that char be 8 bytes, either. ITYM 8 bits, and neither does the C99 Standard. Er, yes. Bits. LP64 does and it applies to anything calling itself a Unix: http://www.unix.org/whitepapers/64bit.html But I don't _need_ a standard to say that any platform that doesn't have 8-bit bytes isn't interesting. And strict adherence to a broken standard can result in a broken compiler. Any platform on which it wasn't was too broken to worry about. For Linux certainly. My understanding is that there are current architectures in the embedded market that use a 32-bit char, though. I haven't heard of them, and am not interested in supporting them. (I know that arm hasn't got instructions to manipulate bytes, but char is still 8 bits on arm linux. The compiler emits code to mask and shift to make it work, which is why you never want to use a char as a loop index on arm.) (If you're curious what I'm doing, it's my toybox project, main.c, line 61.) I see the problem. This adds more ugliness, but like most things you can fix it with another layer of abstraction: USE_ECHO(NEWTOY(echo, OPT_STR(+en), TOYFLAG_BIN)) USE_TOYSH(NEWTOY(exit, OPT_NONE, TOYFLAG_NOFORK)) No. If TCC doesn't handle what it's currently doing, TCC is broken, and I will fix at least _my_ copy of it. I honestly don't care what the standard says about this, and gcc takes this without flinching right now. And then make the trivial definitions alongside NEWTOY and OLDTOY: #define OPT_STR(x) x #define OPT_NONE NULL and #define OPT_STR(x) 1 #define OPT_NONE 0 Won't. -Dave Dodge Rob -- One of my most productive days was throwing away 1000 lines of code. - Ken Thompson. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] More fun with comparison between pointer and integer...
On Wednesday 05 September 2007 6:17:38 pm Rob Landley wrote: Hang on, so when char *a is constant, (int)a is _not_ constant? How does that work? Looking back at it, I think what the standard means is since the actual address of the char * is supplied by the linker, than despite it being a run-time constant it can't be known at compile time. However, we can know that it's nonzero which is all and || need, so I can teach _them_ about propogating constant values from pointers. Rob -- One of my most productive days was throwing away 1000 lines of code. - Ken Thompson. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] 4 bugfixes for Rob Landley's revision 470
On Wednesday 05 September 2007 7:14:30 pm Simon 'corecode' Schubert wrote: Rob Landley wrote: Trailing whitespace is annoying because it's not visible to programmers, but if we're going to skip one kind of whitespace I don't see why not to skip all of 'em. (Windows developers thing \r is _special_ whitespace. I don't.) No, the windows text file convention specifies \r\n as newline. I don't do windows. Like the majority of internet protocols. Actually, if you fopen() a text file with mode rt it does convert \r\n to \n. On Linux? That's not in the man page... In any case, skipping trailing whitespace changes the semantics of \, so that's not a wise thing to do. Is there ever any code that would compile before, but wouldn't now? Nevertheless I wonder if it might be a nice educational experience to write a new tcc (or however it would be called) from scratch, using nice function and variable names, a sane scoping (not everything as globals) and broken up into multiple files. Of course that sounds like a lot of work as well :) Feel free. It would be about as much of an educational experience to morph the existing tcc into something with nice function and variable names, sane scoping, and broken up into multiple files. You'll notice I already broke off a tcc.h from tcc.c. That's the tip of the iceberg of what it _needs_... I don't think those two things are comparable. One thing is designing and implementing a compiler. The other thing is refactoring code to make it readable. I'd always go for the first choice, time and passion permitting. Then do so. I am not interested in that. I'm interested in taking something that works now (tcc) and making it better. If you want to start over from scratch, you do not need my permission. cheers simon Rob -- One of my most productive days was throwing away 1000 lines of code. - Ken Thompson. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] More fun with comparison between pointer and integer...
On Wednesday 05 September 2007 6:29:04 pm Rob Landley wrote: On Wednesday 05 September 2007 6:17:38 pm Rob Landley wrote: Hang on, so when char *a is constant, (int)a is _not_ constant? How does that work? Looking back at it, I think what the standard means is since the actual address of the char * is supplied by the linker, than despite it being a run-time constant it can't be known at compile time. However, we can know that it's nonzero which is all and || need, so I can teach _them_ about propogating constant values from pointers. Which I have now done: , ||, and == NULL all resolve constant arguments at compile time. In theory, it could also compare equality for two constants at compile time even when neither of them is null, but in practice the nonzero value is an index into the symbol array thingy, and that means if you compare thursday == (char *)4 there would be a possibility of a false positive, and I'm just not going there right now. :) Rob Still Rob -- One of my most productive days was throwing away 1000 lines of code. - Ken Thompson. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Linker problem
On Tuesday 08 May 2007 6:13:36 am Philippe Ribet wrote:
Vincent Pit wrote:
Philippe Ribet a écrit :
Hello,
I just downloaded the latest mercurial repository and I still get the
very same problem as described here:
http://lists.gnu.org/archive/html/tinycc-devel/2007-02/msg00041.html
The problem occurs with atexit and some other functions. My system is
Debian/etch.
This message appears many times:
/usr/lib/libc_nonshared.a: '__i686.get_pc_thunk.bx' defined twice
Here is the code I'm unable to compile:
#include stdio.h
#include stdlib.h
void finish() {
printf(The end...\n);
}
int main()
{
atexit(finish);
printf(Hello World\n);
return 0;
}
Does someone have any idea?
Thanks for any help,
Hello,
This is related to
http://lists.gnu.org/archive/html/tinycc-devel/2007-04/msg3.html and
the very recent
http://lists.gnu.org/archive/html/tinycc-devel/2007-05/msg00057.html.
This problem happens because tcc doesn't handle visibility attributes. I
submitted a patch in the first of those links.
Thanks for the quick reply.
I remember I read your mail with the patch. I thought the patch was
applied to the hg repository, that's why I tried again.
I just applied manually the patch and it works for me. Thanks!
Huh, I thought I'd applied this patch already, but I just hit this bug (again,
trying to build new software with tcc) and went wait, I've seen this.
Checked my back email and I had this message marked as unread.
yeah, I need to back and deal with my unfinished tcc items, of which there are
a lot. :)
Anyway, I applied the patch, and I also noticed the stripping problem you saw:
PS: 'strip' does not work anymore on executables generated by tcc.
Specifically, the error I get is:
BFD: toybox_unstripped: no group info for section .text.__i686.get_pc_thunk.bx
Which is the symbol it was complaining about being defined twice before I did
the patch, so it definitely seems to be fallout from this patch. I'm going
to have to learn about elf headers now, aren't I? Oh well,
http://www.muppetlabs.com/~breadbox/software/tiny/teensy.html was a fun
introduction...
Rob
--
One of my most productive days was throwing away 1000 lines of code.
- Ken Thompson.
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/tinycc-devel
[Tinycc-devel] More fun with comparison between pointer and integer...
So in my toybox project (which I'm trying to build with tcc), I'm pulling a dirty trick to do dead code elimination on gcc. Basically, I have macros that boil down to: static const int blah = ptr || ptr || ptr || ptr || 0; with the various ptr entries being either a string constant or NULL. (And they can be #ifdefed out, so the last 0 is there to make sure there's always something to assign). Then, if this thing resolves to 0, the various if() statements that test it get chopped out by dead code elimination, and the command line option parsing code goes bye-bye if unused. I fixed the ptr || ptr bit not working (check hg), and I just made it stop warning me about comparison between pointer and int for and ||, but now it's saying initializer element not constant. Sigh. It's too bad there isn't a channel for this on freenode. I'd love to be able to ask people about this. I hang out on my own channel (#firmware) most of the time, but nobody there seems to know more about tcc than I do. :) Rob -- One of my most productive days was throwing away 1000 lines of code. - Ken Thompson. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] About the fuction gexpr ...
On Wednesday 29 August 2007 4:25:53 am Peter Lund wrote: On Sun, 2007-08-12 at 23:54 -0500, Rob Landley wrote: My priorities are: A) breaking up the source code into smaller, more manageable chunks I still owe you some code there... :/ B) Making it build an unmodified linux kernel. On this one, I'm trying to find the minimal amount of stuff I have to compile to get a kernel image I can boot under qemu, which will say hello world to either the serial port on the vga card. (And then hang.) Then I can try to get tcc to build that, and work my way up from there. (Luckily, Peter Anvin's rewrite of the boot code in C was recently merged, which presumably makes this sort of thing much more accessable.) The general approach I'm taking is: A) read the old Linux Kernel Internals document that walks you through an (alas dreadfully obsolete) version of the boot code: http://www.moses.uklinux.net/patches/lki-1.html B) Run make allnoconfig and then make menuconfig to switch even _more_ stuff off. (It's amazing how much stuff gets left _on_ by allnoconfig. And you have to open the configure standard kernel features menu under general setup in order to switch off more stuff.) Then run make V=1 to see the actual command lines being run, comparing the output of that with a normal make. Unfortunately, the first thing the kernel build does on x86 (other than some housekeeping stuff like creating symlinks) is: gcc -m32 -Wp,-MD,arch/i386/kernel/.asm-offsets.s.d -nostdinc -isystem /usr/lib/gcc/i486-linux-gnu/4.1.2/include -D__KERNEL__ -Iinclude -Iinclude2 -I/home/landley/linux/hg/include -include include/linux/autoconf.h -I/home/landley/linux/hg/. -I. -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-function-declaration -O2 -pipe -msoft-float -mregparm=3 -freg-struct-return -mpreferred-stack-boundary=2 -march=i686 -ffreestanding -maccumulate-outgoing-args -I/home/landley/linux/hg/include/asm-i386/mach-default -Iinclude/asm-i386/mach-default -fomit-frame-pointer -fno-stack-protector -Wdeclaration-after-statement -Wno-pointer-sign -DKBUILD_STR(s)=#s -DKBUILD_BASENAME=KBUILD_STR(asm_offsets) -DKBUILD_MODNAME=KBUILD_STR(asm_offsets) -fverbose-asm -S -o arch/i386/kernel/asm-offsets.s /home/landley/linux/hg/arch/i386/kernel/asm-offsets.c Which looks much scarier than it is. The above is roughly equivalent to: gcc -I include -S asm-offsets.s asm-offsets.c And what it's doing is turning asm-offsets.c into asm-offsets.s, which it then runs a sed invocation against to generate asm-offsets.h, which is the point of the exercise. Our problems: A) we don't produce assembly output. (One possible workaround is to use objdump on the .o file to get assembly, but this means we still can't build a linux kernel without binutils installed, and I'm not sure that gives the same output anyway. That -fverbose-asm makes me especially nervous. Maybe if we build with debug output objdump will be happy?) B) asm-offsets.c doesn't compile with tcc. [EMAIL PROTECTED]:~/linux/temp$ tcc -I ../hg/include -I include2 -c -o woot.o ../hg/arch/i386/kernel/asm-offsets.c In file included from ../hg/arch/i386/kernel/asm-offsets.c:7: In file included from ../hg/include/linux/crypto.h:20: In file included from include2/asm/atomic.h:5: In file included from include2/asm/processor.h:16: In file included from include2/asm/cpufeature.h:11: In file included from ../hg/include/linux/bitops.h:9: In file included from include2/asm/bitops.h:9: include2/asm/alternative.h:9: ',' expected Yup, the _very_first_file_, which is really just header info and structure definitions, died. Wheee... Rob -- One of my most productive days was throwing away 1000 lines of code. - Ken Thompson. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] differences.html
On Wednesday 29 August 2007 4:34:35 am Peter Lund wrote: On Sat, 2007-08-18 at 01:40 -0500, Rob Landley wrote: So I started a list of differences between tcc and gcc. (Not just unfixed bugs but things that are likely to remain different.) http://landley.net/code/tinycc/differences.html Evaluating arguments in the order of last to first would allow more broken programs to work. I'm thinking of programs that don't specify proper prototypes for functions with a variable number of arguments. *shrug* If you're going to use varags, use a prototype. Otherwise trying to make that work sounds too brittle for words. (Code that breaks obviously enough can be debugged.) Other differences just off the top of my head: command-line parameters, I've got some in my wrapper script that I might add. In the short term, I might try using the wrapper script around tcc and see what happens. :) dependency generation (spitting out the names of the include files transitively included in a compilation unit, possibly minus system headers), Patches welcome. :) I think the handling of extra include file directories was rather different last I looked, In what way? some differences in the handling of typedefs and structs especially in the face of forward declarations and incomplete types. Details, please? (I'm aware there are problems here, but my notes are buried somewhere and highly unlikely to be complete anyway...) I believe I've hit programs breaking in this area... -Peter Rob -- One of my most productive days was throwing away 1000 lines of code. - Ken Thompson. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] MINGW compilation failure
On Friday 31 August 2007 12:08:07 pm Hanzac Chen wrote: Yes, it happens really, and it should use `int' instead of `DWORD'. Done. Try -hg. Getting about time to cut a new release, I suspect. Any last minute bug reports I should know about? Rob -- One of my most productive days was throwing away 1000 lines of code. - Ken Thompson. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] autoconfiscation
On Thursday 30 August 2007 1:40:44 am Simon 'corecode' Schubert wrote: Rob Landley wrote: The reason you can't run a glibc version of gcc against uClibc is that pieces of gcc like libgcc_s.so link against their libc, and leak references to that libc. So if you ever divide by a 64 bit number on a 32 bit platform or weird corner cases like that, a reference to glibc sneaks into your uClibc program. Since libgcc is part of the gcc source code, the only way to build a version of that library which leaks a reference the _right_ libc is to rebuild gcc against uClibc, from source code. This is just because libgcc is dynamically linked. You can change that, only producing a static version, which in turn never introduces references to a specific libc. Don't ask me how to do that officially, because my setup uses completely different makefiles alltogether. --disable-shared in config. I'm doing that in firmware linux. But the versions of gcc that come with Fedora and Ubuntu and such don't do that, and to make it do that you have to rebuild gcc from source... Rob -- One of my most productive days was throwing away 1000 lines of code. - Ken Thompson. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Creating .so files.
On Thursday 30 August 2007 9:28:05 am bifferos wrote: --- Rob Landley [EMAIL PROTECTED] wrote: On Wednesday 29 August 2007 6:12:01 am bifferos wrote: --- Rob Landley [EMAIL PROTECTED] wrote: On Wednesday 29 August 2007 3:25:04 am bifferos wrote: I tried to produce a .so file with: tcc -shared -r dll.c -o test_dll.so but when dlopen()ing it I got the error: ./test_dll.so: only ET_DYN and ET_EXEC can be loaded Any ideas what I'm doing wrong? What version are you using, and what platform are you using it on? I tried 0.9.23 on Slackware Linux 11.0. I compiled the same source code with gcc -shared and it was loaded by my test program no problem. Then I looked on the list and then discovered the Mercurial repo, so I tried the tip of that, and got the same result. I take it that from your response I am typing the right compilation command? Dunno, I'm not very familiar with this area. (It's been around two years since I needed to use dlopen() on a shared library, it's pull out the man pages time and I assume you've already done that...) Yup. Did you try doing the same thing with gcc? If it works with gcc and not with Yes, it works fine when .so compiled with gcc -shared -fPIC. tcc, it's a bug and we need to fix it. (Comparing the resulting binaries is a good way to figure out what the heck's wrong, too...) I now know why the .so doesn't load. It's because it wasn't an .so, but a .o file. you cannot combine -shared and -r options on the command line. The first sets the output format to DLL, the second sets it to OBJ, so you end up getting an OBJ file. I guess tcc could add a warning about combining these two options to avoid confusion. It's also a pity the -r option seems to be documented differently between the command-line help and the manual page! However, I'm still no closer to creating my .so file. I surmised that I would have to do it as a two-step process, unfortunately I still get another weird error: bash-3.1$ tcc -r dllmain.c -o dllmain.o bash-3.1$ tcc -shared dllmain.o -o dll.so tcc: file 'AS_NEEDED' not found /usr/lib/libc.so:3: filename expected /usr/lib/libc.so:3: unrecognized file type You're using Fabrice's last release version, not my fork. http://landley.net/hg/tinycc The AS_NEEDED thing should have been fixed a while ago, and I just put in a patch for the -r thing. (Dunno if it _works, but it at least compiled.) Rob -- One of my most productive days was throwing away 1000 lines of code. - Ken Thompson. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Character encoding bug in the mailing list web archive
On Thursday 30 August 2007 3:40:08 pm Peter Lund wrote: Hi, I just checked the access logs for my web site, vax64.dk. It turns out that somebody from Italy downloaded bølge-0.1.tar.gz from my website about 8 hours ago today, presumably to have a look at the Makefile/configuration stuff I did. I wondered why he/she used the wrong URL at first but the explanation turned out to be simple: the web archive got the URL wrong! Fabrice set this list up on Savannah, which I have no control over. Rob -- One of my most productive days was throwing away 1000 lines of code. - Ken Thompson. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Creating .so files.
On Wednesday 29 August 2007 3:25:04 am bifferos wrote: I tried to produce a .so file with: tcc -shared -r dll.c -o test_dll.so but when dlopen()ing it I got the error: ./test_dll.so: only ET_DYN and ET_EXEC can be loaded Any ideas what I'm doing wrong? What version are you using, and what platform are you using it on? Rob -- One of my most productive days was throwing away 1000 lines of code. - Ken Thompson. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] autoconfiscation
On Tuesday 28 August 2007 1:14:19 am Peter Lund wrote: How about not having that many tests? Certainly the option I would prefer. I don't see tcc as having nearly as many external dependencies as my project had. I don't know if this was one of Fabrice's design goals, but it's certainly one of mine. Some day I'd like to get a self-bootstrapping system with just four packages: uClibc BusyBox (or ToyBox) linux tcc I want to boot that under qemu and have it rebuild itself from source code, and boot _that_. I actually think the _easy_ way to handle this is to generate all cross compilers by default and then have a small shell script create a symlink to the one that produces output for our host platform (if any). I would like that :) I'm kind of opinionated about how a compiler works. I think it's no different from a docbook to pdf converter: it takes input and produces output. If something like xml2 had extensive special cases and configuration for every host machine it ran on, it would be a deeply broken piece of software. Yes, having different _targets_ is an interesting thing to configure, because the program is producing different output formats. But that's unrelated to what host you run it on and NOT YOUR PROBLEM. On arm my xml2 produces html, and on PPC it produces pdf, and on mips it produces .PNG files! What's wrong with this picture? Different behavior on different hosts is bad coding. Cross compiling is NOT SPECIAL. The machine your compiler runs on is none of your business, it's the problem of the host compiler you get built with, which is a separate piece of software and should already know everything interesting about your host platform. (If you try to configure your software to work on a host OTHER than the one the compiler that's building you is producing an executable for, it won't work anyway. It doesn't matter if it's a compiler or a web browser or what: it won't work. So don't go there.) If the output you produce happens to be an executable capable of running on the current platform, this is a happy coincidence. But it's also not unique to a compiler: a sed invocation can produce a shell script. Not brain surgery, and not worth jumping through extensive hoops at every level of the program to double-check. /rant I still have to implement this, of course. (Fabrice didn't fall far into the trap of thinking the host is important, but it's tangled in more than one place and I need to get around to cleaning it out...) Rob -- One of my most productive days was throwing away 1000 lines of code. - Ken Thompson. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] autoconfiscation
On Monday 27 August 2007 8:01:50 am Peter Lund wrote: On Mon, 2007-08-27 at 00:21 -0500, Rob Landley wrote: I'm all for improving the config and the makefiles (they need it), but I don't personally consider autoconf or automake to be an improvement. Thank you! That makes me feel safer about the project. I tried as an experiment last year to see how far I could get without using any kind of configure script, just with a GNU makefile (*). It turns out that one get everything auto* gives you plus it is faster, more user friendly, more programmer friendly and doesn't result in (extremely!) big configure shell scripts. *) It has cached feature tests and header dependency tests. If we're doing enough feature tests we need to cache the results, something is wrong. How about not having that many tests? Our ./configure step doesn't take 15 minutes to run (unlike some of the gnu projects), and I'd rather have the build take an extra 3 seconds than have the complexity of a configuration cacheing layer. From my point of view, the main issue is that users expect ./configure; make; make install. It's a user interface thing. In this space, make menuconfig is also fairly widely used (linux, uClibc, busybox), but tcc hasn't got nearly enough configuration options for something like menuconfig to make sense, and I'd rather not go there if we can avoid it. Our ./configure needs to support --help. All I ever really use out of it is --enable-cross and --cc, although I can see specifying the prefix and various paths. (I have no idea what this architecture dependent files nonsense is since it doesn't install any architecture _independent_ files that I'm aware of...) But is our ./configure really probing the host system? (Looks.) Oh that's evil. Look, we don't CARE what machine we're building on. We don't. We care what the _target_ architecture is (NOT THE HOST), and that means we look at the pre#defined symbols the host compiler gives us. Do this: gcc -dM -E - /dev/null Now look through the symbols and write the appropriate #ifdef tests. On Linux you'll have __linux__ and you can tell your architecture from these symbols: Arm: __arm__ Blackfin: __bfin__ m68k: __m68k__ ppc: __powerpc__ sparc: __sparc__ mips: __mips__ x86: __i386__ (yes even i686 gives you this symbol) x86-64: __x86_64__ And so on. Look at the output, grab the appropriate symbol. This tells you the machine your compiler will run on. And this is NOT necessarily the same as the machine your compiler will produce OUTPUT for... If you want to know if the machine you're on is 64 bit, look for __LP64__. The dance to find endianness seems to be: #ifndef __APPLE__ #include byteswap.h #include endian.h #if __BYTE_ORDER == __BIG_ENDIAN #define IS_BIG_ENDIAN 1 #else #define IS_BIG_ENDIAN 0 #endif #else #ifdef __BIG_ENDIAN__ #define IS_BIG_ENDIAN 1 #else #define IS_BIG_ENDIAN 0 #endif And that's only if you care about macos x. (Another platform I haven't got a test system for. They get mad if you try to run it under qemu, so I simply don't develop for it. They made the rules, not me...) There are commands (make targets) to list the caches and to flush them etc. I /could/ make it generate a config.h file but it is cleaner to rely on standards for the most part and a few -Dxxx=yyy parameters to the compiler for the rest. The question that interests me is how much can ./configure _avoid_ doing? The current one is doing _way_ too much work. It's identifying a half-dozen platforms we don't currently support, and I actually think the _easy_ way to handle this is to generate all cross compilers by default and then have a small shell script create a symlink to the one that produces output for our host platform (if any). Note that right now, the code doesn't work right if you build it with -funsigned-char (which is why I added the flag to specify). Personally I prefer -funsigned-char because it makes your ascii handling naturally 8-bit clean, which makes things like utf8 handling easier. Not a _huge_ deal in a compiler, but still... :) I haven't tried building it in an x86-64 environment. I should do so... Rob -- One of my most productive days was throwing away 1000 lines of code. - Ken Thompson. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] TLS/__thread support
On Sunday 26 August 2007 6:34:18 pm Simon 'corecode' Schubert wrote: Hey, Okay, here we go. It's a bit hackish, but not more than the rest of tinycc, so I think that's okay. Currently only the i386 platform is supported and only the Initial Exec and the Local Exec TLS models are supported. I didn't change linking yet, because I have some other problems related to debug sections right now. Binaries linked with gnu ld work as far as I can tell. cheers simon patching file tcc.c Hunk #5 FAILED at 8064. 1 out of 8 hunks FAILED -- saving rejects to file tcc.c.rej Is this expected to work with with the tree at http://landley.net/hg/tinycc ? Rob -- One of my most productive days was throwing away 1000 lines of code. - Ken Thompson. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] TLS/__thread support
On Saturday 25 August 2007 10:13:13 am Simon 'corecode' Schubert wrote: Hey, Do you have any opinons on if or how to support thread local storage (TLS) support (via the __thread keyword)? I'm under the vague impression it just goes into another ELF section, but I don't know the details. If there is a possibility to implement it and a possibility to get the code incorporated, I might try and do it. I'll happily take a patch. :) However I'd need some pointers on where to look and where to tweak, because I'm a total newcomer to the tinycc source. Line 5593 of tcc.c, parse_attribute(), handles the gcc __attribute__ extension, meaning it might even be possible to implement __thread as a #define. But this is just a guess... cheers simon Rob -- One of my most productive days was throwing away 1000 lines of code. - Ken Thompson. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] autoconfiscation
On Sunday 26 August 2007 5:56:09 am Gregg Reynolds wrote: Hi, Just found tcc/tinycc recently. I'd like to use it under cygwin, osx, and opendbsd. However, its config/make system is a little weak. I had to hack it up just to get it to compile on mingw, and there are still problems. Anybody out there willing to help test an autotoolized version? I'm all for improving the config and the makefiles (they need it), but I don't personally consider autoconf or automake to be an improvement. Rob -- One of my most productive days was throwing away 1000 lines of code. - Ken Thompson. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] TLS/__thread support
On Sunday 26 August 2007 6:31:36 am Simon 'corecode' Schubert wrote:
Simon 'corecode' Schubert wrote:
No, it needs a relocation entry of type R_386_TLS_LE (for the object
file) or R_386_TLS_TPOFF (for a shared object). Of course, before, the
variable access has to be constructed to use %gs relative addresses. So
the code generation path would have to be changed for that as well.
Okay, this is the moment I start asking stupid questions:
I'll answer what I can, but I've never used thread local storage on Linux. (I
mostly got threading out of my system back under OS/2 and Java...)
I've kind of tracked down the place to add the functionality between gv()
and load() and vstore()/store(). I guess it would be cleaner to put it
into load()/store(), however, my problem is that I need another register to
actually calculate the offset.
To illustrate, consider this code fragment produced by gcc:
__thread int i;
void f(void){ i = 1; }
produces:
e: 65 a1 00 00 00 00 mov%gs:0x0,%eax
14: c7 80 00 00 00 00 01movl $0x1,0x0(%eax)
what happens here is that %gs:0x0 contains a pointer to the thread local
storage block in which the tls variables are allocated (the 0x0(%eax) is
relocated on link).
So, for every load and store, I'd first need a register to read the pointer
from %gs:0x0, and then I'd need to generate a register-relative load/store.
But I think I am not allowed to allocate a register within load() or
store(), so what would you people suggest to do?
It seems to me that tcc does an awful lot of register spilling to the stack.
It sucks from a performance perspective, and makes the compiler
implementation really simple. (Its' register allocation policy is, more or
less, don't.)
Of course I could generate some push %esi; mov %gs:0x0,%esi; mov
...,0x0(%esi); pop %esi code sequence, but I'm not sure if this is to much
of a hack.
It's what the rest of the code does.
Another interesting point is that there's an arm target (which probably needs
to be cleaned up and genericized so we can add x86-64 and powerpc and mips
and so on as output formats too). What would be involved in adding this
support to the arm target as well?
Keep in mind that x86 is going to become an obsolete format in 2008, which is
about when the installed base of x86-64 hits the 50% mark. Both Intel and
AMD stopped making non-embedded 32 bit processors late last year, you know.
Existing inventories in the channel are all she wrote...
cheers
simon
Rob
--
One of my most productive days was throwing away 1000 lines of code.
- Ken Thompson.
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Do not put static variables into a common section.
On Sunday 26 August 2007 6:24:31 pm Simon 'corecode' Schubert wrote: This is at least needed for DragonFly, so perhaps also for *BSD. Otherwise static variables won't get a proper offset when linking (with gnu ld). I'm confused: it looks like (at a quick glance, which is all I'm up for at the moment with this cold) that the patch makes it put the static variables into bss, which is _not_ a common section...? Could you explain slightly more, please? Rob -- One of my most productive days was throwing away 1000 lines of code. - Ken Thompson. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Do not link -ldl if the OS does not need/have it.
On Sunday 26 August 2007 6:25:26 pm Simon 'corecode' Schubert wrote: There is no -ldl on DragonFly, probably not on other *BSD. Applied. Rob -- One of my most productive days was throwing away 1000 lines of code. - Ken Thompson. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] TLS/__thread support
On Sunday 26 August 2007 6:34:18 pm Simon 'corecode' Schubert wrote: Hey, Okay, here we go. It's a bit hackish, but not more than the rest of tinycc, so I think that's okay. Currently only the i386 platform is supported and only the Initial Exec and the Local Exec TLS models are supported. I didn't change linking yet, because I have some other problems related to debug sections right now. Binaries linked with gnu ld work as far as I can tell. Ok, I need to be _wy_ more coherent to try to review this one, so I'm going to wait for my cold to get better. (Poke me if I don't apply this tomorrow, please.) cheers simon Rob -- One of my most productive days was throwing away 1000 lines of code. - Ken Thompson. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] tcc exit status on error
On Sunday 08 July 2007 12:12:04 pm Michael Somos wrote: I am using the latest CVS version 0.9.24 and found that the exit status is not getting set on error occurring in the compile and link. The problem comes from the function tcc_output_file in tccelf.c which returns an int which is -1 if an error exists. When it's called in tcc.c the return value is ignored. That code could be improved to ret = tcc_output_file(s, outfile) ? 1 : 0; Sorry it took so long to apply this... Applied. Rob -- One of my most productive days was throwing away 1000 lines of code. - Ken Thompson. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] shared libraries broken..ish
On Tuesday 26 September 2006 5:17:04 pm Andrew Johnson wrote: After patching tcc with the simple change for compound literals, I discovered that shared libraries don't work. Trying to use a shared library built in tcc, caused instant crashing. and gdb just gave a nice long list of ??. Quite by accident, I discovered that after running strip on the resulting .so, it worked. I tried this with several other shared libraries, and it was the same in each one, all libraries are useless on build.. but after running strip on them, they appear to work fine. Sometimes the actual binary grows on strip. Could it be that tcc is not properly building the structure for shared libraries, but close enough that strip fixes it? I can deal for now, since strip fixes it for me, but if anyone has ideas, or a real fix I would appreciate it :) Andrew Is this still a problem? Rob -- One of my most productive days was throwing away 1000 lines of code. - Ken Thompson. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
[Tinycc-devel] differences.html
So I started a list of differences between tcc and gcc. (Not just unfixed bugs but things that are likely to remain different.) http://landley.net/code/tinycc/differences.html The first thing this brings to mind is that my other projects (toybox, firmware linux, http://kernel.org/doc) have their websites checked into a source control system, and this doesn't. I could add a www subdirectory to the source code, I suppose... Rob -- One of my most productive days was throwing away 1000 lines of code. - Ken Thompson. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] About the fuction gexpr ...
On Friday 10 August 2007 10:48:44 pm Jack Shang wrote: Is anyone can tell me how does function gexpr works? the process of gexpr is too obscure to understand for me. so any suggestion or help will be appreciated. thanks! Never looked at it before, but let's see... Ah. It's a wrapper to handle comma concatenated statements. You know how you can have multiple statements separated by a comma, even outside function arguments? Ala: for (i=0, j=0; notdone; i++, j++) stuff(); gexpr() it's a little wrapper around expr_eq(). If the last token parsed at the end of the expression isn't a comma, it breaks out and behaves exactly the same as if you'd called expr_eq(). But if the last token was a comma, it does some cleanup, loops around, and calls expr_eq() again. and, is there someone willing to share her/his experience in analysis of TCC? Happy to, but I haven't had time to _do_ any recently. Three months ago I got a fellowship from the Linux Foundation to do kernel documentation, and between that and my Firmware Linux and toybox projects, I'm easily distracted from poking at tcc... I think it is more important to let more people to understand the inside of TCC. but the relevant documents of TCC is so scarce... My priorities are: A) breaking up the source code into smaller, more manageable chunks B) Making it build an unmodified linux kernel. C) Getting it to do just enough dead code elimination to handle things like busybox and toybox. More or less in that order... Rob -- One of my most productive days was throwing away 1000 lines of code. - Ken Thompson. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] What's the newest release of TCC? is it still in 0.9.23 released since 2004?
On Friday 27 July 2007 12:05:55 pm Peter Lund wrote: PS: Will you accept patches to cut tcc up into smaller files in order to make it more modular? Yes please. This is one of the major todo items I have for tcc. I split out the first chunk of it into a .h file, and then had to fiddle with it for a while to make an empty .c file that does nothing but #including it not generate a 20k .o file. I still have some more work to do to get it so I can #include that .h file from a second .c file without things going nuts. (Specifically, the #include i386/i386-gen.c from tcc.c is backwards and should be listed as a separate file on the gcc command line and then fed to the linker, but right now it doesn't do that. This is one of my low hanging fruit issues to make the tcc codebase more flexible.) I did that a few years ago in order to get a handle on what was going on but I didn't have the energy to try to get them accepted under la régime ancien. I'm doing that myself to get a better handle what's going on, but I have no spare time just now. At the start of the month, I was at OLS, giving a tutorial on cross-compiling (using my Firmware Linux as an example, so I had to cut a new release of that on my way there). The following weekend I had to visit Eric Raymond in hopes of getting a new Doclifter release out (a man page to docbook converter is useful for my day job) and a 6-month status report on that world domination 201 paper written up. (Didn't have _any_ time to work on that part. I only had time to get the doclifter repository ported from RCS to http://thyrsus.com/hg/doclifter/ and left Eric rewriting emacs VC mode to understand changesets. Still no new release. I need to spend about another 3 weeks in malvern to get through our combined todo list, but when's that likely to happen?) Then this _past_ week I was in California meeting all of my wife's relatives who couldn't make it to our wedding in April. Yesterday, we rented a truck and did many hours of heavy lifting to pack the contents of our storage space into it. And today, we do the same thing to the apartment. Tomorrow morning, we leave Pittsburgh to move to Austin, which will only be a 3 day drive if we're _lucky_, with the to 2 vehicles and 4 cats and such... In between, I'm doing my documentation day job for the Linux Foundation, which I'm behind on and trying to catch up on now because I get evaluated on it at the end of the month and I have 8 gazillion half finished things I need to finish, post, and write up a report on. (If I could just get 2 uninterrupted weeks to _concentrate_ on this thing, I'd have http://kernel.org/docs in a useful state.) Of course _next_ month I need to spend a week in Michigan for an event I was too busy to make it to last year when we moved _into_ the apartment that the lease just expired on. (I _already_ cancelled on them once...) And I really need to visit my grandparents in Florida who were too sick to make it to the wedding and would like to meet my wife before they die... If I seem slightly stressed and distracted right now, it's because I am. Rob -- One of my most productive days was throwing away 1000 lines of code. - Ken Thompson. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] unknown constraint 't'
On Wednesday 25 July 2007 12:11:38 am Mike S. wrote: The current tarball code at http://landley.net/hg/tinycc doesn't appear to handle the 't' constraint either (tinycc-3e7c64539eb2). *shrug* I don't have a windows system. I'll take patches to fix windows problems, but I can't test them. Rob -- One of my most productive days was throwing away 1000 lines of code. - Ken Thompson. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] What's the newest release of TCC? is it still in 0.9.23 released since 2004?
On Tuesday 24 July 2007 6:42:31 pm David A. Wheeler wrote: Rob Landley: The most recent reemergence of this concept was: http://lists.gnu.org/archive/html/tinycc-devel/2007-05/msg00139.html And I've barely touched my tree since then. (It usually takes me at least three months to regain interest when this happens, and this time I'm busy enough with other things it may take much longer.) Hmm, my intent was to let you keep going while using Hg - so you wouldn't need to use CVS - while letting people who pull from CVS to keep pulling doing so. I point out that you can get a tarball of any version through the hg web interface, but oh well. All I intend to do is pull changesets from your Hg tree into CVS, as you make changes to your Hg branch NOT to _maintain_ the stuff in CVS. If people start checking stuff into CVS that isn't already in my tree, it's an amazing pain for me to extract that change, far more than it is if they posted it to the list. This threat has sort of receeded, but making CVS relevant again brings it back to the surface. It also brings back the your tree isn't good enough, only this other tree over here is real bit. That way, people who currently pull from CVS can keep doing so, and the CVS can can act as the backup in case your server goes down/away (that happened a few months ago). If anyone, anywhere has done an hg clone on my tree, they have a complete backup of the entire history. This is how mercurial (or any other modern decentralized source control system, including git) works. I've been sending patches to you, and telling others to do the same. So just keep modifying tcc using Hg, as you want to; you have a more active tree. The whole point was to let you keep making modifications as you see fit! Last time Fabrice regained interest he checked something into CVS that was never posted to the list. I don't want to stand in his way if he regains interest again, but I'm not pulling another patch out of CVS. I got pulled off on some other work, Join the club. I just got back from california, we pick up a moving truck tomorrow, fill it up, head to austin, and from there I fly to Michigan for a week (and will probably be completely offline for that). The past two months has been kind of crazy... which is why I haven't pulled Changesets into CVS yet. But I still intend copy your tree into CVS (with history of changes, modulo CVS limits). But the point was so that you can keep making changes using Hg, without needing to touch CVS. I currently don't need to touch CVS, and have no intention of getting any of it on me. However, CVS is somehow special and needs to be touched even if I don't do it. My tree stands in the shadow of the CVS tree, because the CVS tree is the real one, even when it's not updated. I've come to terms with this, but it means that playing with my tree is a meaningless thing I do solely for my own amusement, or because I'm explicitly asked to. Don't mind me, I'm jetlagged and moving... --- David A. Wheeler Rob -- One of my most productive days was throwing away 1000 lines of code. - Ken Thompson. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] What's the newest release of TCC? is it still in 0.9.23 released since 2004?
On Sunday 22 July 2007 12:32:56 pm Conrado Miranda wrote: No, it isn't. Fabrice doesn't spend time on it anymore. You can find the lastest version here: http://landley.net/hg/tinycc Rob mantains tcc now and his page has lots of patches and the source with all patches applied. Um, maintains is a bit strong. I maintain my own fork, and happily accept patches to it, but it's not official and I am constantly reminded that it never will be. Fabrice Bellard made it clear that the only possible official version is the CVS repository on Savanah. I don't do CVS, it's an old crufty technology from the 1980's that I try not to touch unless paid to. Every few months somebody comes up with some plan or other to revive the old CVS tree, and I stop working on mine. (In part I get out of their way in case it actually happens, and in part I'm dispirited by this and loose interest.) The most recent reemergence of this concept was: http://lists.gnu.org/archive/html/tinycc-devel/2007-05/msg00139.html And I've barely touched my tree since then. (It usually takes me at least three months to regain interest when this happens, and this time I'm busy enough with other things it may take much longer.) I do not have tools to merge anything from CVS into my tree (I made tailor do a cvs2hg once, but then upgraded Ubuntu and now the python cvs code doesn't work anymore and nobody's interested in fixing it). I don't do development on projects that are in CVS except occasionally by sending in patches to their mailing lists. When my tree fell behind the CVS tree by one patch (which was never posted to this list) it stayed there for most of a year. And now, I'm off to do other things... Rob -- One of my most productive days was throwing away 1000 lines of code. - Ken Thompson. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] strange error
On Saturday 30 June 2007 00:46:31 Michael Huss wrote: I am using Gentoo Linux, with the latest version of portage and the portage tree, and I just installed tcc today. I have used it before in binary-based distros, but never here. I am getting a strange error now, no matter what I try to compile: [EMAIL PROTECTED] ~ $ tcc hello-world.c /usr/lib/crtn.o: Invalid relocation entry What tcc version are you using? Try the one in the mercurial repository at http://landley.net/hg/tinycc (you can get a tarball from the links up top). I should do another unofficial release... I was hoping I could use tcc as my C compiler for portage, so it woud emerge many times faster, but first I have to know that it is actually working. I can mess with my CC variable and break stuff later.;-D tcc builds a lot of things but not everything. Also, the output is less efficient (If there was an -O -1, we'd be doing that). P.S. It would be nice if people could meet on IRC to talk about things like this in the future. I will be in #tcc on irc.freenode.org if anybody wants to join me. Rob -- One of my most productive days was throwing away 1000 lines of code. - Ken Thompson. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] How TCC handlse the scope
On Friday 22 June 2007 18:29:34 David A. Wheeler wrote: If you call a function that hasn't been defined, C assumes that it takes an int, and returns an int, no matter what it REALLY does. nitpick Actually, C assumes it takes all varargs and returns an int. int blah(...); (see man 3 va_arg.) /nitpick Way back when (before the Ansi C 89 standard) there were no function prototypes, so every function was expected to do the above. This works for a surprising number of things because on a 32-bit platform, any pointer can be cast to an int and back so things that return pointers work if you return ints. Basically there was a register in which to expect the return value. On a 64-bit platforms this doesn't work, because it would have to default to long to hold a pointer and everybody just says prototype the darn thing already. But then 64 bit platforms are a relatively recent invention (the DEC Alpha was around 1993 I think). The standards for them are even more recent... Rob -- One of my most productive days was throwing away 1000 lines of code. - Ken Thompson. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] better code for case labels
On Friday 15 June 2007 10:56:28 Zdenek Pavlas wrote: Generate better code for case labels with no code in between. Applied to my tree. Rob -- One of my most productive days was throwing away 1000 lines of code. - Ken Thompson. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
