[Tinycc-devel] Straightening out x86_64 build?
Hi. Ubuntu 12.04 x86_64, latest mob. Plain ./configure make It still builds an i386 cross compiler instead of a native compiler. Can whoever broke this P L E A S E fix it? Thanks, Arnold ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Straightening out x86_64 build?
What is the output of the uname -m ? ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] CValue
x86 system: tcc with this patch applied succefully compile a linux 2.4.26 kernel and this kernel boots w/o problems... ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Your revert of a gdb-helping patch breaks gdb
Test: debugging programs compiled with the current tcc in x86 systems
(centos6, gentoo). Debuggers: gdb 6.6 and 7.3. All works OK
This is not correct. Before grischkas patch, and now, after your revert, gdb
does _not_ work correctly:
This is not true for the x86 systems. But yes: for x86_64 systems a
revert is needed. gdb in x86_64 systems (with current tcc) fails with
the same message as in the x86 (with the patch reverted).
home/matz/hello.c:
undefined main ()
{ /* 0x0 */
/* file /home/matz/hello.c line 5 addr 0x0 */
/* file /home/matz/hello.c line 5 addr 0xb */
/* file /home/matz/hello.c line 6 addr 0xb */
/* file /home/matz/hello.c line 7 addr 0x1f */
} /* 0x2b *
undefined main () is displayed in all cases (for me). But gdb works
(x86 system with the current tcc)
% objcopy -R .rela.stabs input output
This don't help.
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Straightening out x86_64 build?
I've glanced through the configure logic for this and I can't really understand how it's supposed to work. The configure scripts sets CONFIG_LDDIR, CONFIG_TCC_LIBPATHS, CONFIG_TCC_CRTPREFIX and CONFIG_MULTIARCHDIR, all of which might relate to how crt1.o is found, but what is the meaning or intended use of each of these variables? Are they all necessary? Two are set directly and only from configure's command line, but there is logic to set the other two automatically. Edmund ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] RE :Re: New test 73_arm64 hangs if ran on RPi
Hi, On Mon, 9 Mar 2015, Edmund Grimley Evans wrote: Michael Matz matz@frakked.de: And some more fixes for more tests in 73_arm64, namely stdarg passing of structs passed in purely integer registers. structs passed in fp regs or mixed int/fp regs are unfortunately not consecutive in the reg_save_area, and hence need temporary memory, but this requires some more involved changes in libtcc1. On arm64 a struct is sometimes not consecutive in memory. Code is generated in gen_va_arg() in arm64-gen.c to rearrange the data. I get more stack space using the global variable loc. Yes, I know. I just wanted to avoid having to open-code a va_arg in x86-64, it currently uses a C implementation from libtcc1. With that approach I can't allocate stack in the calling routine, of course, and would have to resort to a static buffer, which in turn would break multi-threaded use, or use malloc which would create a leak, or use malloc with reuse, which requires a global list, again creating multi-threaded problems :-/ Over that set of stones and hard places I went to bed. (I now think the only realistic option is indeed to generate va_arg from the backend). Ciao, Michael. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Your revert of a gdb-helping patch breaks gdb
By the way: after appling a patch CValue (replacing various integer types with int64_t) rhide works well independed of stabs behavior (with relocating stabs section and w/o this). What this means? ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] broken tcc build after latest git pull
2015-03-09 14:45 GMT+08:00 Sergey Korshunoff sey...@gmail.com: Hi! Please try to test the attached patch. With this patch applied building in MSYS is working again, thanks. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] broken tcc build after latest git pull
Hi! Please try to test the attached patch. configure-host-os.patch Description: Binary data ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Your revert of a gdb-helping patch breaks gdb
Hi,
On Mon, 9 Mar 2015, Sergey Korshunoff wrote:
This behavior may depend on the gdb version. I use a rhide v1.5 for
debuggin (i386, Linux). A gdb version embedded in it is 6.1.1
This version is more than ten years old.
And which version of the gdb you use?
Various ones, 7.3, 7.5.50, 7.8.
I think a tcc switch must be
introduced to select a stabs handling behavior.
I don't think so. I rather think we should do what a normal linker does
in this respect, and that's relocating the input sections. So you're
saying that a hello world compiled by gcc -gstabs (and linked by ld)
doesn't work in rhide? In that case rhide is simply buggy and needs
fixing. If it does work OTOH, then you should find out why and make tcc
emulate gcc+ld better.
PS: grishka don't explain in his patch why he change a behavior of the
previous patch.
Well, neither did you, but the way it's not working without relocated
.stabs is very obvious, as I showed in my mail. When not relocating
.stabs no program compiled by tcc -g will be debuggable in gdb.
On Mon, 9 Mar 2015, Sergey Korshunoff wrote:
By the way: after appling a patch CValue (replacing various integer
types with int64_t) rhide works well independed of stabs behavior
(with relocating stabs section and w/o this). What this means?
Sorry, this is not true. With grishka patch on rhide don't work.
So, what exactly doesn't work?
PS: You can test this itself (www.rhide.com)
Well, you want to use age-old software, so IMO it's you having the
burden of debugging your IDE. But some other hint: you can also use
objdump to inspect the debug output of tcc:
% objdump -g hello.broken
hello: file format elf64-x86-64
/home/matz/hello.c:
undefined main ()
{ /* 0x0 */
/* file /home/matz/hello.c line 5 addr 0x0 */
/* file /home/matz/hello.c line 5 addr 0xb */
/* file /home/matz/hello.c line 6 addr 0xb */
/* file /home/matz/hello.c line 7 addr 0x1f */
} /* 0x2b */
...
(That's a full executable). As you can see, the addresses are wrong by
starting at zero. A working executable shows this:
% objdump -g hello.ok
hello.ok: file format elf64-x86-64
/home/matz/hello.c:
undefined main ()
{ /* 0x400303 */
/* file /home/matz/hello.c line 5 addr 0x400303 */
/* file /home/matz/hello.c line 5 addr 0x40030e */
/* file /home/matz/hello.c line 6 addr 0x40030e */
/* file /home/matz/hello.c line 7 addr 0x400322 */
} /* 0x40032e */
...
I have one other idea, that _might_ be the cause for your problems: tcc
usually emits all input sections to the output, and that includes the
applied .rela.secname sections. So, in a way, the produced executables
contain the relocations twice: once in the target section, once in the
relocation section again. This is normally harmless (only dynamic
relocations are processed for executables, not those additional ones), but
possibly the old tools you use do apply them again.
You can check this if you remove that section: with a program
compiled/linked by a tcc with your revert reverted (i.e. relocated
.stabs), do this:
% objcopy -R .rela.stabs input output
If input isn't debuggable in rhide, but output is, then this is the
problem, and the right fix for tcc is to not emit those needless .rel(a)
sections in linked files.
Ciao,
Michael.
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
