On Wed, Sep 19, 2018 at 5:11 PM Julian Brown <jul...@codesourcery.com> wrote:
>
> On Fri, 14 Sep 2018 22:49:35 -0400
> Julian Brown <jul...@codesourcery.com> wrote:
>
> > > > On 12/09/18 16:16, Richard Biener wrote:
> > > > It may well be that there's a better way to solve the problem, or
> > > > at least to do the lookups.
> > > >
> > > > It may also be that there are some unintended consequences, such
> > > > as false name matches, but I don't know of any at present.
>
> > > Possibly, this was an abuse of these hooks, but it's arguably wrong
> > > that that e.g. handle_alias_pairs has the "assembler name" leak
> > > through into the user's source code -- if it's expected that the
> > > hook could make arbitrary transformations to the string. (The
> > > latter hook is only used by PE code for x86 at present, by the look
> > > of it, and the default handles only special-purpose mangling
> > > indicated by placing a '*' at the front of the symbol.)
>
> Two places I've found that currently expose the underlying symbol name
> in the user's source code: one (documented!) is C++, where one must
> write the mangled symbol name as the alias target:
>
> int foo (int c) { ... }
> int bar (int) __attribute__((alias("_Z3fooi")));
>
> another (perhaps obscure) is x86/PE with "fastcall":
>
> __attribute__((fastcall)) void foo(void) { ... }
> void bar(void) __attribute__((alias("@foo@0")));
>
> both of which probably suggest that using the decl name, rather than
> demangling the assembler name (or using some completely different
> solution) was the wrong thing to do.
>
> I'll keep thinking about this...Thanks, IIRC we already have some targets with quite complex renaming where I wonder iff uses like above work correctly. Btw, if you don't "fix" the handle_alias_paris code but keep your mangling what does break for you in practice (apart from maybe some testcases)? Richard. > Julian
