[Bug tree-optimization/111073] [13/14/15 regression] False-positive -Wstringop-overflow when building gdb from trunk with -D_GLIBCXX_ASSERTIONS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111073 --- Comment #5 from Simon Marchi --- Created attachment 58840 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58840&action=edit creduced example To build the creduced example: $ g++ -x c++ -Wall -Werror -g3 -O2 -c creduced.cpp Note that I didn't include -D_GLIBCXX_DEBUG here. I still see the error, perhaps it means my libstdc++ has _GLIBCXX_ASSERTIONS enabled by default like Sam, not sure. There are a bunch of other errors, but the last one is the same as I pasted before: creduced.cpp:45:24: error: ‘void* __builtin_memmove(void*, const void*, long unsigned int)’ forming offset 16 is out of the bounds [0, 16] [-Werror=array-bounds=] 45 | __builtin_memmove(db, cm, sizeof(c) * dc); | ~^~~~ Note: I don't know if this is actually a bug, I don't understand what's going on, it just looks like one of those -Warray-bounds false positives. And if it's not a -Warray-bounds bug, then it means it's probably a libstdc++ bug, so a bug either way.
[Bug tree-optimization/111073] [13/14/15 regression] False-positive -Wstringop-overflow when building gdb from trunk with -D_GLIBCXX_ASSERTIONS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111073 Simon Marchi changed: What|Removed |Added CC||simon.marchi at polymtl dot ca --- Comment #4 from Simon Marchi --- I have a similar one from GDB. It's -Warray-bounds, not -Wstringop-overflow, but the symptoms are really similar (needs _GLIBCXX_ASSERTIONS/_GLIBCXX_DEBUG, error reported at same line): $ g++ -x c++-I. -I/home/smarchi/src/wt/amd/gdb -I/home/smarchi/src/wt/amd/gdb/config -include /home/smarchi/src/wt/amd/gdb/defs.h -DLOCALEDIR="\"/tmp/roc-gdb/share/locale\"" -DHAVE_CONFIG_H -I/home/smarchi/src/wt/amd/gdb/../include/opcode -I../bfd -I/home/smarchi/src/wt/amd/gdb/../bfd -I/home/smarchi/src/wt/amd/gdb/../include -I/home/smarchi/src/wt/amd/gdb/../readline/readline/.. -I../libdecnumber -I/home/smarchi/src/wt/amd/gdb/../libdecnumber -I/home/smarchi/src/wt/amd/gdb/../gnulib/import -I../gnulib/import -I/home/smarchi/src/wt/amd/gdb/.. -I.. -I/home/smarchi/src/wt/amd/gdb/../libbacktrace/ -I../libbacktrace/ -DTUI=1 -I/usr/include/python3.12 -I/usr/include/python3.12 -I/home/smarchi/src/wt/amd/gdb/.. -pthread -I/tmp/roc-gdb/share/pkgconfig/../../include -Wall -Wpointer-arith -Wno-unused -Wunused-value -Wunused-variable -Wunused-function -Wno-switch -Wno-char-subscripts -Wempty-body -Wunused-but-set-parameter -Wunused-but-set-variable -Wno-sign-compare -Wno-error=maybe-uninitialized -Wno-mismatched-tags -Wsuggest-override -Wimplicit-fallthrough=5 -Wduplicated-cond -Wshadow=local -Wdeprecated-copy -Wdeprecated-copy-dtor -Wredundant-move -Wmissing-declarations -Wstrict-null-sentinel -Wvla -Wformat -Wformat-nonliteral -Werror -g3 -O2 -fmax-errors=1 -fdiagnostics-color=always -fsanitize=address -D_GLIBCXX_DEBUG=1 -c -o symfile.o -MT symfile.o -MMD -MP -MF ./.deps/symfile.Tpo /home/smarchi/src/wt/amd/gdb/symfile.c In file included from /usr/include/c++/13/bits/hashtable_policy.h:36, from /usr/include/c++/13/bits/hashtable.h:35, from /usr/include/c++/13/bits/unordered_map.h:33, from /usr/include/c++/13/unordered_map:41, from /usr/include/c++/13/functional:63, from /home/smarchi/src/wt/amd/gdb/../gdbsupport/ptid.h:35, from /home/smarchi/src/wt/amd/gdb/../gdbsupport/common-defs.h:197, from /home/smarchi/src/wt/amd/gdb/defs.h:27, from : In static member function ‘static _Up* std::__copy_move<_IsMove, true, std::random_access_iterator_tag>::__copy_m(_Tp*, _Tp*, _Up*) [with _Tp = const add_symbol_file_command(const char*, int)::sect_opt; _Up = add_symbol_file_command(const char*, int)::sect_opt; bool _IsMove = false]’, inlined from ‘_OI std::__copy_move_a2(_II, _II, _OI) [with bool _IsMove = false; _II = const add_symbol_file_command(const char*, int)::sect_opt*; _OI = add_symbol_file_command(const char*, int)::sect_opt*]’ at /usr/include/c++/13/bits/stl_algobase.h:506:30, inlined from ‘_OI std::__copy_move_a1(_II, _II, _OI) [with bool _IsMove = false; _II = const add_symbol_file_command(const char*, int)::sect_opt*; _OI = add_symbol_file_command(const char*, int)::sect_opt*]’ at /usr/include/c++/13/bits/stl_algobase.h:533:42, inlined from ‘_OI std::__copy_move_a(_II, _II, _OI) [with bool _IsMove = false; _II = const add_symbol_file_command(const char*, int)::sect_opt*; _OI = add_symbol_file_command(const char*, int)::sect_opt*]’ at /usr/include/c++/13/bits/stl_algobase.h:540:31, inlined from ‘_OI std::copy(_II, _II, _OI) [with _II = const add_symbol_file_command(const char*, int)::sect_opt*; _OI = add_symbol_file_command(const char*, int)::sect_opt*]’ at /usr/include/c++/13/bits/stl_algobase.h:633:7, inlined from ‘static _ForwardIterator std::__uninitialized_copy::__uninit_copy(_InputIterator, _InputIterator, _ForwardIterator) [with _InputIterator = const add_symbol_file_command(const char*, int)::sect_opt*; _ForwardIterator = add_symbol_file_command(const char*, int)::sect_opt*]’ at /usr/include/c++/13/bits/stl_uninitialized.h:147:27, inlined from ‘_ForwardIterator std::uninitialized_copy(_InputIterator, _InputIterator, _ForwardIterator) [with _InputIterator = const add_symbol_file_command(const char*, int)::sect_opt*; _ForwardIterator = add_symbol_file_command(const char*, int)::sect_opt*]’ at /usr/include/c++/13/bits/stl_uninitialized.h:185:15, inlined from ‘_ForwardIterator std::__uninitialized_copy_a(_InputIterator, _InputIterator, _ForwardIterator, allocator<_Tp>&) [with _InputIterator = const add_symbol_file_command(const char*, int)::sect_opt*; _ForwardIterator = add_symbol_file_command(const char*, int)::sect_opt*; _Tp = add_symbol_file_command(const char*, int)::sect_opt]’ at /usr/include/c++/13/bits/stl_uninitialized.h:373:37, inlined from ‘void std::__cxx1998::vector<_Tp, _Alloc>::_M_range_initialize(_ForwardIt
[Bug c++/113599] New: Wrong computation of member offset through pointer-to-member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113599
Bug ID: 113599
Summary: Wrong computation of member offset through
pointer-to-member
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: simon.marchi at polymtl dot ca
Target Milestone: ---
This commit:
c++: non-dependent .* operand folding [PR112427]
https://gitlab.com/gnutools/gcc/-/commit/d3f48f68227
seems to cause a regression in some cases when computing the address of a
member using a pointer-to-member.
Origin: https://sourceware.org/bugzilla/show_bug.cgi?id=31281
I made this reproducer, which was then made more minimal by Tom de Vries. We
get the address of the thread_info::node field in two different ways. One
using through a pointer-to-member, the other is getting its address directly.
We expect both to be equal. gcc 14/trunk gets it wrong.
...
struct intrusive_list_node {
void *next;
};
struct dummy {
void *base;
};
struct thread_info : public dummy, public intrusive_list_node {
intrusive_list_node node;
};
static thread_info ti;
int main (void) {
auto thread_info::*MemberNode = &thread_info::node;
auto node_ptr_1 = &(ti.*MemberNode);
auto node_ptr_2 = &ti.node;
return !(node_ptr_1 == node_ptr_2);
}
...
gcc-13:
...
$ g++ test.cpp; ./a.out; echo $?
0
...
gcc-14:
...
$ g++ test.cpp; ./a.out; echo $?
1
...
[Bug c++/111374] New: Spurious -Warray-bounds warning when building std::vector (or libstdc++ bug?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111374 Bug ID: 111374 Summary: Spurious -Warray-bounds warning when building std::vector (or libstdc++ bug?) Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: simon.marchi at polymtl dot ca Target Milestone: --- I encountered what seems to be either an invalid -Warray-bounds warning, or a bug in libstdc++. I see it when compiling file gdb/d-lang.c in binutils-gdb (at -O2). I wasn't able to make a small reproducer, unfortunately. I tested with gcc master (commit 316d57da5bb9205b946afc56d78582fee874e4b5). $ /opt/gcc/git/bin/g++ -x c++-I. -I/home/smarchi/src/binutils-gdb/gdb -I/home/smarchi/src/binutils-gdb/gdb/config -DLOCALEDIR="\"/opt/gdb/git/share/locale\"" -DHAVE_CONFIG_H -I/home/smarchi/src/binutils-gdb/gdb/../include/opcode -I../bfd -I/home/smarchi/src/binutils-gdb/gdb/../bfd -I/home/smarchi/src/binutils-gdb/gdb/../include -I/home/smarchi/src/binutils-gdb/gdb/../readline/readline/.. -I/home/smarchi/src/binutils-gdb/gdb/../zlib -I../libdecnumber -I/home/smarchi/src/binutils-gdb/gdb/../libdecnumber -I/home/smarchi/src/binutils-gdb/gdb/../gnulib/import -I../gnulib/import -I/home/smarchi/src/binutils-gdb/gdb/.. -I.. -I/home/smarchi/src/binutils-gdb/gdb/../libbacktrace/ -I../libbacktrace/ -DTUI=1-I/usr/include/guile/3.0 -I/usr -I/usr/include/python3.11 -I/usr/include/python3.11 -I/home/smarchi/src/binutils-gdb/gdb/.. -pthread -Wall -Wpointer-arith -Wno-unused -Wunused-value -Wunused-variable -Wunused-function -Wno-switch -Wno-char-subscripts -Wempty-body -Wunused-but-set-parameter -Wunused-but-set-variable -Wno-sign-compare -Wno-error=maybe-uninitialized -Wno-mismatched-tags -Wsuggest-override -Wimplicit-fallthrough=3 -Wduplicated-cond -Wshadow=local -Wdeprecated-copy -Wdeprecated-copy-dtor -Wredundant-move -Wmissing-declarations -Wstrict-null-sentinel -Wformat -Wformat-nonliteral -Werror -g3 -O2 -fsanitize=address -D_GLIBCXX_DEBUG=1 -c -o d-lang.o -MT d-lang.o -MMD -MP -MF ./.deps/d-lang.Tpo /home/smarchi/src/binutils-gdb/gdb/d-lang.c In file included from /opt/gcc/git/include/c++/14.0.0/bits/hashtable_policy.h:36, from /opt/gcc/git/include/c++/14.0.0/bits/hashtable.h:35, from /opt/gcc/git/include/c++/14.0.0/bits/unordered_map.h:33, from /opt/gcc/git/include/c++/14.0.0/unordered_map:41, from /opt/gcc/git/include/c++/14.0.0/functional:71, from /home/smarchi/src/binutils-gdb/gdb/../gdbsupport/ptid.h:35, from /home/smarchi/src/binutils-gdb/gdb/../gdbsupport/common-defs.h:206, from /home/smarchi/src/binutils-gdb/gdb/defs.h:26, from /home/smarchi/src/binutils-gdb/gdb/d-lang.c:20: In static member function ‘static _Up* std::__copy_move<_IsMove, true, std::random_access_iterator_tag>::__copy_m(_Tp*, _Tp*, _Up*) [with _Tp = const char* const; _Up = const char*; bool _IsMove = false]’, inlined from ‘_OI std::__copy_move_a2(_II, _II, _OI) [with bool _IsMove = false; _II = const char* const*; _OI = const char**]’ at /opt/gcc/git/include/c++/14.0.0/bits/stl_algobase.h:509:30, inlined from ‘_OI std::__copy_move_a1(_II, _II, _OI) [with bool _IsMove = false; _II = const char* const*; _OI = const char**]’ at /opt/gcc/git/include/c++/14.0.0/bits/stl_algobase.h:536:42, inlined from ‘_OI std::__copy_move_a(_II, _II, _OI) [with bool _IsMove = false; _II = const char* const*; _OI = const char**]’ at /opt/gcc/git/include/c++/14.0.0/bits/stl_algobase.h:543:31, inlined from ‘_OI std::copy(_II, _II, _OI) [with _II = const char* const*; _OI = const char**]’ at /opt/gcc/git/include/c++/14.0.0/bits/stl_algobase.h:636:7, inlined from ‘static _ForwardIterator std::__uninitialized_copy::__uninit_copy(_InputIterator, _InputIterator, _ForwardIterator) [with _InputIterator = const char* const*; _ForwardIterator = const char**]’ at /opt/gcc/git/include/c++/14.0.0/bits/stl_uninitialized.h:150:27, inlined from ‘_ForwardIterator std::uninitialized_copy(_InputIterator, _InputIterator, _ForwardIterator) [with _InputIterator = const char* const*; _ForwardIterator = const char**]’ at /opt/gcc/git/include/c++/14.0.0/bits/stl_uninitialized.h:188:15, inlined from ‘_ForwardIterator std::__uninitialized_copy_a(_InputIterator, _InputIterator, _ForwardIterator, allocator<_Tp>&) [with _InputIterator = const char* const*; _ForwardIterator = const char**; _Tp = const char*]’ at /opt/gcc/git/include/c++/14.0.0/bits/stl_uninitialized.h:376:37, inlined from ‘void std::__cxx1998::vector<_Tp, _Alloc>::_M_range_initialize(_ForwardIterator, _ForwardIterator, std::forward_iterator_tag) [with _ForwardIterator = const char* const*; _Tp = const char*; _Alloc = std::allocator]’ at /opt/gcc/git/include/c++/14.0.0/bits/st
[Bug libstdc++/108288] Deadlock when using -fno-elide-constructor + -D_GLIBCXX_DEBUG=1 + -std=c++11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108288 --- Comment #8 from Simon Marchi --- I tested with just patching my /usr/include, and it looks like it works fine, I'm able to run a program under my GDB. Removing the fix, I get back the hang.
[Bug libstdc++/108288] Deadlock when using -fno-elide-constructor + -D_GLIBCXX_DEBUG=1 + -std=c++11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108288 --- Comment #6 from Simon Marchi --- Because some code trying to acquire the lock (see frame #7 in my backtrace) is in debug.cc, I thought it would maybe need to be changed too? But I don't really understand any of this.
[Bug libstdc++/108288] Deadlock when using -fno-elide-constructor + -D_GLIBCXX_DEBUG=1 + -std=c++11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108288 --- Comment #4 from Simon Marchi --- Thanks for looking into this so quickly. I'll try to test the patch against my use case, but I might need some guidance. I know how to build gcc and install it in some non-default prefix. But then, do I need to do something special when building my program, to ensure that this libstdc++.so will be used, instead of the system one? Just set LD_LIBRARY_PATH appropriately, like for any other lib?
[Bug libstdc++/108288] New: Deadlock when using -fno-elide-constructor + -D_GLIBCXX_DEBUG=1 + -std=c++11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108288
Bug ID: 108288
Summary: Deadlock when using -fno-elide-constructor +
-D_GLIBCXX_DEBUG=1 + -std=c++11
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: simon.marchi at polymtl dot ca
Target Milestone: ---
I built GDB with -fno-elide-constructor in order to chase / prove a bug in some
move constructor (which would get elided otherwise, hiding the problem). I
also used -D_GLIBCXX_DEBUG=1 and -std=c++11, I think it's important here. This
results in a deadlock in GDB, when trying to run a simple program:
(top-gdb) bt 15
#0 futex_wait (private=0, expected=2, futex_word=0x76e35f80
<__gnu_internal::get_mutex(unsigned char)::m>) at
../sysdeps/nptl/futex-internal.h:146
#1 __GI___lll_lock_wait (futex=futex@entry=0x76e35f80
<__gnu_internal::get_mutex(unsigned char)::m>, private=0) at lowlevellock.c:49
#2 0x769bac12 in lll_mutex_lock_optimized (mutex=0x76e35f80
<__gnu_internal::get_mutex(unsigned char)::m>) at pthread_mutex_lock.c:48
#3 ___pthread_mutex_lock (mutex=0x76e35f80
<__gnu_internal::get_mutex(unsigned char)::m>) at pthread_mutex_lock.c:93
#4 0x76cd2518 in __gthread_mutex_lock (__mutex=0x76e35f80
<__gnu_internal::get_mutex(unsigned char)::m>) at
/usr/src/debug/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu/bits/gthr-default.h:749#5
__gnu_cxx::__mutex::lock (this=0x76e35f80
<__gnu_internal::get_mutex(unsigned char)::m>) at
/usr/src/debug/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/include/ext/concurrence.h:149
#6 __gnu_cxx::__scoped_lock::__scoped_lock (__name=..., this=) at
/usr/src/debug/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/include/ext/concurrence.h:241
#7 __gnu_debug::_Safe_iterator_base::_M_detach (this=0x7fffa5a8) at
/usr/src/debug/gcc/libstdc++-v3/src/c++11/debug.cc:408
#8 0x57fd1608 in
__gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iterator > >, std::__debug::vector >,
std::forward_iterator_tag>::_Safe_iterator (this=0x7fffaab0, __x=...) at
/usr/include/c++/12.2.0/debug/safe_iterator.h:201
#9 0x57fcf919 in
__gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iterator > >, std::__debug::vector >,
std::bidirectional_iterator_tag>::_Safe_iterator (this=0x7fffaab0) at
/usr/include/c++/12.2.0/debug/safe_iterator.h:550
#10 0x57fcf93f in
__gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iterator > >, std::__debug::vector >,
std::random_access_iterator_tag>::_Safe_iterator (this=0x7fffaab0) at
/usr/include/c++/12.2.0/debug/safe_iterator.h:699
#11 0x57fd2734 in
__gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iterator > >, std::__debug::vector >,
std::random_access_iterator_tag>::operator++ (this=0x7fffa7e0) at
/usr/include/c++/12.2.0/debug/safe_iterator.h:764
#12 0x57fa6341 in addr_info_make_relative (addrs=0x7fffb8f0,
abfd=0x612ebfc0) at /home/simark/src/binutils-gdb/gdb/symfile.c:551
#13 0x57fa8cee in syms_from_objfile_1 (objfile=0x61407e40,
addrs=0x7fffb8f0, add_flags=...) at
/home/simark/src/binutils-gdb/gdb/symfile.c:957
#14 0x57fa9106 in syms_from_objfile (objfile=0x61407e40,
addrs=0x7fffb8f0, add_flags=...) at
/home/simark/src/binutils-gdb/gdb/symfile.c:985
(More stack frames follow...)
My theory is:
- frame #11 has acquired the lock at 0x76e35f80:
(top-gdb) frame 11
#11 0x57fd2734 in
__gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iterator > >, std::__debug::vector >,
std::random_access_iterator_tag>::operator++ (this=0x7fffa7e0) at
/usr/include/c++/12.2.0/debug/safe_iterator.h:764
764 _Attach_single());
(top-gdb) print __l._M_device
$12 = (__gnu_cxx::__scoped_lock::__mutex_type &) @0x76e35f80: {
- frame #7 is trying to acquire the same lock:
(top-gdb) frame 7
#7 __gnu_debug::_Safe_iterator_base::_M_detach (this=0x7fffa5a8) at
/usr/src/debug/gcc/libstdc++-v3/src/c++11/debug.cc:408
408 /usr/src/debug/gcc/libstdc++-v3/src/c++11/debug.cc: Bad file
descriptor.
(top-gdb) frame 6
#6 __gnu_cxx::__scoped_lock::__scoped_lock (__name=..., this=) at
/usr/src/debug/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/include/ext/concurrence.h:241
241
/usr/src/debug/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/include/ext/concurrence.h:
Bad file descriptor.
(top-gdb) p __name
$13 = (__gnu_cxx::__scoped_lock::__mutex_type &) @0x76e35f80: {
- This isn't normally seen because the move construction of _Safe_iterator
(frame 10) would normally get elided.
[Bug debug/107414] dwarf 5 C macro support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107414
Simon Marchi changed:
What|Removed |Added
CC||simon.marchi at polymtl dot ca
--- Comment #5 from Simon Marchi ---
The original reproducer Ulrich gave indeed seems like what was fixed in GDB
master recently. Macros in the main source file didn't work with DWARF 5.
That works fine now.
But he pointed me to a real-life case in gawk, where it didn't work:
https://sourceware.org/bugzilla/show_bug.cgi?id=29725#c2
That seems to highlight a new problem, that is the use of macros combined with
#line directives. I don't think that the debug info is sufficient for GDB to
figure this out.
For convenience, here's a copy of what I posted on the GDB bug.
---
With a simple case, it works as expected:
$ cat test.c
#define FOO 2
int main() { return FOO; }
$ gcc test.c -g3 -O0
$ ./gdb --data-directory=data-directory -nx -q -iex "set debuginfod enabled
off" ./a.out -ex start -ex "info macro FOO" -batch
...
Defined at /home/simark/build/binutils-gdb/gdb/test.c:1
#define FOO 2
But then if you add a line control directive, like you have for a .c file
generated from a .y file:
$ cat test.c
#define FOO 2
#line 17 "potato.c"
int main() { return FOO; }
$ gcc test.c -g3 -O0
$ ./gdb --data-directory=data-directory -nx -q -iex "set debuginfod enabled
off" ./a.out -ex start -ex "info macro FOO" -batch
...
The symbol `FOO' has no definition as a C/C++ preprocessor macro
at /home/simark/build/binutils-gdb/gdb/test.c:-1
Looking at the macro debug info (my annotations after the #s):
$ readelf --debug-dump=macro a.out
DW_MACRO_import - offset : 0x20 # built-in macros
DW_MACRO_start_file - lineno: 0 filenum: 2 # test.c
DW_MACRO_start_file - lineno: 0 filenum: 3 # stdc-predef.h
DW_MACRO_import - offset : 0x900 # STDC macros
DW_MACRO_end_file # end of stdc-predef.h
DW_MACRO_define_strp - lineno : 1 macro : FOO 2
<--- here
DW_MACRO_end_file # end of test.c
The line table tells GDB that the current PC is in potato.c, line 17:
CU: ./test.c:
File nameLine numberStarting addressView
Stmt
potato.c 17 0x1119
x
potato.c 17 0x111d
x
potato.c 17 0x1122
x
potato.c - 0x1124
But GDB has no way to figure out where this is in the macro inclusion tree, as
potato.c is never represented in there. Ideally, GDB would figure out that we
are where I maked `here`, above.
Looking at the DWARF opcodes for macro, I don't really see a way to describe
the #line stuff. There's only DW_MACRO_start_file, which represents the
inclusion of a complete file.
[Bug c++/81159] New warning idea: -Wself-move
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81159 --- Comment #11 from Simon Marchi --- Awesome, thanks!
[Bug debug/105088] Small DWARF 5 spec violation in line table when passing an absolute path
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105088 --- Comment #1 from Simon Marchi --- Looking at the .s, I see that gcc attempts to pass "/tmp/cwd/test.c" as the name of the file at index 0: .file 0 "/home/simark" "/tmp/cwd/test.c" If gas did put "/tmp/cwd/test.c" as the name in the line table header, it would be fine. But in the gas doc [1]: > When emitting DWARF2 line number information, .file assigns filenames to the > .debug_line file name table. The syntax is: > > .file fileno filename > > The fileno operand should be a unique positive integer to use as the index of > the entry in the table. The filename operand is a C string literal enclosed > in double quotes. The filename can include directory elements. If it does, > then the directory will be added to the directory table and the basename will > be added to the file table. So, gas always only puts the basename as the name in the line table header, that's why we end up with just "test.c". [1] https://sourceware.org/binutils/docs/as/File.html#File
[Bug debug/105088] New: Small DWARF 5 spec violation in line table when passing an absolute path
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105088
Bug ID: 105088
Summary: Small DWARF 5 spec violation in line table when
passing an absolute path
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: simon.marchi at polymtl dot ca
Target Milestone: ---
With:
$ gcc --version
gcc (GCC) 11.2.0
$ as --version
GNU assembler (GNU Binutils) 2.38
I have a source file at /tmp/cwd/test.c and compile it with:
$ gcc /tmp/cwd/test.c -g3 -O0 -gdwarf-5
The DW_AT_name of the CU is "/tmp/cwd/test.c":
<12> DW_AT_name: (line_strp) (offset: 0xd): /tmp/cwd/test.c
The entry at index 0 in the file names table, in the line table header, is
"test.c":
0 (udata) 1 (line_strp) (offset: 0x16): test.c
In section 6.2.4 (The Line Number Program Header), bullet 20 (file_names),
DWARF5.pdf says:
> The first entry in the sequence is the primary source file whose file name
exactly matches that given in the DW_AT_name attribute in the compilation
unit debugging information entry.
The debug info produced by the toolchain therefore seems to not respect the
spec: the name of the primary source file in the line table header ("test.c")
does not match the DW_AT_name attribute in the compilation unit DIE
("/tmp/cwd/test.c").
[Bug libstdc++/101659] _GLIBCXX_DEBUG mode for std::optional ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101659 Simon Marchi changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Simon Marchi --- (In reply to Marc Glisse from comment #1) > I already see some "__glibcxx_assert(this->_M_is_engaged());" in the code, > which IIUC should be enabled by _GLIBCXX_ASSERTIONS (and a fortiori by > _GLIBCXX_DEBUG). Did you actually try it? Arf, yes I did try it. But I now see that I compiled my test.cpp _without_ _GLIBCXX_DEBUG (with the intention of compiling with it). Now that I did it correctly, I see the assertion triggers. Thanks, and sorry for wasting everyone's time.
[Bug c++/101659] New: _GLIBCXX_DEBUG mode for std::optional ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101659 Bug ID: 101659 Summary: _GLIBCXX_DEBUG mode for std::optional ? Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: simon.marchi at polymtl dot ca Target Milestone: --- There doesn't seem to be a version of std::optional with debug runtime checks enabled with _GLIBCXX_DEBUG. It seems to me like it would be useful, to catch "dereferencing" the optional when it doesn't contain a value.
[Bug debug/101378] Negative DW_AT_data_member_location
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101378 --- Comment #1 from Simon Marchi --- I bisected, it started with: libstdc++: Remove inheritance from elements in std::tuple 91e6226f880b048275a7ceedef716e159c7cefd9 So it's likely related to the use of [[no_unique_address]]. Relevant thread on dwarf-discuss: http://lists.dwarfstd.org/pipermail/dwarf-discuss-dwarfstd.org/2021-June/004825.html
[Bug debug/101378] New: Negative DW_AT_data_member_location
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101378
Bug ID: 101378
Summary: Negative DW_AT_data_member_location
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: simon.marchi at polymtl dot ca
Target Milestone: ---
I'm at 1ca642d785c49e9e0b28651b190720267703f023 (current master).
$ cat test.cpp
#include
int main() {
std::unique_ptr p(new int);
return 0;
}
$ /opt/gcc/git/bin/g++ test.cpp -g3 -O0
$ readelf --debug-dump a.out
...
<3><968>: Abbrev Number: 79 (DW_TAG_member)
<969> DW_AT_name: (indirect string, offset: 0xc214): _M_head_impl
<96d> DW_AT_decl_file : 4
<96e> DW_AT_decl_line : 125
<96f> DW_AT_decl_column : 39
<970> DW_AT_type: <0x67e>
<974> DW_AT_data_member_location: -1
...
The -1 DW_AT_data_member_location value looks wrong. Previous gcc versions
would say 0, which makes more sense. It doesn't seem to change anything
whether I use DWARF 4 or 5.
Related GDB bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28063
[Bug debug/100610] New: DWARF5, wrong include_directories[0] when building in /
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100610
Bug ID: 100610
Summary: DWARF5, wrong include_directories[0] when building in
/
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: simon.marchi at polymtl dot ca
Target Milestone: ---
If I build a trivial test file while in the /tmp directory:
$ pwd
/tmp
$ cat test.c
#include
#define FOO 2
int main() {
return FOO;
}
$ /opt/gcc/git/bin/gcc -gdwarf-5 -g3 -O0 -o test test.c
The include_directories table of .debug_line looks fine:
$ readelf --debug-dump=rawline test
The Directory Table (offset 0x22, lines 7, columns 1):
Entry Name
0 (line_strp) (offset: 0x0): /tmp
1 (line_strp) (offset: 0xc): /usr/include
2 (line_strp) (offset: 0x19): /usr/include/bits
3 (line_strp) (offset: 0x2b): /usr/include/sys
4 (line_strp) (offset: 0x3c): /usr/include/gnu
5 (line_strp) (offset: 0x4d):
/opt/gcc/git/lib/gcc/x86_64-pc-linux-gnu/12.0.0/include
6 (line_strp) (offset: 0x85): /usr/include/bits/types
The File Name Table (offset 0x44, lines 26, columns 2):
Entry Dir Name
0 (udata) 0 (line_strp) (offset: 0x5): test.c
1 (udata) 0 (line_strp) (offset: 0x5): test.c
Files #0 and #1 point to directory 0, which gives /tmp/test.c.
However, if I move test.c in the root directory, at /test.c and move there:
$ pwd
/
$ /opt/gcc/git/bin/gcc -gdwarf-5 -g3 -O0 -o /tmp/test test.c
The Directory Table (offset 0x22, lines 7, columns 1):
Entry Name
0 (line_strp) (offset: 0x9): /usr/include
1 (line_strp) (offset: 0x9): /usr/include
2 (line_strp) (offset: 0x16): /usr/include/bits
3 (line_strp) (offset: 0x28): /usr/include/sys
4 (line_strp) (offset: 0x39): /usr/include/gnu
5 (line_strp) (offset: 0x4a):
/opt/gcc/git/lib/gcc/x86_64-pc-linux-gnu/12.0.0/include
6 (line_strp) (offset: 0x82): /usr/include/bits/types
The File Name Table (offset 0x44, lines 26, columns 2):
Entry Dir Name
0 (udata) 0 (line_strp) (offset: 0x0): test.c
1 (udata) 0 (line_strp) (offset: 0x0): test.c
See the files #0 and #1. They point to directory #0, which is /usr/include.
That makes it believe that the source file was at /usr/include/test.c. That
looks wrong to me.
[Bug debug/100446] GDB has problems reading GCC's debugging info level -g3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100446
Simon Marchi changed:
What|Removed |Added
CC||simon.marchi at polymtl dot ca
--- Comment #7 from Simon Marchi ---
Indeed, as soon as I build something with more than two CUs (no LTO involved),
I get these import 0x0:
$ gcc --version
gcc (GCC) 10.2.0
Copyright (C) 2020 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.
$ cat test.c
#include
void foo();
int main() {
foo();
}
$ cat test2.c
#include
void foo()
{
}
$ gcc test.c test2.c -g3 -O0 -o test
$ readelf --debug-dump=macro test | less
...
Offset: 0x1a81
Version: 4
Offset size: 4
Offset into .debug_line: 0x1c1
DW_MACRO_import - offset : 0x0
DW_MACRO_start_file - lineno: 0 filenum: 1 filename: test2.c
DW_MACRO_start_file - lineno: 31 filenum: 2 filename:
/usr/include/stdc-predef.h
DW_MACRO_import - offset : 0x0
DW_MACRO_end_file
DW_MACRO_start_file - lineno: 1 filenum: 3 filename: /usr/include/unistd.h
DW_MACRO_define_strp - lineno : 23 macro : _UNISTD_H 1
DW_MACRO_start_file - lineno: 25 filenum: 4 filename: /usr/include/features.h
DW_MACRO_import - offset : 0x0
DW_MACRO_start_file - lineno: 473 filenum: 5 filename:
/usr/include/sys/cdefs.h
DW_MACRO_import - offset : 0x0
DW_MACRO_start_file - lineno: 462 filenum: 6 filename:
/usr/include/bits/wordsize.h
DW_MACRO_import - offset : 0x0
DW_MACRO_end_file
DW_MACRO_start_file - lineno: 463 filenum: 7 filename:
/usr/include/bits/long-double.h
DW_MACRO_define_strp - lineno : 21 macro : __LDOUBLE_REDIRECTS_TO_FLOAT128_ABI
0
DW_MACRO_end_file
DW_MACRO_import - offset : 0x0
DW_MACRO_end_file
DW_MACRO_start_file - lineno: 497 filenum: 8 filename:
/usr/include/gnu/stubs.h
...
