Re: [Tinycc-devel] sizeof (long double) vs sizeof (double)
Le dimanche 07 septembre 2014, 13:47:39 Mads a écrit : So basically, I should be able to get additional 2 bytes? And I suppose it will be stored as 12 bytes to maintain data structure alignment? LDOUBLE_SIZE is defined to be 16 so you should have 16 bytes for long double (twice that of double). Reading through the code as well as changelogs, x87 is indeed implemented, which means I should be able to use long double with higher precision than double. Correct me if I'm wrong, but shouldn't long double precision be like that declared in floats.h (see below __i386__ / __x86_64__ ). (sorry for the hassle, but long double as extended precision is a necessary evil for me). *From include\floats.h* /* horrible intel long double */ #if defined __i386__ || defined __x86_64__ #define LDBL_MANT_DIG 64 #define LDBL_DIG 18 #define LDBL_EPSILON 1.08420217248550443401e-19L #define LDBL_MIN_EXP (-16381) #define LDBL_MIN 3.36210314311209350626e-4932L #define LDBL_MIN_10_EXP (-4931) #define LDBL_MAX_EXP 16384 #define LDBL_MAX 1.18973149535723176502e+4932L #define LDBL_MAX_10_EXP 4932 #else /* same as IEEE double */ #define LDBL_MANT_DIG 53 #define LDBL_DIG 15 #define LDBL_EPSILON 2.2204460492503131e-16 #define LDBL_MIN_EXP (-1021) #define LDBL_MIN 2.2250738585072014e-308 #define LDBL_MIN_10_EXP (-307) #define LDBL_MAX_EXP 1024 #define LDBL_MAX 1.7976931348623157e+308 #define LDBL_MAX_10_EXP 308 #endif Except these don't seem to be used in tcc's code. It's probably for system headers only. But I just tried compiling a similar testcase as yours and it gives the correct sizeof (16). Can you show me the output of the configure script? Best regards, Thomas signature.asc Description: This is a digitally signed message part. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] [patch] tcc reports wrong file name for static inline functions
Le vendredi 12 septembre 2014, 17:50:08 Vadim Ushakov a écrit : The bug seems to be in decl0(). When it sees a static inline declaration, it _first_ reads the function body and _then_ saves the body and the file name in tcc_state-inline_fns. If the function is the last declaration, the parser pops the file from the stack after reading the function. After that, decl0() attempts to read file-filename and gets the name of the previous file in the stack. Thanks for the analysis, it helps reviewing the patch. The patch is: diff --git a/tccgen.c b/tccgen.c index 5fd127f..f1146db 100644 --- a/tccgen.c +++ b/tccgen.c @@ -6055,7 +6055,11 @@ static int decl0(int l, int is_for_loop_init) int block_level; struct InlineFunc *fn; const char *filename; - + +filename = file ? file-filename : ; +fn = tcc_malloc(sizeof *fn + strlen(filename)); +strcpy(fn-filename, filename); + tok_str_new(func_str); block_level = 0; @@ -6076,9 +6080,7 @@ static int decl0(int l, int is_for_loop_init) } tok_str_add(func_str, -1); tok_str_add(func_str, 0); -filename = file ? file-filename : ; -fn = tcc_malloc(sizeof *fn + strlen(filename)); -strcpy(fn-filename, filename); + fn-sym = sym; fn-token_str = func_str.str; dynarray_add((void ***)tcc_state-inline_fns, tcc_state-nb_inline_fns, fn); Looks good but please add a testcase. Maybe the example you showed us? Look at tests in test2. Best regards, Thomas signature.asc Description: This is a digitally signed message part. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Fallout from commit 01c041923474750a236da02561f0f8835445848b
Hi,
On Tue, 9 Sep 2014, Thomas Preud'homme wrote:
1) You added the support for R_ARM_GLOB_DAT and R_ARM_JUMP_SLOT
relocations but the computation you added ignore the possible addend at
*ptr by doing a simple assignment. Is that normal? Did I miss something?
This is per the ABI. The addend for both relocations (when using REL
form) is (and must be) always zero. I didn't bother checking for this,
but rather just ignored anything that was in there.
2) When creating a GOT and PLT entry for a R_ARM_PC24, R_ARM_CALL or
R_ARM_JUMP24 you add the offset of the PLT entry to the place being
relocated.
I'm not sure I got it right but it seems to me that the relocation will be
processed again in relocate_section and seems the symbol referenced is still
the target function (and not the PLT entry created) as the index in the
r_info
field of the relocation has remained unchanged. Also this put some relocation
computation in build_got_entries. Why not change the initial relocation to
make it resolve to the PLT entry.
It might be that I got some of the logic wrong, though I obviously did
check tcc on arm with itself (and IIRC gawk). I'll need to reproduce the
problem somewhen. Are you positive that it was my commit that broke it?
Hmm, or it might be that I also hit an error but somehow convinced myself
that it was a pre-existing but possibly hidden problem. Man, it's long
ago :)
3) I don't see any test for the type of output when deciding what type of
relocation to add. So even when the output is in memory reloc_type will be
JUMP_SLOT which will lead to a PLT entry being created. This seems to
contradict the comment near the end of put_got_entry. The comment seems wrong
as I don't see how a branch could be relocated without a PLT entry.
I think what I wanted to convey in the comment is the following situation:
normally with memory output (or static linking) no symbolic relocations
whatsoever are required in the executable, because, well, everything is
relocated from the beginning. But the means by which that is ensured is
itself (at least in TCCs link editor) by creating (and later processing)
relocations. Where it matters are indirect calls:
extern void f(void);
g() { void (*ptr)(void) = f; ptr(); }
Here there will be a GOT slot allocated for 'f'. The initialization of
'ptr' will load from that GOT slot. So even though direct calls to 'f'
can (and will be, when 'f' is defined) fully resolved without a PLT slot,
this indirect access needs a GOT slot, and because of that also needs to
initialize that slot with f's address, which is done by an relocation
(which are processed for static and memory output right at the end of most
processing).
4) the jump table that was removed in subsequent patch was only available
when
outputing to memory. But now a PLT and GOT entry is created no matter what
type of output (see 3) above).
Yes, PLT and GOT together (when unconditionally created) take over the
role of the old jump table.
Now obviously I bungled something regarding all that on ARM and will have
to look at the details. Let me first try to reproduce and I'll come back.
Ciao,
Michael.
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Fallout from commit 01c041923474750a236da02561f0f8835445848b
Hi, On Thu, 18 Sep 2014, Michael Matz wrote: Now obviously I bungled something regarding all that on ARM and will have to look at the details. Let me first try to reproduce and I'll come back. Hmm, current git TCC works for me on ARMv7 in a qemu-simulated chroot. I do have to configure with --with-libgcc (which is different from the debian buildlog you referenced), because my libc_nonshared.a references __aeabi_unwind_cpp_pr[01] . Probably I'd have to use that exact debian-based setup under qemu (my chroot is based on some openSUSE version), but I don't know a simple recipe for how. Any help appreciated. Ciao, Michael. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
