[ISSUE] gdb can't step in libstdc++

[ISSUE] gdb can't step in libstdc++

[meator]

[-- Attachment #1: Type: text/plain, Size: 1762 bytes --]

New issue by meator on void-packages repository

https://github.com/void-linux/void-packages/issues/49207

Description:
### Is this a new report?

Yes

### System Info

Void 6.6.18_1 x86_64 GenuineIntel uptodate hold rrrdDFFFFFFFFFFFFFFFFFFFFFFFFFFFF

### Package(s) Affected

libstdc++-13.2.0_2 libstdc++-devel-13.2.0_2 libstdc++-dbg-13.2.0_2

### Does a report exist for this bug with the project's home (upstream) and/or another distro?

_No response_

### Expected behaviour

Everything being all right.

### Actual behaviour

I have the following program:

```c++
#include <string>

int main() {
    std::string{std::string{}};
}
```

When I compile it with

```
g++ -ggdb main.cpp
```

, debug it with `gdb` and try to step in the fourth line, I get
```
std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string (this=0x7fffffffe590)
    at ./build/x86_64-unknown-linux-gnu/libstdc++-v3/include/bits/basic_string.h:512
warning: 512	./build/x86_64-unknown-linux-gnu/libstdc++-v3/include/bits/basic_string.h: No such file or directory
```

`gdb` is trying to look into `./build/x86_64-unknown-linux-gnu/libstdc++-v3/include/bits/basic_string.h`, but it should be looking in `/usr/include/c++/13.2/bits/basic_string.h`.

This looks like `./build/x86_64-unknown-linux-gnu/libstdc++-v3/include/bits/basic_string.h` was the path in the build step of `libstdc++` (which is a subpackage of `gcc`) in the masterdir. This path doesn't match the path in a real installed system, which rightfully confuses gdb.

### Steps to reproduce

I have first created this recording with slightly different code and it was intended for `#voidlinux`, but it is still relevant and useful: https://asciinema.org/a/646146

Re: gdb can't step in libstdc++

[meator]

[-- Attachment #1: Type: text/plain, Size: 289 bytes --]

New comment by meator on void-packages repository

https://github.com/void-linux/void-packages/issues/49207#issuecomment-1986976682

Comment:
@classabbyamp suggested on `#voidlinux` that `gcc`'s template might have `-ffile-prefix-map` missing. This is likely the solution to this problem.

Re: gdb can't step in libstdc++

[oreo639]

[-- Attachment #1: Type: text/plain, Size: 1212 bytes --]

New comment by oreo639 on void-packages repository

https://github.com/void-linux/void-packages/issues/49207#issuecomment-1986998038

Comment:
This issue is labeled as gdb not being able to step inside libstdc++ (which occurs per-instruction), but your issue appears to be that the file paths shown are the ones from build time? Am I misunderstanding?

Showing `/usr/include/c++/13.2/bits/basic_string.h` would not be correct in this instance since the debug symbols can also point to cpp files. The correct generalized path would be smth like `/usr/sources/libstdc++/...` which isn't supported by void since we don't have `-src` packages.

gdb supports a substitute path for this purpose:
https://sourceware.org/gdb/current/onlinedocs/gdb.html/Source-Path.html#set-substitute_002dpath

> suggested on `#voidlinux` that `gcc`'s template might have `-ffile-prefix-map` missing. This is likely the solution to this problem.

The opposite is the case, the `-ffile-prefix-map` is getting passed and is set up such that the wrksrc is replaced with `./`.
https://github.com/void-linux/void-packages/blob/7771ef865fa7b5312892b8c53dbfbc459cfdfd41/common/environment/configure/debug-debug-prefix-map.sh#L12-L13

Re: gdb can't step in libstdc++

[oreo639]

[-- Attachment #1: Type: text/plain, Size: 1383 bytes --]

New comment by oreo639 on void-packages repository

https://github.com/void-linux/void-packages/issues/49207#issuecomment-1986998038

Comment:
This issue is labeled as gdb not being able to step inside libstdc++ (which occurs per-instruction), but your issue appears to be that the file paths shown are the ones from build time? Am I misunderstanding? (stepping, either per-instruction, or per function doesn't require the presence of the source files, the source files are just so it can display the line of code for you)

Showing `/usr/include/c++/13.2/bits/basic_string.h` would not be correct in this instance since the debug symbols can also point to cpp files. The correct generalized path would be smth like `/usr/sources/libstdc++/...` which isn't supported by void since we don't have `-src` packages.

gdb supports a substitute path for this purpose:
https://sourceware.org/gdb/current/onlinedocs/gdb.html/Source-Path.html#set-substitute_002dpath

> suggested on `#voidlinux` that `gcc`'s template might have `-ffile-prefix-map` missing. This is likely the solution to this problem.

The opposite is the case, the `-ffile-prefix-map` is getting passed and is set up such that the wrksrc is replaced with `./`.
https://github.com/void-linux/void-packages/blob/7771ef865fa7b5312892b8c53dbfbc459cfdfd41/common/environment/configure/debug-debug-prefix-map.sh#L12-L13

Re: gdb can't step in libstdc++

[oreo639]

[-- Attachment #1: Type: text/plain, Size: 1384 bytes --]

New comment by oreo639 on void-packages repository

https://github.com/void-linux/void-packages/issues/49207#issuecomment-1986998038

Comment:
This issue is labeled as gdb not being able to step inside libstdc++ (which occurs per-instruction), but your issue appears to be that the file paths shown are the ones from build time? Am I misunderstanding?
(stepping, either per-instruction, or per function doesn't require the presence of the source files, the source files are just so it can display the line of code for you)

Showing `/usr/include/c++/13.2/bits/basic_string.h` would not be correct in this instance since the debug symbols can also point to cpp files. The correct generalized path would be smth like `/usr/sources/libstdc++/...` which isn't supported by void since we don't have `-src` packages.

gdb supports a substitute path for this purpose:
https://sourceware.org/gdb/current/onlinedocs/gdb.html/Source-Path.html#set-substitute_002dpath

> suggested on `#voidlinux` that `gcc`'s template might have `-ffile-prefix-map` missing. This is likely the solution to this problem.

The opposite is the case, the `-ffile-prefix-map` is getting passed and is set up such that the wrksrc is replaced with `./`.
https://github.com/void-linux/void-packages/blob/7771ef865fa7b5312892b8c53dbfbc459cfdfd41/common/environment/configure/debug-debug-prefix-map.sh#L12-L13

Re: gdb can't step in libstdc++

[oreo639]

[-- Attachment #1: Type: text/plain, Size: 1380 bytes --]

New comment by oreo639 on void-packages repository

https://github.com/void-linux/void-packages/issues/49207#issuecomment-1986998038

Comment:
This issue is labeled as gdb not being able to step inside libstdc++ (which occurs per-instruction), but your issue appears to be that the file paths shown are the ones from build time? Am I misunderstanding?
(stepping, either per-instruction, or per function doesn't require the presence of the source files, the source files are just so it can display the line of code for you)

Showing `/usr/include/c++/13.2/bits/basic_string.h` would not be correct in this instance since the debug symbols can also point to cpp files. The correct generalized path would be smth like `/usr/src/libstdc++/...` which isn't supported by void since we don't have `-src` packages.

gdb supports a substitute path for this purpose:
https://sourceware.org/gdb/current/onlinedocs/gdb.html/Source-Path.html#set-substitute_002dpath

> suggested on `#voidlinux` that `gcc`'s template might have `-ffile-prefix-map` missing. This is likely the solution to this problem.

The opposite is the case, the `-ffile-prefix-map` is getting passed and is set up such that the wrksrc is replaced with `./`.
https://github.com/void-linux/void-packages/blob/7771ef865fa7b5312892b8c53dbfbc459cfdfd41/common/environment/configure/debug-debug-prefix-map.sh#L12-L13

Re: gdb can't step in libstdc++

[oreo639]

[-- Attachment #1: Type: text/plain, Size: 1389 bytes --]

New comment by oreo639 on void-packages repository

https://github.com/void-linux/void-packages/issues/49207#issuecomment-1986998038

Comment:
This issue is labeled as gdb not being able to step inside libstdc++ (which occurs per-instruction), but your issue appears to be that the file paths shown are the ones from build time? Am I misunderstanding?
(stepping, either per-instruction, or per function doesn't require the presence of the source files, the source files are just so it can display the line of code for you)

Showing `/usr/include/c++/13.2/bits/basic_string.h` would not be correct in this instance since the debug symbols can also point to cpp files. The correct generalized path would be smth like `/usr/src/libstdc++-13.2.0_1/...` which isn't supported by void since we don't have `-src` packages.

gdb supports a substitute path for this purpose:
https://sourceware.org/gdb/current/onlinedocs/gdb.html/Source-Path.html#set-substitute_002dpath

> suggested on `#voidlinux` that `gcc`'s template might have `-ffile-prefix-map` missing. This is likely the solution to this problem.

The opposite is the case, the `-ffile-prefix-map` is getting passed and is set up such that the wrksrc is replaced with `./`.
https://github.com/void-linux/void-packages/blob/7771ef865fa7b5312892b8c53dbfbc459cfdfd41/common/environment/configure/debug-debug-prefix-map.sh#L12-L13

Re: gdb can't step in libstdc++

[oreo639]

[-- Attachment #1: Type: text/plain, Size: 1384 bytes --]

New comment by oreo639 on void-packages repository

https://github.com/void-linux/void-packages/issues/49207#issuecomment-1986998038

Comment:
This issue is labeled as gdb not being able to step inside libstdc++ (which occurs per-instruction), but your issue appears to be that the file paths shown are the ones from build time? Am I misunderstanding?
(stepping, either per-instruction, or per function doesn't require the presence of the source files, the source files are just so it can display the line of code for you)

Showing `/usr/include/c++/13.2/bits/basic_string.h` would not be correct in this instance since the debug symbols can also point to cpp files. The correct generalized path would be smth like `/usr/src/libstdc++-13.2.0_1/...` which isn't done by void since we don't have `-src` packages.

gdb supports a substitute path for this purpose:
https://sourceware.org/gdb/current/onlinedocs/gdb.html/Source-Path.html#set-substitute_002dpath

> suggested on `#voidlinux` that `gcc`'s template might have `-ffile-prefix-map` missing. This is likely the solution to this problem.

The opposite is the case, the `-ffile-prefix-map` is getting passed and is set up such that the wrksrc is replaced with `./`.
https://github.com/void-linux/void-packages/blob/7771ef865fa7b5312892b8c53dbfbc459cfdfd41/common/environment/configure/debug-debug-prefix-map.sh#L12-L13

Re: gdb can't step in libstdc++

[meator]

[-- Attachment #1: Type: text/plain, Size: 504 bytes --]

New comment by meator on void-packages repository

https://github.com/void-linux/void-packages/issues/49207#issuecomment-1987110066

Comment:
So

```
std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string (this=0x7fffffffe590)
    at ./build/x86_64-unknown-linux-gnu/libstdc++-v3/include/bits/basic_string.h:512
warning: 512	./build/x86_64-unknown-linux-gnu/libstdc++-v3/include/bits/basic_string.h: No such file or directory
```

is the intended behavior?

Re: gdb can't step in libstdc++

[meator]

[-- Attachment #1: Type: text/plain, Size: 716 bytes --]

New comment by meator on void-packages repository

https://github.com/void-linux/void-packages/issues/49207#issuecomment-1987110066

Comment:
So

```
std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string (this=0x7fffffffe590)
    at ./build/x86_64-unknown-linux-gnu/libstdc++-v3/include/bits/basic_string.h:512
warning: 512	./build/x86_64-unknown-linux-gnu/libstdc++-v3/include/bits/basic_string.h: No such file or directory
```

is the intended behavior?

My issue might not have been worded exactly. You are correct, gdb can step into whatever it wants to, but here it can't display the code. The warning, especially for a file that is on my system, concerned me.

Re: gdb can't step in libstdc++

[oreo639]

[-- Attachment #1: Type: text/plain, Size: 671 bytes --]

New comment by oreo639 on void-packages repository

https://github.com/void-linux/void-packages/issues/49207#issuecomment-1987116052

Comment:
> is the intended behavior?

I can't speak for what the other Void maintainers intend, but afaict it is working as it is written. In this case, you can use substitute-path to fix the locations for the includes.
For source files you can can download the un-patched sources from https://sources.voidlinux.org (this won't include patches and compile-time generated files though, so be aware of that. For example, the header in this instance is a compile-time generated file.)
Ofc you can also use `disas` to see the assembly. 

Re: gdb can't step in libstdc++

[oreo639]

[-- Attachment #1: Type: text/plain, Size: 914 bytes --]

New comment by oreo639 on void-packages repository

https://github.com/void-linux/void-packages/issues/49207#issuecomment-1987116052

Comment:
> is the intended behavior?

I can't speak for what the other Void maintainers intend, but afaict it is working as it is written. In this case, you can use substitute-path to fix the locations for the includes.
For source files you can can download the un-patched sources from https://sources.voidlinux.org (this won't include patches and compile-time generated files though, so be aware of that. For example, the header in this instance is a compile-time generated file.)
Ofc you can also use `disas` to see the assembly. 

Arch Linux, for example, uses debugedit to generate a list of source files referenced in the debug symbols to add them to the dbg packages: https://gitlab.archlinux.org/pacman/pacman/-/blob/master/scripts/libmakepkg/tidy/strip.sh.in#L38-53

Re: gdb libstdc++ frame gives warning: <line> <file>.h: No such file or directory

[oreo639]

[-- Attachment #1: Type: text/plain, Size: 196 bytes --]

New comment by oreo639 on void-packages repository

https://github.com/void-linux/void-packages/issues/49207#issuecomment-1987119438

Comment:
I updated the title, let me know if it is incorrect.

Re: gdb libstdc++ frame gives warning: <line> <file>.h: No such file or directory

[oreo639]

[-- Attachment #1: Type: text/plain, Size: 921 bytes --]

New comment by oreo639 on void-packages repository

https://github.com/void-linux/void-packages/issues/49207#issuecomment-1987116052

Comment:
> is the intended behavior?

I can't speak for what the other Void maintainers intend, but afaict it is working as it is written. In this case, you can use substitute-path to fix the locations for the includes.
For source files you can can download the un-patched sources from https://sources.voidlinux.org (this won't include patches and compile-time generated files though, so be aware of that. For example, the header in this instance is a compile-time generated file.)
Ofc you can also use `disas` in gdb to see the assembly. 

Arch Linux, for example, uses debugedit to generate a list of source files referenced in the debug symbols to add them to the dbg packages: https://gitlab.archlinux.org/pacman/pacman/-/blob/master/scripts/libmakepkg/tidy/strip.sh.in#L38-53

Re: gdb libstdc++ frame gives warning: <line> <file>.h: No such file or directory

[oreo639]

[-- Attachment #1: Type: text/plain, Size: 955 bytes --]

New comment by oreo639 on void-packages repository

https://github.com/void-linux/void-packages/issues/49207#issuecomment-1987116052

Comment:
> is the intended behavior?

I can't speak for what the other Void maintainers intend, but afaict it is working as it is written. In this case, you can use substitute-path to fix the locations for the includes.
For source files you can can download the un-patched sources from https://sources.voidlinux.org (this won't include patches and compile-time generated files though, so be aware of that. For example, the header in this instance is a compile-time generated file.)
Ofc you can also use `disas` in gdb to see the assembly. 

Arch Linux, for example, uses debugedit to generate a list of source files referenced in the debug symbols to add them to the dbg packages: https://gitlab.archlinux.org/pacman/pacman/-/blob/d55b47e5512808b67bc944feb20c2bcc6c1a4c45/scripts/libmakepkg/tidy/strip.sh.in#L38-53

Re: [ISSUE] [CLOSED] gdb libstdc++ frame gives warning: <line> <file>.h: No such file or directory

[ahesford]

[-- Attachment #1: Type: text/plain, Size: 1934 bytes --]

Closed issue by meator on void-packages repository

https://github.com/void-linux/void-packages/issues/49207

Description:
### Is this a new report?

Yes

### System Info

Void 6.6.18_1 x86_64 GenuineIntel uptodate hold rrrdDFFFFFFFFFFFFFFFFFFFFFFFFFFFF

### Package(s) Affected

libstdc++-13.2.0_2 libstdc++-devel-13.2.0_2 libstdc++-dbg-13.2.0_2

### Does a report exist for this bug with the project's home (upstream) and/or another distro?

_No response_

### Expected behaviour

Everything being all right.

### Actual behaviour

I have the following program:

```c++
#include <string>

int main() {
    std::string{std::string{}};
}
```

When I compile it with

```
g++ -ggdb main.cpp
```

, debug it with `gdb` and try to step in the fourth line, I get
```
std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string (this=0x7fffffffe590)
    at ./build/x86_64-unknown-linux-gnu/libstdc++-v3/include/bits/basic_string.h:512
warning: 512	./build/x86_64-unknown-linux-gnu/libstdc++-v3/include/bits/basic_string.h: No such file or directory
```

`gdb` is trying to look into `./build/x86_64-unknown-linux-gnu/libstdc++-v3/include/bits/basic_string.h`, but it should be looking in `/usr/include/c++/13.2/bits/basic_string.h`.

This looks like `./build/x86_64-unknown-linux-gnu/libstdc++-v3/include/bits/basic_string.h` was the path in the build step of `libstdc++` (which is a subpackage of `gcc`) in the masterdir. This path doesn't match the path in a real installed system, which rightfully confuses gdb.

I have `libstdc++-13.2.0_2` `libstdc++-devel-13.2.0_2` and `libstdc++-dbg-13.2.0_2` installed, so I shouldn't be lacking debugging symbols.

### Steps to reproduce

I have first created this recording with slightly different code and it was intended for `#voidlinux`, but it is still relevant and useful: https://asciinema.org/a/646146

Re: gdb libstdc++ frame gives warning: <line> <file>.h: No such file or directory

[ahesford]

[-- Attachment #1: Type: text/plain, Size: 1316 bytes --]

New comment by ahesford on void-packages repository

https://github.com/void-linux/void-packages/issues/49207#issuecomment-1997266231

Comment:
This is definitely not a bug, but an expected consequence of our decision (implicit or otherwise) not to include source in debug packages.

I don't believe shipping source in debug packages is a good idea in general. There are a number of reasons why people might want debug symbols, but in many cases, also having the source sitting around may not be necessary or particularly useful. Having source available for this kinds of things should be an extra opt-in. We don't have a mechanism for that except shipping `-src` packages, which I'm sure nobody wants to do.

If you just need some context for debugging your own stuff, it's easy enough to `./xbps-src -I patch <pkg>` and look through the source. If you're actually trying to debug packaged software, this may be a bit more cumbersome, but there are probably better ways to debug and test packaged software than by trying to use only the packages.

Also note that the generated nature of the header in your example would pose substantial challenges to properly accumulating the source for distribution anyway.

I'm marking this WONTFIX; if any Void member wishes to reopen for more discussion, please do so.

Re: gdb libstdc++ frame gives warning: <line> <file>.h: No such file or directory

[meator]

[-- Attachment #1: Type: text/plain, Size: 210 bytes --]

New comment by meator on void-packages repository

https://github.com/void-linux/void-packages/issues/49207#issuecomment-1997996689

Comment:
Thanks for the explanation! I understand why was this issue closed.