Re: [patches] Re: KDE a gcc

[Jan Hubicka <jh@suse.cz>]

> As the patch is missing, I cannot comment on it, but only guess.
> Is .data.rel for R/W data which need relocations?
> I had in mind .data.ro.rel and .data.ro.localrel where the former would be
> R/O data which is expected to have dynamic relocation while the latter would
> be for R/O data which is expected to have just relative relocations.

By relative relocation you I guess you don't mean PC_REL...
> E.g. in
> extern char foo[];
> char * const p[] = { foo };
> char * const q[] = { "foo" };
> p would go into .data.ro.rel and q into .data.ro.localrel.

Hmm, so you mean reference to static data should be handled even more differently?
I guess I can easilly add it, as we note the static labelref anyway, but it will
need more changes to the SELECT_SECTION.

I guess this can be done as followup patch.
So to sumarize we want:
1) have all data with references together for non-prelinking dynlinking
2) have all read only data with local references together for dynlinking

So we need .data.rel, .data.rel.ro and .data.rel.ro.local
or whatever we want to name it. Sounds sane?

Honza

> For prelinking, the advantage would be that data which would be never
> relocated would be put together (there will be just a R_*_RELATIVE reloc
> against q and prelinked libs are already relocated to the address they will
> be mapped to (unless something gets in the way)), while .data.ro.rel might
> be runtime relocated.
> 
> 	Jakub