Re: [Tinycc-devel] tcc as compiler for tccboot

[Michael Matz]

Hi,

On Wed, 20 Apr 2016, Sergey Korshunoff wrote:

> > Just checked. I used a hex editor to replace a 0x20 bytes in mem-2.o with 
> > 0x04.
> > This helped.
> 
> diff --git a/libtcc.c b/libtcc.c
> index 5aebd32..a8e109c 100644
> --- a/libtcc.c
> +++ b/libtcc.c
> @@ -514,7 +514,11 @@ ST_FUNC Section *new_section(TCCState *s1, const
> char *name, int sh_type, int sh
>  sec->sh_addralign = 1;
>  break;
>  default:
> +#ifdef TCC_TARGET_I386
> +sec->sh_addralign =  4; /* gcc/pcc default alignment for i386 */
> +#else
>  sec->sh_addralign = 32; /* default conservative alignment */
> +#endif
>  break;

A nicer default that will work for all our architectures is 'PTR_SIZE'.

The 32 comes from Fabrices original tcc implementation, at which point you 
couldn't yet specify alignment for decls (or sections) explicitely, and 
some needed larger alignment than pointer sizes.  This isn't the case 
anymore, section alignment is updated as needed.  So reducing to something 
sensible is possible now.

Please go with PTR_SIZE and no #ifdefery.


Ciao,
Michael.

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

Re: [Tinycc-devel] tcc as compiler for tccboot

[Sergey Korshunoff]

> In any event, it is odd to me that any software compiled entirely from source
> should care about this sort of alignment. It should leave such issues up to
> the compiler, as an implementation detail, shouldn't it?

In the source code we can ask about a section where to place result,
an alignment
of the result, but not alignment (padding) of the section itself. I.e.
how sections of the
same name (from different source code) are combined.

PS: A description of the linux initial code: a name (pointer) of the
init function is placed in
the special section. And after kernel start this functions are called.
If section padding
is more then sizeof(pointer), then there are null pointers and we have a trap

A special section for this is used to free memory after start (no need
after start).

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

Re: [Tinycc-devel] tcc as compiler for tccboot

[David Mertens]

Hello Sergey,

On Thu, Apr 21, 2016 at 12:44 AM, Sergey Korshunoff 
wrote:

> > That's a good bit of sleuthing. A couple of questions immediately come
> to mind:
> >Why does gcc and pcc take 4 as their alignment? Why do we take 32?
> I'm not a guru. But tcc behaviour cost me a day of the problem discovering
>

I hate it when I lose a full day to stuff like this.


> >Does this have any performance impact?
> I don't think so. This alignment is for unusual sections, not for
> .text .data and so.
>
> >Is there a reason you are implementing this with #ifdef?
> I don't know about gcc defaults on different ARCH
>
> > Might we use a preprocessor value (i.e. TCC_DEFAULT_ALIGNMENT) and
> #define that in architecture-specific header files instead?
> May be. But problem exposed only on i386.
>

Taking all three of these together, I wonder if there is a reason tcc
defaulted to 32 in the first place. That is, why not just switch to 4 for
all architectures? Perhaps you could do that, push a topic branch, and ask
folks to pull it and run their own tests on it. (It looks like you haven't
pushed any topic branches yet to http://repo.or.cz/tinycc.git/refs)

Something that might help the conversation along: Do you know where, in the
source code for gcc, the alignments are set? This might let us examine how
they handle it across architectures. It might even be possible to run "git
blame" on said lines in gcc's source, to see if we can learn anything from
the commit history.

In any event, it is odd to me that any software compiled entirely from
source should care about this sort of alignment. It should leave such
issues up to the compiler, as an implementation detail, shouldn't it?

PS: another problem: 0x1234-123 parsed by tcc as float number by
> default and there is no switch to dsiable this. And gcc-3.4.6 (4.1.2)
> understand the above as expression 0x1234 - 123 by default.
>

No no no! This is unrelated! Start a different thread, or the conversation
will get all confused!

David

-- 
 "Debugging is twice as hard as writing the code in the first place.
  Therefore, if you write the code as cleverly as possible, you are,
  by definition, not smart enough to debug it." -- Brian Kernighan
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] tcc as compiler for tccboot

[Sergey Korshunoff]

> 0x1234-123 parsed by tcc as float number
May be 0x0fe-123 (as macro expansion, I can't remember now)

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

Re: [Tinycc-devel] tcc as compiler for tccboot

[Sergey Korshunoff]

> That's a good bit of sleuthing. A couple of questions immediately come to 
> mind:
>Why does gcc and pcc take 4 as their alignment? Why do we take 32?
I'm not a guru. But tcc behaviour cost me a day of the problem discovering

>Does this have any performance impact?
I don't think so. This alignment is for unusual sections, not for
.text .data and so.

>Is there a reason you are implementing this with #ifdef?
I don't know about gcc defaults on different ARCH

> Might we use a preprocessor value (i.e. TCC_DEFAULT_ALIGNMENT) and #define 
> that in architecture-specific header files instead?
May be. But problem exposed only on i386.

PS: another problem: 0x1234-123 parsed by tcc as float number by
default and there is no switch to dsiable this. And gcc-3.4.6 (4.1.2)
understand the above as expression 0x1234 - 123 by default.

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

Re: [Tinycc-devel] tcc as compiler for tccboot

[David Mertens]

Hello Sergey,

That's a good bit of sleuthing. A couple of questions immediately come to
mind:

   - Why does gcc and pcc take 4 as their alignment? Why do we take 32?
   - Does this have any performance impact?
   - Is there a reason you are implementing this with #ifdef? Might we use
   a preprocessor value (i.e. TCC_DEFAULT_ALIGNMENT) and #define that in
   architecture-specific header files instead?

Thanks!

David

On Wed, Apr 20, 2016 at 11:49 AM, Sergey Korshunoff 
wrote:

> > Just checked. I used a hex editor to replace a 0x20 bytes in mem-2.o
> with 0x04.
> > This helped.
>
> diff --git a/libtcc.c b/libtcc.c
> index 5aebd32..a8e109c 100644
> --- a/libtcc.c
> +++ b/libtcc.c
> @@ -514,7 +514,11 @@ ST_FUNC Section *new_section(TCCState *s1, const
> char *name, int sh_type, int sh
>  sec->sh_addralign = 1;
>  break;
>  default:
> +#ifdef TCC_TARGET_I386
> +sec->sh_addralign =  4; /* gcc/pcc default alignment for i386 */
> +#else
>  sec->sh_addralign = 32; /* default conservative alignment */
> +#endif
>  break;
>  }
>
> ___
> 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] tcc as compiler for tccboot

[Sergey Korshunoff]

> A problem may be in the section aligment: gcc sets this to 4 and tcc to 32.
Just checked. I used a hex editor to replace a 0x20 bytes in mem-2.o with 0x04.
This helped.

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

Re: [Tinycc-devel] tcc as compiler for tccboot

[Sergey Korshunoff]

A problem may be in the section aligment: gcc sets this to 4 and tcc to 32.
Where in the source this is fixed?

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

[Tinycc-devel] tcc as compiler for tccboot

[Sergey Korshunoff]

Hi!
I'm trying to use tcc as CC compiler for usual kernel compilation (2.4.37) i.e.
  cd linux
  make bzImage CC=tcc

Kernel compiles fine, but hangs some time after start. After
Investigating a problem, I got the following difference: a file
mem-2.s (a part of the file drivers/char/mem.c)
.section .initcall.init
.long chr_dev_init

objdump -Dtsr mem-2.o (compiled by gcc)

mem-2.o: file format elf32-i386
SYMBOL TABLE:
 ld  .text<> .text
 ld  .data<> .data
 ld  .bss<-> .bss
 ld  .initcall.init> .initcall.init
 *UND*<> chr_dev_init
Disassembly of section .initcall.init:
 <.initcall.init>:
   0:<->00 00<->add%al,(%eax)
<--><--><-->0: R_386_32<--->chr_dev_init

objdump -Dtsr mem-2.o (compiled by tcc)
mem-2.o: file format elf32-i386
SYMBOL TABLE:
 ldf *ABS*<> mem-2.s
 *UND*<> chr_dev_init
Disassembly of section .initcall.init:
 <.initcall.init>:
   0:<->00 00<->add%al,(%eax)
<--><--><-->0: R_386_32<--->chr_dev_init

As you can see, there is only one difference:
in mem-2.o compiled by gcc  we see extra data in symbol table
 ld  .text<> .text
 ld  .data<> .data
 ld  .bss<-> .bss
 ld  .initcall.init> .initcall.init
Nothing serious. But kernel hangs with mem-2.o compiled by tcc.
May be gnu ld needs that? Is it possible to modify tcc in the way like gcc?

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