Re: [Tinycc-devel] OT (Re: modern c++ compiler written in C)
On Mon, May 18, 2015 at 01:34:45AM -0500, Jared Maddox wrote: > Templates are certainly somewhat convenient, but when you get down to > it they're a poorly designed code generation system that has grossly > distorted the language: most of C++'s design problems could likely be > fixed by scraping the old syntax & semantics for a new variant (which > obviously isn't going ... +1 Rune ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
[Tinycc-devel] tips? define asm symbol as global if it is extern in C
Hello all!
tcc fails to compile the following program
extern void vide(void);
#ifndef TCC_OK
__asm__(".align 4\nvide: ret"); // tcc: error: undefined symbol 'vide'
#else
__asm__(".align 4\n.globl vide\nvide: ret");
#endif
int main (void) { vide(); }
What the problem with tcc? Why tcc need ".globl vide" in asm code and
gcc can compile w/o this declaration?
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] TinyCC REPL
Hello all
A some question:
* push a given symbol on the symbol stack */
ST_FUNC Sym *sym_push(int v, CType *type, int r, int c)
{
Sym *s, **ps;
TokenSym *ts;
#ifdef CONFIG_TCC_EXSYMTAB
v &= ~SYM_EXTENDED;
#endif
if (local_stack)
ps = &local_stack;
else {
#ifdef CONFIG_TCC_EXSYMTAB
/* Global symbol stack. This is OK for the local symbol stack,
but don't allow
* this for symbols that are in the extended symbol stack. */
if (v >= SYM_EXTENDED) {
tcc_error("Cannot use name '%s' as a global variable, it
is already in the "
"extended symbol table.", get_tok_str(v, 0));
}
#endif
ps = &global_stack;
}
v is integer and SYM_EXTENDED=0x4000
When (v >= SYM_EXTENDED) can be true ?
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] TinyCC REPL
Sergey,
That's a good question. To add the SYM_EXTENDED flag, I took SYM_STRUCT,
SYM_FIELD, and SYM_FIRST_ANOM and shifted them down by 1. So, SYM_STRUCT
used to be 0x4000. As to whether or not a 32-bit integer can hold it,
isn't that constant equivalent to 2^31? Unless I've miscalculated or lost
my mind, I'm pretty sure that fits. It certainly achieves the desired end
in code that I've run on my machine, which uses 4 bytes for its integers.
David
On Mon, May 18, 2015 at 6:21 AM, Sergey Korshunoff wrote:
> Hello all
> A some question:
>
> * push a given symbol on the symbol stack */
> ST_FUNC Sym *sym_push(int v, CType *type, int r, int c)
> {
> Sym *s, **ps;
> TokenSym *ts;
>
> #ifdef CONFIG_TCC_EXSYMTAB
> v &= ~SYM_EXTENDED;
> #endif
> if (local_stack)
> ps = &local_stack;
> else {
> #ifdef CONFIG_TCC_EXSYMTAB
> /* Global symbol stack. This is OK for the local symbol stack,
> but don't allow
> * this for symbols that are in the extended symbol stack. */
> if (v >= SYM_EXTENDED) {
> tcc_error("Cannot use name '%s' as a global variable, it
> is already in the "
>"extended symbol table.", get_tok_str(v, 0));
> }
> #endif
> ps = &global_stack;
> }
>
> v is integer and SYM_EXTENDED=0x4000
> When (v >= SYM_EXTENDED) can be true ?
>
> ___
> Tinycc-devel mailing list
> Tinycc-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel
>
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." -- Brian Kernighan
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] TinyCC REPL
0x8000 is a sign bit. If v == 0x8000 then v < 0x4000 ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] tips? define asm symbol as global if it is extern in C
Looks like sym_push for extern proc must define a label too. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
[Tinycc-devel] No lazy PLTGOT relocation for TinyCC generated executables
Hi all, I'm currently working on distention, cleaning up and refactoring tccelf.c. The process already uncovered some bugs and one of them is that PLT0 is broken for ARM [1]. Since binaries are working, I investigated and found that the lazy relocation of PLTGOT entries is not in effect. When _start is run, PLTGOT entries already hold their final values. I tries comparing the output of readelf -a for an hello world program but there are too many differences and I didn't spot anything obvious. So I'm turning to you dear TinyCC community[2] for some explanation. Why does ld.so behave as if RTLD_BIND_NOW was set when running TinyCC generated executables? [1] it lacks an extra 4 bytes to hold offset to GOT and code in relocate_plt to write the offset in that space. [2] Michael, I'm asking you explicitly since you are one of the author of the System V ABI for x86_64 and thus probably know a fair amount on the subject. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] tips? define asm symbol as global if it is extern in C
Hi all,
there is a patch for the problem. Any suggestions?
diff -urN tinycc.old/tccasm.c tinycc/tccasm.c
--- tinycc.old/tccasm.c 2015-05-18 12:30:24.0 +0300
+++ tinycc/tccasm.c 2015-05-18 16:28:03.0 +0300
@@ -779,6 +779,16 @@
opcode = tok;
next();
if (tok == ':') {
+/* handle "extern void vide(void); __asm__("vide: ret");" as
+"__asm__("globl vide\nvide: ret");" */
+Sym *sym = sym_find(opcode);
+if (sym && (sym->type.t & VT_EXTERN)) {
+sym = label_find(opcode);
+if (!sym) {
+sym = label_push(&s1->asm_labels, opcode, 0);
+sym->type.t = VT_VOID;
+}
+}
/* new label */
asm_new_label(s1, opcode, 0);
next();
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] tips? define asm symbol as global if it is extern in C
On May 18, 2015 9:39:36 PM GMT+08:00, Sergey Korshunoff
wrote:
> Hi all,
> there is a patch for the problem. Any suggestions?
>
> diff -urN tinycc.old/tccasm.c tinycc/tccasm.c
> --- tinycc.old/tccasm.c 2015-05-18 12:30:24.0 +0300
> +++ tinycc/tccasm.c 2015-05-18 16:28:03.0 +0300
> @@ -779,6 +779,16 @@
> opcode = tok;
> next();
> if (tok == ':') {
> +/* handle "extern void vide(void); __asm__("vide:
> ret");" as
> +"__asm__("globl vide\nvide: ret");" */
> +Sym *sym = sym_find(opcode);
> +if (sym && (sym->type.t & VT_EXTERN)) {
> +sym = label_find(opcode);
> +if (!sym) {
> +sym = label_push(&s1->asm_labels, opcode, 0);
> +sym->type.t = VT_VOID;
> +}
The else should throw an error for trying to redefine the symbol.
> +}
> /* new label */
> asm_new_label(s1, opcode, 0);
Shouldn't this be part of a else for the outer if?
> next();
Ok otherwise.
Tom
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] No lazy PLTGOT relocation for TinyCC generated executables
On May 18, 2015 7:46:26 PM GMT+08:00, Thomas Preud'homme wrote: > Hi all, > > I'm currently working on distention, cleaning up and refactoring Err, documentation. > tccelf.c. The process already uncovered some bugs and one of them is > that PLT0 is broken for ARM [1]. Since binaries are working, I > investigated and found that the lazy relocation of PLTGOT entries is > not in effect. When _start is run, PLTGOT entries already hold their > final values. Note that I checked and this applies also to x86_64. > > I tries comparing the output of readelf -a for an hello world program Err, tried. Sorry for the typos, I'm writing on my phone. Best regards, Thomas ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] No lazy PLTGOT relocation for TinyCC generated executables
> tries comparing the output of readelf -a for an hello world program but there > are too many > differences and I didn't spot anything obvious there is no .got.plt section in the tcc generated exe. gcc don't generate this section if bind_now. no (FLAGS attribute too. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] tips? define asm symbol as global if it is extern in C
Sergey Korshunoff wrote:
Hi all,
there is a patch for the problem. Any suggestions?
And why does tinycc need this? If you want the symbol to be
global, you can add ".globl" to your asm.
Behavior whereby any "extern" declaration in C, provided it
appears above the asm in the file, would have the same effect
as .globl, is not a known feature to anyone.
-- gr
diff -urN tinycc.old/tccasm.c tinycc/tccasm.c
--- tinycc.old/tccasm.c 2015-05-18 12:30:24.0 +0300
+++ tinycc/tccasm.c 2015-05-18 16:28:03.0 +0300
@@ -779,6 +779,16 @@
opcode = tok;
next();
if (tok == ':') {
+/* handle "extern void vide(void); __asm__("vide: ret");" as
+"__asm__("globl vide\nvide: ret");" */
+Sym *sym = sym_find(opcode);
+if (sym && (sym->type.t & VT_EXTERN)) {
+sym = label_find(opcode);
+if (!sym) {
+sym = label_push(&s1->asm_labels, opcode, 0);
+sym->type.t = VT_VOID;
+}
+}
/* new label */
asm_new_label(s1, opcode, 0);
next();
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] tips? define asm symbol as global if it is extern in C
> And why does tinycc need this? If you want the symbol to be > global, you can add ".globl" to your asm. This snipped is taken from the linux 2.4.26 (2.4.37) kernels. It looks like there is no such code in 2.6+ kernels. PS: yes, I can live w/o this. There are other places which require a patching of the kernel. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] tips? define asm symbol as global if it is extern in C
Sergey Korshunoff wrote: And why does tinycc need this? If you want the symbol to be global, you can add ".globl" to your asm. This snipped is taken from the linux 2.4.26 (2.4.37) kernels. It looks like there is no such code in 2.6+ kernels. PS: yes, I can live w/o this. There are other places which require a patching of the kernel. Well, compiling the kernel is maybe an interesting experiment, however tinycc would have a _very_ long way to go until it could produce one that you'd want to recommended to anyone to run on real hardware. If it helps to fix small bugs or to add features that fit in nicely, fine. However not a good idea if its just workarounds. Because if you want tinycc to become more reliable then workarounds is the least thihg you need. (What you need is a new tccgen.c at least - you can start today ;) Ps, in this case, it works in gcc because gcc compiles C to asm first, and then as resolves the symbol. There is no natural solution to this in tinycc. -- gr ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] tips? define asm symbol as global if it is extern in C
> If it helps to fix small bugs
It looks tcc have some serious bugs related to the compiled kernel:
negative numbers of the freed memory, traps when booting.
One of the problem:
what size of the segment registers (%fs, %gs)
- asm volatile("mov %%fs,%0":"=m" (prev->fs));
- asm volatile("mov %%gs,%0":"=m" (prev->gs));
+ asm volatile("movw %%fs,%0":"=m" (prev->fs));
+ asm volatile("movw %%gs,%0":"=m" (prev->gs));
or
+ asm volatile("movl %%fs,%0":"=m" (prev->fs));
+ asm volatile("movl %%gs,%0":"=m" (prev->gs));
Related to the pp (or asm?):
SYMBOL_NAME_STR(IRQ) #nr "_interrupt:\n\t" \
- "pushl $"#nr"-256\n\t" \
+ "pushl $"#nr" - 256\n\t" \
A .rept asm macro must be implemented:
+#if 0
.rept NR_syscalls-(.-sys_call_table)/4
.long SYMBOL_NAME(sys_ni_syscall)
.endr
+#else
+.long SYMBOL_NAME(sys_ni_syscall)
+.long SYMBOL_NAME(sys_ni_syscall)
+.long SYMBOL_NAME(sys_ni_syscall)
+.long SYMBOL_NAME(sys_ni_syscall)
+.long SYMBOL_NAME(sys_ni_syscall)
+.long SYMBOL_NAME(sys_ni_syscall)
+.long SYMBOL_NAME(sys_ni_syscall)
+.long SYMBOL_NAME(sys_ni_syscall)
+.long SYMBOL_NAME(sys_ni_syscall)
+.long SYMBOL_NAME(sys_ni_syscall)
+.long SYMBOL_NAME(sys_ni_syscall)
+.long SYMBOL_NAME(sys_ni_syscall)
#endif
I don't shure that I can do this.
PS: I will try to mix gcc compiled *.o and tcc compiled *.o to find a
code which is miscompiled by tcc.
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
