tinycc-devel
[Top][All Lists]
Advanced

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

Re: [Tinycc-devel] x86-64 port


From: grischka
Subject: Re: [Tinycc-devel] x86-64 port
Date: Sun, 30 Nov 2008 15:48:29 +0100
User-agent: Thunderbird 1.5.0.10 (Windows/20070221)

shinichiro.h wrote:

Please consider to contribute to our GIT repo directly.
http://repo.or.cz/w/tinycc.git

Thanks for the suggestion.

I pushed two patches. The first one introduces ElfW macros to
encapsulate the difference between Elf32 and Elf64, and REL and RELA.
The second one was just copied pieces related to x86-64 from my
/usr/include/elf.h. I checked this two patch don't break x86 TCC.

http://repo.or.cz/w/tinycc.git?a=commit;h=e9cbea68479f714c27a522931fc579e0db1bd522
http://repo.or.cz/w/tinycc.git?a=commit;h=3531962e81ff89415097b9f9654bf15affa35882

I'm new to git. I hope I didn't do something wrong.

No, it's great.

For commit messages, the convention is to use a short header line,
and if needed, add more information below with line breaks. (I always
use the first line for CVS later).

You could use the status summary from your first email as commit-message
at some point.

Let me confirm if I understand the process you are suggesting
correctly. I'll continue to split my patch into several pieces and
push them. Then, I'll report my changes in this list. Finally, you'll
merge my changes into the main branch. Is this process correct?

Absolutely.

If you want I can add you as "project member" so you can work more
undisturbed on say, a "x86-64" topic branch.

To be honest, I don't understand the benefit to have my own branch in
the remote git repository for now. Maybe the mob branch and local
branches are sufficient for now. Once I understand git and development
process of here well, I may ask you to give the account.

Well, other people may push on "mob".  I was thinking that with an
extra branch you could keep your work together.  Say if you want to
add something in a month or so.  But we'll see how it goes.

- Try to avoid casts if it's just to get rid of gcc-warnings.
   We'd rather use a gcc-switch to disable such warnings, for now.

I see. I'll withdraw unnecessary casts.

Thanks. The reason is that casts hide the real problem which is type
inconsistency.  I hope we can make it more consistent at some time.
It might be not entirely trivial in cases, for instance changing
the text-buffers to signed char could change the behavior of the parser.
Maybe, maybe not.

   Also try to separate such and other formal changes into their
   own patches. It makes it easier for other people to follow your
   actual work.  With GIT it is painless to make many small commits.

Sure.

- in tcc_delete: free the member before the structure :)
     tcc_free(s1->jmp_table);
     tcc_free(s1);

Oops. Thanks for catching this.


No matter.

--- grischka





reply via email to

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