[PATCH] Select new undefined atom rather than old one if other conditions are the same.

Rui Ueyama ruiu at google.com
Thu Nov 14 17:37:54 PST 2013


On Thu, Nov 14, 2013 at 4:53 PM, kledzik at apple.com <kledzik at apple.com>wrote:

>
>   I understand the need to check that the fallback is not being changed or
> lost, but why change the behavior to keep switching to newer undefines?  In
> the current impl, if there are bunch of .o files and each one has an
> undefine for _malloc, the UndefinedAtom from the first .o file will be put
> in the symbol table, and the rest will entered in the the replacement map
> to be replaced by the first.  If instead you keep changing the symbol table
> entry for malloc when processing each .o file, you get a long chain in the
> replacement map where the first UndefinedAtom is to be replaced by the
> second which is to be replaced by the third, etc.
>
>   Seems to me there are three steps here:
>   1) warn if the new and current undefined atoms have different can-be-null
>   2) warn if the new and current undefined atoms have different fallback
> names
>   3) only switch the current undefined atom to be another one if it is
> "better" (has fallback or can't be null).
>

These steps make sense, it's better to avoid making a long chain in the
replacement map. Thank you for the suggestion. I'll update the patch as you
suggested.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20131114/2c4ac86a/attachment.html>


More information about the llvm-commits mailing list