Re: [Tinycc-devel] Fallout from commit 01c041923474750a236da02561f0f8835

[Michael Matz]

Hi,

On Fri, 20 Feb 2015, Edmund Grimley Evans wrote:

> >   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,
>
> If f is in a library it may turn out not to be in range for a direct
> call.

Right.  But "defined" in tcc sense means defined in the .o/.c files 
taking part in the compilation, not in some shared library.  I.e. symbols 
that don't have SHN_UNDEF as st_shndx.  They are always reachable (as long 
as the programs text segment doesn't become too large, i.e. the usual 
"small" model when sizeof(.text) must be something < 1<<(some-bitsize)).

> > 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.
>
> You could try taking debootstrap from the Debian archive, unpacking it
> manually, and running it as root thus:
>
> .../debootstrap --arch armhf unstable .../chroots/arm64-unstable 
> http://ftp.debian.org/debian
>
> I've done that before for creating a Debian chroot on a non-Debian
> Linux machine. It's also what I use for creating a chroot for a
> different architecture, such as arm64 on i386 (with QEMU), or armhf on
> arm64 (without QEMU).

Yeah, something wasn't quite right with my qemu when I tried this last 
time in September.  Now it works.


Ciao,
Michael.