[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Tinycc-devel] Cleanups
From: |
Thomas Preud'homme |
Subject: |
Re: [Tinycc-devel] Cleanups |
Date: |
Tue, 5 Feb 2013 14:56:12 +0100 |
User-agent: |
KMail/1.13.7 (Linux/3.2.0-4-amd64; KDE/4.8.4; x86_64; ; ) |
Le lundi 4 février 2013 20:51:29, grischka a écrit :
> Thomas Preud'homme wrote:
> >> 1) too many warnings "conversion from/to ptr <-> integer of different
> >> size"
> >>
> >> http://repo.or.cz/w/tinycc.git/commitdiff/82bcbd027f100d7601c6139e93e1f6
> >> 9a 9cc46244
> >
> > Why some uplong were replaced by uintptr_t?
>
> Well, that is with
> LIBTCCAPI int tcc_add_symbol(TCCState *s, const char *name, const void
> *val); to convert
> void *val -> elf-address.
>
> Because
> 1) I wanted to keep "void* val" in the prototype because it is LIBTCCAPI.
> 2) It is not TCC_IS_NATIVE only.
>
> So basically someone could use
> - an i386-libtcc.a (cross-compiler) made on x86-64
> with addr_t(32) and void*(64), or
>
> - an x86_64-libtcc.a (cross-compiler) made on i386/arm
> with addr_t(64) but void*(32)
> Which still wont work if the upper 32 bits are used, which
> they usually aren't as long as no relocation was made, but
> I'm not sure.
>
> Of course you can't run something with such libtcc.a but you
> could still use tcc_output_file.
>
> Technically perfect would be to change the prototype to accept
> a target address sized integer (addr_t). Respectively return
> with tcc_get_symbol which has a similar problem.
>
> But this then requires casts in the user code (e.g. libtcc_test.c)
> and probably would make some people cry.
>
> --- grischka
It makes perfect sense. Thanks for the explaination.
Thomas
signature.asc
Description: This is a digitally signed message part.
Re: [Tinycc-devel] Cleanups, grischka, 2013/02/04
- Re: [Tinycc-devel] Cleanups,
Thomas Preud'homme <=