This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH 03/25] Improve TARGET_MANGLE_DECL_ASSEMBLER_NAME.


On Fri, 14 Sep 2018 22:49:35 -0400
Julian Brown <julian@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...

Julian


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]