Re: [patch bfd]: Adjust handling for plugin-generated sections for pe-coff targets

[Kai Tietz <ktietz70 at googlemail dot com>]

2011/10/10 Alan Modra <amodra@gmail.com>:
> On Sun, Oct 09, 2011 at 08:21:46PM +0200, Kai Tietz wrote:
>> So after some research I found the cause for this. ?As any global
>> symbol is visible from outside of claimed object realm, ?we can ease
>> for COFF is_visible_from_outside function in plugin.c file. ?As
>> visibility concepts isn't known to COFF targets too, none of the
>> checks within this functions are necessary.
>
> No, the function deals with IR symbols. ?See the comment, which says
> gcc does give you visibility on symbols for non-ELF targets. ?I'm
> quite certain you do not want is_visible_from_outside returning true
> for all symbols, but I don't know enough to tell you what you should
> be looking for. ?I suspect you may be fighting a gcc bug. ?Sorry, all
> I seem good for is saying "No"..
>
> --
> Alan Modra
> Australia Development Lab, IBM


No for function is_visible_from_outside comment explicit says "Return
TRUE if a defined symbol might be reachable from outside the  universe
of claimed objects.". Which means relation between IR and non-IR
objects.
As for COFF there is no model of visibility and see here comment about
visibility for non-ELF targets "On non-ELF targets, we can safely make
inferences by considering
	 what visibility the plugin would have liked to apply when it first
	 sent us the symbol.  During ELF symbol processing, visibility only
	 ever becomes more restrictive, not less, when symbols are merged,
	 so this is a conservative estimate; it may give false positives,
	 declaring something visible from outside when it in fact would
	 not have been, but this will only lead to missed optimisation
	 opportunities during LTRANS at worst; it will not give false
	 negatives, which can lead to the disastrous conclusion that the
	 related symbol is IRONLY.  (See GCC PR46319 for an example.) "
which explicit states that it is better to have a false-positive, then
to produce wrong IRONLY.

The problem this that wrongly IRONLY is used. So issue is related to
this problem, but for non-relocatable and non-shared of COFF targets.
For relocatable linking, this function returns always TRUE. For shared
it returns always TRUE as visibility is always LDPV_DEFAULT or
LPPV_PROTEXTED.  But for COFF it makes no difference, if you are
bulding shared or non-shared image.

Regards,
Kai