Re: [Tinycc-devel] Help with tcc_add_symbol // pe_find_import in 0.9.27

[grischka]

On 21.06.2022 12:38, Michael Richter wrote:
> Symbols are added in the form tcc_add_symbol (s,"tclStubsPtr", tclStubsPtr) where 
> &tclStubsptr refers to the adress of the internal pointer from the active Tcl 
> Interpreter. the stubstable is organized as a list of functionpointers, that are called 
> relative to tclStubsPtr (https://wiki.tcl-lang.org/page/Stubs for further info)
> With 0.9.27 this fails, wether with unkonwn symbol or, if I force tccpe to find 
> the symbol, the adress gets resolved in the wrong way and coredumps.

IIRC tcc from 0.9.27 on tries to help with a more explicit error message
made just for that case:

    tcc: error: undefined symbol 'xxxx', missing __declspec(dllimport)?

See also the libtcc_test.c example:

    /* this strinc is referenced by the generated code */
    const char hello[] = "Hello World!";

    char my_program[] =
    "..."
    "#ifdef _WIN32\n" /* dynamically linked data needs 'dllimport' */
    " __attribute__((dllimport))\n"
    "#endif\n"
    "extern const char hello[];\n"

    [...]
    tcc_add_symbol(s, "hello", hello);

FYI, the change was necessary with the introduction of 64-bit targets
to the effect that data objects that are resolved via tcc_add_symbol()
are now accessed by the same mechanism as those that come from dlls.

This mechanism needs special code to be generated already at compile
time which is what happens when tcc sees __declspec(dllimport) (and
does not otherwise).

-- grischka

> Further Info:
> - I used the last 0.9.27 stable from Fabrice Bellard 
> http://download.savannah.gnu.org/releases/tinycc/
> - I compile and test it under windows (ok, wine to be exact), but use -m32 
> WIN32 model to build the tcc4tcl.dll
> - Tcl version is 8.6.6
> Dumping the symboltable shows, that tclStubsPtr and tclIntStubsptr are in 
> dynsymtable.
> pe_find_import refuses to find the symbol, though sym_index >0, because the 
> tested conditions are true.
> (...)
>         sym_index = find_elf_sym(s1->dynsymtab_section, s);
>          if (sym_index
>              && ELFW(ST_TYPE)(sym->st_info) == STT_OBJECT // was stt_object
>              && 0 == (sym->st_other & ST_PE_IMPORT)
>              && 0 == a
>              ) err = -1, sym_index = 0;
> (...)
> If I hack this to return the sym_index, the linker will link and the linked adress 
> "looks" like it did in 0.9.26, but the resulting code coredumps, so something 
> is terribly wrong with this.
> I can't say, why the symbol gets sorted out. I don't kno, if the coredump comes 
> from a false conversion of the pointer adress or if the generated asm is 
> handling it wrongly. I'm stuck....
> Is anyone here able to point me in the right direction? Is there a patch im 
> missing?
> I can put up the modified code on github as a zip if anyone interested in 
> getting into the details :-)
> Is my problem clear enough or is there any helpful information missing?
> Michael
>
>
> _______________________________________________
> Tinycc-devel mailing list
> Tinycc-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel