tinycc-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Tinycc-devel] [ RFC] About packing two infos in a long v2


From: grischka
Subject: Re: [Tinycc-devel] [ RFC] About packing two infos in a long v2
Date: Thu, 15 Nov 2012 15:24:39 +0100
User-agent: Thunderbird 2.0.0.23 (Windows/20090812)

address@hidden wrote:
In fact currently in tcc, GOT entries are all at least 4 bytes aligned. Indeed, s1->got->data_offset is always incremented by PTR_SIZE which is 4 or greater. Thus I could use the new structure unconditionnally and add a #if PTR_SIZE < 2 #error + a check in section_ptr_add to unsure we catch any changes of how GOT entries are aligned. That would make for a much smaller patch and more consistent situation.
>
> Any thought people?
>

To me that fiddling with unused bits looks too hackish even for tinycc.

Also, some place to store additional information with symbols might
be handy anyway.  For example the Windows backend currently abuses
the sym->st_other field to store the export/import attribute.

The problem is that the AttributeDef is not consequently stored
with the symbols.  Instead the sym->r field is abused to store
part of AttributeDef, and nothing is stored when the tcc "Sym"'s
are translated into the "Elf_Sym"'s.

So what about, in TCCState, instead of

    unsigned long *got_offsets;
    int nb_got_offsets;

switching to

    struct {
        unsigned long got_offset;
        unsigned some_attribute:X;
        <more ...>
    } *symbol_attributes:
   int nb_symbol_attributes;

By the way, why is the following code used in fill_got_entry:

offset = get_got_offset(s1, sym_index);
section_reserve(s1->got, offset + PTR_SIZE);

when section_ptr_add(s1->got, PTR_SIZE) would have the same effect?

I think that the effect WOULD be the same only if sym_index were always
greater by one than the previously passed.

--- grischka




reply via email to

[Prev in Thread] Current Thread [Next in Thread]