[Bug binutils/27865] Unsupported name-unmangling for C++20 modules?

[andrew.jones at vector dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=27865

--- Comment #3 from Andrew V. Jones  ---
Hi Nick,

So, I did actually ask this on the GCC mailing list:

   https://gcc.gnu.org/pipermail/gcc/2021-May/236057.html

but I'm yet to receive a response.

I'd actually be totally fine to give a go at implementing this inside of
libiberty, but I don't actually know how the module function should be
demangled, to avoid ambiguity with the namespace case.

Are you aware of any other places where two (different) mangled names get
unmangled to the same thing?

Cheers,

Andrew

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug binutils/27865] Unsupported name-unmangling for C++20 modules?

[andrew.jones at vector dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=27865

--- Comment #1 from Andrew V. Jones  ---
It seems that this was implemented in GCC here:

*
https://github.com/gcc-mirror/gcc/commit/210d143dbc575f293affbd55417505bcb8257d74

with the BNF of the new mangling appearing here:

*
https://github.com/gcc-mirror/gcc/blob/f05627d404038368b99e92ac4df4c29f4ae4a5fa/gcc/cp/mangle.c#L865

I took a quick look at the binutils code (i.e., libiberty/cp-demangle.c), but
there appeared to be nothing to handle modules (e.g., the only use of 'W' was
in relation to `DEMANGLE_COMPONENT_TLS_WRAPPER`, which seems unrelated).

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug binutils/27865] New: Unsupported name-unmangling for C++20 modules?

[andrew.jones at vector dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=27865

Bug ID: 27865
   Summary: Unsupported name-unmangling for C++20 modules?
   Product: binutils
   Version: 2.37 (HEAD)
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: binutils
  Assignee: unassigned at sourceware dot org
  Reporter: andrew.jones at vector dot com
  Target Milestone: ---

# tl;dr:

When working with binutils with HEAD at 75f03fa7743, it seems that demangling
of C++20 module symbols doesn't work.

For example:

```
 g F .text  000b _ZW3mooE3moov
```

does not appear to have a demangling, while all other examples of "private"
entities (see below) do have a demangling.


These files have all been compiled with:

```
g++-11 --version
g++-11 (SUSE Linux) 11.0.0 20210208 (experimental) [revision
efcd941e86b507d77e90a1b13f621e036eacdb45]
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
```

# Examples:

## static.cpp
```
static int moo() { return 10; }
```

### Unfiltered
```
 l F .text  000b _ZL3moov
```

### Filtered
```
 l F .text  000b moo()
```

Correct!


## anon_ns.cpp
```
namespace {
int moo() { return 10; }
}
```

### Unfiltered
```
 l F .text  000b _ZN12_GLOBAL__N_13mooEv
```

### Filtered
```
 l F .text  000b (anonymous namespace)::moo()
```

Correct!



## namespace.cpp
```
namespace moo {
int moo() { return 10; }
} // namespace moo
```

### Unfiltered
```
 g F .text  000b _ZN3moo3mooEv
```

### Filtered
```
 g F .text  000b moo::moo()
```

Correct!


## module_with_export.cpp
```
export module moo;

export int moo() { return 10; }
```

### Unfiltered
```
 l O .bss   0001 _ZZ11_ZGIW3mooEvE9__in_chrg
 g F .text  000b _Z3moov
000b g F .text  0018 _ZGIW3mooEv
```

### Filtered
```
 l O .bss   0001 _ZGIW3mooEv::__in_chrg
 g F .text  000b moo()
000b g F .text  0018 _ZGIW3mooEv
```

Looks good, exported symbol appears like it is a global symbol.


## module_without_export.cpp
```
export module moo;

int moo() { return 10; }
```

### Unfiltered
```
 l O .bss   0001 _ZZ11_ZGIW3mooEvE9__in_chrg
 g F .text  000b _ZW3mooE3moov
000b g F .text  0018 _ZGIW3mooEv
```

### Filtered
```
 l O .bss   0001 _ZGIW3mooEv::__in_chrg
 g F .text  000b _ZW3mooE3moov
000b g F .text  0018 _ZGIW3mooEv
```

Hmm, so what's happening here? `_ZW3mooE3moov` appears to have no demangling. I
don't actually know what the demangling should be, but the fact that all of the
other examples of "private-esque" functions do have demanglings, suggests that
binutils should support a demangling of non-exported module functions.

GCC's ABI for modules appears at least partially documented here:
https://gcc.gnu.org/wiki/cxx-modules?action=AttachFile&do=view&target=module-abi-2017-09-01.pdf

-- 
You are receiving this mail because:
You are on the CC list for the bug.