bug-binutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: andrew.jones at vector dot com
Subject: [Bug binutils/27865] New: Unsupported name-unmangling for C++20 modules?
Date: Fri, 14 May 2021 09:27:00 +0000

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:

```
0000000000000000 g     F .text  000000000000000b _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
```
0000000000000000 l     F .text  000000000000000b _ZL3moov
```

### Filtered
```
0000000000000000 l     F .text  000000000000000b moo()
```

Correct!


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

### Unfiltered
```
0000000000000000 l     F .text  000000000000000b _ZN12_GLOBAL__N_13mooEv
```

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

Correct!



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

### Unfiltered
```
0000000000000000 g     F .text  000000000000000b _ZN3moo3mooEv
```

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

Correct!


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

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

### Unfiltered
```
0000000000000000 l     O .bss   0000000000000001 _ZZ11_ZGIW3mooEvE9__in_chrg
0000000000000000 g     F .text  000000000000000b _Z3moov
000000000000000b g     F .text  0000000000000018 _ZGIW3mooEv
```

### Filtered
```
0000000000000000 l     O .bss   0000000000000001 _ZGIW3mooEv::__in_chrg
0000000000000000 g     F .text  000000000000000b moo()
000000000000000b g     F .text  0000000000000018 _ZGIW3mooEv
```

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


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

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

### Unfiltered
```
0000000000000000 l     O .bss   0000000000000001 _ZZ11_ZGIW3mooEvE9__in_chrg
0000000000000000 g     F .text  000000000000000b _ZW3mooE3moov
000000000000000b g     F .text  0000000000000018 _ZGIW3mooEv
```

### Filtered
```
0000000000000000 l     O .bss   0000000000000001 _ZGIW3mooEv::__in_chrg
0000000000000000 g     F .text  000000000000000b _ZW3mooE3moov
000000000000000b g     F .text  0000000000000018 _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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]