* Re: [PATCH v3] gdb: call check_typedef at beginning of dwarf_expr_context::fetch_result [not found] <20220728153340.4052079-1-simon.marchi@efficios.com> @ 2022-08-18 16:16 ` Simon Marchi 2022-08-18 16:51 ` Luis Machado 0 siblings, 1 reply; 7+ messages in thread From: Simon Marchi @ 2022-08-18 16:16 UTC (permalink / raw) To: Simon Marchi, gdb-patches On 7/28/22 11:33, Simon Marchi wrote: > From: Simon Marchi <simon.marchi@polymtl.ca> > > New in this version: > > - add architecture check in test > - add aarch64 version of the .S > > Bug 29374 shows this crash: > > $ ./gdb -nx --data-directory=data-directory -q -batch -ex "catch throw" -ex r -ex bt a.out > ... > /home/simark/src/binutils-gdb/gdb/../gdbsupport/array-view.h:217: internal-error: copy: Assertion `dest.size () == src.size ()' failed. > > The backtrace is: > > #0 internal_error (file=0x5555606504c0 "/home/simark/src/binutils-gdb/gdb/../gdbsupport/array-view.h", line=217, fmt=0x55556064b700 "%s: Assertion `%s' failed.") at /home/simark/src/binutils-gdb/gdbsupport/errors.cc:51 > #1 0x000055555d41c0bb in gdb::copy<unsigned char const, unsigned char> (src=..., dest=...) at /home/simark/src/binutils-gdb/gdb/../gdbsupport/array-view.h:217 > #2 0x000055555deef28c in dwarf_expr_context::fetch_result (this=0x7fffffffb830, type=0x621007a86830, subobj_type=0x621007a86830, subobj_offset=0, as_lval=false) at /home/simark/src/binutils-gdb/gdb/dwarf2/expr.c:1040 > #3 0x000055555def0015 in dwarf_expr_context::evaluate (this=0x7fffffffb830, addr=0x62f00004313e "0", len=1, as_lval=false, per_cu=0x60b000069550, frame=0x621007c9e910, addr_info=0x0, type=0x621007a86830, subobj_type=0x621007a86830, subobj_offset=0) at /home/simark/src/binutils-gdb/gdb/dwarf2/expr.c:1091 > #4 0x000055555e084327 in dwarf2_evaluate_loc_desc_full (type=0x621007a86830, frame=0x621007c9e910, data=0x62f00004313e "0", size=1, per_cu=0x60b000069550, per_objfile=0x613000006080, subobj_type=0x621007a86830, subobj_byte_offset=0, as_lval=false) at /home/simark/src/binutils-gdb/gdb/dwarf2/loc.c:1485 > #5 0x000055555e0849e2 in dwarf2_evaluate_loc_desc (type=0x621007a86830, frame=0x621007c9e910, data=0x62f00004313e "0", size=1, per_cu=0x60b000069550, per_objfile=0x613000006080, as_lval=false) at /home/simark/src/binutils-gdb/gdb/dwarf2/loc.c:1529 > #6 0x000055555e0828c6 in dwarf_entry_parameter_to_value (parameter=0x621007a96e58, deref_size=0x0, type=0x621007a86830, caller_frame=0x621007c9e910, per_cu=0x60b000069550, per_objfile=0x613000006080) at /home/simark/src/binutils-gdb/gdb/dwarf2/loc.c:1235 > #7 0x000055555e082f55 in value_of_dwarf_reg_entry (type=0x621007a86890, frame=0x621007acc510, kind=CALL_SITE_PARAMETER_DWARF_REG, kind_u=...) at /home/simark/src/binutils-gdb/gdb/dwarf2/loc.c:1332 > #8 0x000055555e083449 in value_of_dwarf_block_entry (type=0x621007a86890, frame=0x621007acc510, block=0x61e000033568 "T\004\205\001\240\004\004\243\001T\237\004\240\004\261\004\001T\004\261\004\304\005\004\243\001T\237\004\304\005\310\005\001T\004\310\005\311\005\004\243\001T\237", block_len=1) at /home/simark/src/binutils-gdb/gdb/dwarf2/loc.c:1365 > #9 0x000055555e094d40 in loclist_read_variable_at_entry (symbol=0x621007a99bd0, frame=0x621007acc510) at /home/simark/src/binutils-gdb/gdb/dwarf2/loc.c:3889 > #10 0x000055555f5192e0 in read_frame_arg (fp_opts=..., sym=0x621007a99bd0, frame=0x621007acc510, argp=0x7fffffffbf20, entryargp=0x7fffffffbf60) at /home/simark/src/binutils-gdb/gdb/stack.c:559 > #11 0x000055555f51c352 in print_frame_args (fp_opts=..., func=0x621007a99ad0, frame=0x621007acc510, num=-1, stream=0x6030000bad90) at /home/simark/src/binutils-gdb/gdb/stack.c:887 > #12 0x000055555f521919 in print_frame (fp_opts=..., frame=0x621007acc510, print_level=1, print_what=LOCATION, print_args=1, sal=...) at /home/simark/src/binutils-gdb/gdb/stack.c:1390 > #13 0x000055555f51f22e in print_frame_info (fp_opts=..., frame=0x621007acc510, print_level=1, print_what=LOCATION, print_args=1, set_current_sal=0) at /home/simark/src/binutils-gdb/gdb/stack.c:1116 > #14 0x000055555f526c6d in backtrace_command_1 (fp_opts=..., bt_opts=..., count_exp=0x0, from_tty=0) at /home/simark/src/binutils-gdb/gdb/stack.c:2079 > #15 0x000055555f527ae5 in backtrace_command (arg=0x0, from_tty=0) at /home/simark/src/binutils-gdb/gdb/stack.c:2198 > > The problem is that the type that gets passed down to > dwarf_expr_context::fetch_result (the type of a variable of which we're > trying to read the entry value) is a typedef whose size has never been > computed yet (check_typedef has never been called on it). As we get in > the DWARF_VALUE_STACK case (line 1028 of dwarf2/expr.c), the `len` > variable is therefore set to 0, instead of the actual type length. We > then call allocate_value on subobj_type, which does call check_typedef, > so the length of the typedef gets filled in at that point. We end up > passing to the copy function a source array view of length 0 and a > target array view of length 4, and the assertion fails. > > Fix this by calling check_typedef on both type and subobj_type at the > beginning of fetch_result. > > I tried writing a test for this using the DWARF assembler, but I haven't > succeeded. It's possible that we need to get into this specific code > path (value_of_dwarf_reg_entry and all) to manage to get to > dwarf_expr_context::fetch_result with a typedef type that has never been > resolved. In all my attempts, the typedef would always be resolved > already, so the bug wouldn't show up. > > As a fallback, I made a gdb.dwarf2 test with compiler-generated .S > files. I don't particularly like those, but I think it's better than no > test. The .cpp source code is the smallest reproducer I am able to make > from the reproducer given in the bug (thanks to Pedro for suggestions on > how to minimize it further than I had). Since I tested on both amd64 > and aarch64, I added versions of the test for these two architectures. > > Change-Id: I182733ad08e34df40d8bcc47af72c482fabf4900 > Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29374 > --- > gdb/dwarf2/expr.c | 5 + > .../gdb.dwarf2/entry-value-typedef-aarch64.S | 12885 +++++++++++++ > .../gdb.dwarf2/entry-value-typedef-amd64.S | 15545 ++++++++++++++++ > .../gdb.dwarf2/entry-value-typedef.cpp | 36 + > .../gdb.dwarf2/entry-value-typedef.exp | 45 + > 5 files changed, 28516 insertions(+) > create mode 100644 gdb/testsuite/gdb.dwarf2/entry-value-typedef-aarch64.S > create mode 100644 gdb/testsuite/gdb.dwarf2/entry-value-typedef-amd64.S > create mode 100644 gdb/testsuite/gdb.dwarf2/entry-value-typedef.cpp > create mode 100644 gdb/testsuite/gdb.dwarf2/entry-value-typedef.exp I pushed this patch. Simon ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH v3] gdb: call check_typedef at beginning of dwarf_expr_context::fetch_result 2022-08-18 16:16 ` [PATCH v3] gdb: call check_typedef at beginning of dwarf_expr_context::fetch_result Simon Marchi @ 2022-08-18 16:51 ` Luis Machado 2022-08-18 17:34 ` Simon Marchi 0 siblings, 1 reply; 7+ messages in thread From: Luis Machado @ 2022-08-18 16:51 UTC (permalink / raw) To: Simon Marchi, Simon Marchi, gdb-patches On 8/18/22 17:16, Simon Marchi via Gdb-patches wrote: > On 7/28/22 11:33, Simon Marchi wrote: >> From: Simon Marchi <simon.marchi@polymtl.ca> >> >> New in this version: >> >> - add architecture check in test >> - add aarch64 version of the .S >> >> Bug 29374 shows this crash: >> >> $ ./gdb -nx --data-directory=data-directory -q -batch -ex "catch throw" -ex r -ex bt a.out >> ... >> /home/simark/src/binutils-gdb/gdb/../gdbsupport/array-view.h:217: internal-error: copy: Assertion `dest.size () == src.size ()' failed. >> >> The backtrace is: >> >> #0 internal_error (file=0x5555606504c0 "/home/simark/src/binutils-gdb/gdb/../gdbsupport/array-view.h", line=217, fmt=0x55556064b700 "%s: Assertion `%s' failed.") at /home/simark/src/binutils-gdb/gdbsupport/errors.cc:51 >> #1 0x000055555d41c0bb in gdb::copy<unsigned char const, unsigned char> (src=..., dest=...) at /home/simark/src/binutils-gdb/gdb/../gdbsupport/array-view.h:217 >> #2 0x000055555deef28c in dwarf_expr_context::fetch_result (this=0x7fffffffb830, type=0x621007a86830, subobj_type=0x621007a86830, subobj_offset=0, as_lval=false) at /home/simark/src/binutils-gdb/gdb/dwarf2/expr.c:1040 >> #3 0x000055555def0015 in dwarf_expr_context::evaluate (this=0x7fffffffb830, addr=0x62f00004313e "0", len=1, as_lval=false, per_cu=0x60b000069550, frame=0x621007c9e910, addr_info=0x0, type=0x621007a86830, subobj_type=0x621007a86830, subobj_offset=0) at /home/simark/src/binutils-gdb/gdb/dwarf2/expr.c:1091 >> #4 0x000055555e084327 in dwarf2_evaluate_loc_desc_full (type=0x621007a86830, frame=0x621007c9e910, data=0x62f00004313e "0", size=1, per_cu=0x60b000069550, per_objfile=0x613000006080, subobj_type=0x621007a86830, subobj_byte_offset=0, as_lval=false) at /home/simark/src/binutils-gdb/gdb/dwarf2/loc.c:1485 >> #5 0x000055555e0849e2 in dwarf2_evaluate_loc_desc (type=0x621007a86830, frame=0x621007c9e910, data=0x62f00004313e "0", size=1, per_cu=0x60b000069550, per_objfile=0x613000006080, as_lval=false) at /home/simark/src/binutils-gdb/gdb/dwarf2/loc.c:1529 >> #6 0x000055555e0828c6 in dwarf_entry_parameter_to_value (parameter=0x621007a96e58, deref_size=0x0, type=0x621007a86830, caller_frame=0x621007c9e910, per_cu=0x60b000069550, per_objfile=0x613000006080) at /home/simark/src/binutils-gdb/gdb/dwarf2/loc.c:1235 >> #7 0x000055555e082f55 in value_of_dwarf_reg_entry (type=0x621007a86890, frame=0x621007acc510, kind=CALL_SITE_PARAMETER_DWARF_REG, kind_u=...) at /home/simark/src/binutils-gdb/gdb/dwarf2/loc.c:1332 >> #8 0x000055555e083449 in value_of_dwarf_block_entry (type=0x621007a86890, frame=0x621007acc510, block=0x61e000033568 "T\004\205\001\240\004\004\243\001T\237\004\240\004\261\004\001T\004\261\004\304\005\004\243\001T\237\004\304\005\310\005\001T\004\310\005\311\005\004\243\001T\237", block_len=1) at /home/simark/src/binutils-gdb/gdb/dwarf2/loc.c:1365 >> #9 0x000055555e094d40 in loclist_read_variable_at_entry (symbol=0x621007a99bd0, frame=0x621007acc510) at /home/simark/src/binutils-gdb/gdb/dwarf2/loc.c:3889 >> #10 0x000055555f5192e0 in read_frame_arg (fp_opts=..., sym=0x621007a99bd0, frame=0x621007acc510, argp=0x7fffffffbf20, entryargp=0x7fffffffbf60) at /home/simark/src/binutils-gdb/gdb/stack.c:559 >> #11 0x000055555f51c352 in print_frame_args (fp_opts=..., func=0x621007a99ad0, frame=0x621007acc510, num=-1, stream=0x6030000bad90) at /home/simark/src/binutils-gdb/gdb/stack.c:887 >> #12 0x000055555f521919 in print_frame (fp_opts=..., frame=0x621007acc510, print_level=1, print_what=LOCATION, print_args=1, sal=...) at /home/simark/src/binutils-gdb/gdb/stack.c:1390 >> #13 0x000055555f51f22e in print_frame_info (fp_opts=..., frame=0x621007acc510, print_level=1, print_what=LOCATION, print_args=1, set_current_sal=0) at /home/simark/src/binutils-gdb/gdb/stack.c:1116 >> #14 0x000055555f526c6d in backtrace_command_1 (fp_opts=..., bt_opts=..., count_exp=0x0, from_tty=0) at /home/simark/src/binutils-gdb/gdb/stack.c:2079 >> #15 0x000055555f527ae5 in backtrace_command (arg=0x0, from_tty=0) at /home/simark/src/binutils-gdb/gdb/stack.c:2198 >> >> The problem is that the type that gets passed down to >> dwarf_expr_context::fetch_result (the type of a variable of which we're >> trying to read the entry value) is a typedef whose size has never been >> computed yet (check_typedef has never been called on it). As we get in >> the DWARF_VALUE_STACK case (line 1028 of dwarf2/expr.c), the `len` >> variable is therefore set to 0, instead of the actual type length. We >> then call allocate_value on subobj_type, which does call check_typedef, >> so the length of the typedef gets filled in at that point. We end up >> passing to the copy function a source array view of length 0 and a >> target array view of length 4, and the assertion fails. >> >> Fix this by calling check_typedef on both type and subobj_type at the >> beginning of fetch_result. >> >> I tried writing a test for this using the DWARF assembler, but I haven't >> succeeded. It's possible that we need to get into this specific code >> path (value_of_dwarf_reg_entry and all) to manage to get to >> dwarf_expr_context::fetch_result with a typedef type that has never been >> resolved. In all my attempts, the typedef would always be resolved >> already, so the bug wouldn't show up. >> >> As a fallback, I made a gdb.dwarf2 test with compiler-generated .S >> files. I don't particularly like those, but I think it's better than no >> test. The .cpp source code is the smallest reproducer I am able to make >> from the reproducer given in the bug (thanks to Pedro for suggestions on >> how to minimize it further than I had). Since I tested on both amd64 >> and aarch64, I added versions of the test for these two architectures. >> >> Change-Id: I182733ad08e34df40d8bcc47af72c482fabf4900 >> Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29374 >> --- >> gdb/dwarf2/expr.c | 5 + >> .../gdb.dwarf2/entry-value-typedef-aarch64.S | 12885 +++++++++++++ >> .../gdb.dwarf2/entry-value-typedef-amd64.S | 15545 ++++++++++++++++ >> .../gdb.dwarf2/entry-value-typedef.cpp | 36 + >> .../gdb.dwarf2/entry-value-typedef.exp | 45 + >> 5 files changed, 28516 insertions(+) >> create mode 100644 gdb/testsuite/gdb.dwarf2/entry-value-typedef-aarch64.S >> create mode 100644 gdb/testsuite/gdb.dwarf2/entry-value-typedef-amd64.S >> create mode 100644 gdb/testsuite/gdb.dwarf2/entry-value-typedef.cpp >> create mode 100644 gdb/testsuite/gdb.dwarf2/entry-value-typedef.exp > > I pushed this patch. > > Simon It seems newer compilers on aarch64 (g++ 9.4.0 or 11.2.0) don't like this test. They complain with: gdb compile failed, /usr/bin/ld: /tmp/cc0vjoZT.o: relocation R_AARCH64_ADR_PREL_PG_HI21 against symbol `_ZNSsD1Ev@@GLIBCXX_3.4' which may bin d externally can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: /tmp/cc0vjoZT.o(.text+0x38): unresolvable R_AARCH64_ADR_PREL_PG_HI21 relocation against symbol `_ZNSsD1Ev@@GLIBCXX_3.4' /usr/bin/ld: final link failed: bad value So the test doesn't run properly. Building it statically makes it work though, and still shows the problem: FAIL: gdb.dwarf2/entry-value-typedef.exp: backtrace (GDB internal error) Hopefully that will also work fine for x86_64 (haven't tried yet). ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH v3] gdb: call check_typedef at beginning of dwarf_expr_context::fetch_result 2022-08-18 16:51 ` Luis Machado @ 2022-08-18 17:34 ` Simon Marchi 2022-08-18 18:37 ` [PATCH] gdb/testsuite: re-compile entry-value-typedef .S files with -fPIE Simon Marchi 2022-08-19 10:35 ` [PATCH v3] gdb: call check_typedef at beginning of dwarf_expr_context::fetch_result Luis Machado 0 siblings, 2 replies; 7+ messages in thread From: Simon Marchi @ 2022-08-18 17:34 UTC (permalink / raw) To: Luis Machado, Simon Marchi, gdb-patches On 8/18/22 12:51, Luis Machado wrote: > On 8/18/22 17:16, Simon Marchi via Gdb-patches wrote: >> On 7/28/22 11:33, Simon Marchi wrote: >>> From: Simon Marchi <simon.marchi@polymtl.ca> >>> >>> New in this version: >>> >>> - add architecture check in test >>> - add aarch64 version of the .S >>> >>> Bug 29374 shows this crash: >>> >>> $ ./gdb -nx --data-directory=data-directory -q -batch -ex "catch throw" -ex r -ex bt a.out >>> ... >>> /home/simark/src/binutils-gdb/gdb/../gdbsupport/array-view.h:217: internal-error: copy: Assertion `dest.size () == src.size ()' failed. >>> >>> The backtrace is: >>> >>> #0 internal_error (file=0x5555606504c0 "/home/simark/src/binutils-gdb/gdb/../gdbsupport/array-view.h", line=217, fmt=0x55556064b700 "%s: Assertion `%s' failed.") at /home/simark/src/binutils-gdb/gdbsupport/errors.cc:51 >>> #1 0x000055555d41c0bb in gdb::copy<unsigned char const, unsigned char> (src=..., dest=...) at /home/simark/src/binutils-gdb/gdb/../gdbsupport/array-view.h:217 >>> #2 0x000055555deef28c in dwarf_expr_context::fetch_result (this=0x7fffffffb830, type=0x621007a86830, subobj_type=0x621007a86830, subobj_offset=0, as_lval=false) at /home/simark/src/binutils-gdb/gdb/dwarf2/expr.c:1040 >>> #3 0x000055555def0015 in dwarf_expr_context::evaluate (this=0x7fffffffb830, addr=0x62f00004313e "0", len=1, as_lval=false, per_cu=0x60b000069550, frame=0x621007c9e910, addr_info=0x0, type=0x621007a86830, subobj_type=0x621007a86830, subobj_offset=0) at /home/simark/src/binutils-gdb/gdb/dwarf2/expr.c:1091 >>> #4 0x000055555e084327 in dwarf2_evaluate_loc_desc_full (type=0x621007a86830, frame=0x621007c9e910, data=0x62f00004313e "0", size=1, per_cu=0x60b000069550, per_objfile=0x613000006080, subobj_type=0x621007a86830, subobj_byte_offset=0, as_lval=false) at /home/simark/src/binutils-gdb/gdb/dwarf2/loc.c:1485 >>> #5 0x000055555e0849e2 in dwarf2_evaluate_loc_desc (type=0x621007a86830, frame=0x621007c9e910, data=0x62f00004313e "0", size=1, per_cu=0x60b000069550, per_objfile=0x613000006080, as_lval=false) at /home/simark/src/binutils-gdb/gdb/dwarf2/loc.c:1529 >>> #6 0x000055555e0828c6 in dwarf_entry_parameter_to_value (parameter=0x621007a96e58, deref_size=0x0, type=0x621007a86830, caller_frame=0x621007c9e910, per_cu=0x60b000069550, per_objfile=0x613000006080) at /home/simark/src/binutils-gdb/gdb/dwarf2/loc.c:1235 >>> #7 0x000055555e082f55 in value_of_dwarf_reg_entry (type=0x621007a86890, frame=0x621007acc510, kind=CALL_SITE_PARAMETER_DWARF_REG, kind_u=...) at /home/simark/src/binutils-gdb/gdb/dwarf2/loc.c:1332 >>> #8 0x000055555e083449 in value_of_dwarf_block_entry (type=0x621007a86890, frame=0x621007acc510, block=0x61e000033568 "T\004\205\001\240\004\004\243\001T\237\004\240\004\261\004\001T\004\261\004\304\005\004\243\001T\237\004\304\005\310\005\001T\004\310\005\311\005\004\243\001T\237", block_len=1) at /home/simark/src/binutils-gdb/gdb/dwarf2/loc.c:1365 >>> #9 0x000055555e094d40 in loclist_read_variable_at_entry (symbol=0x621007a99bd0, frame=0x621007acc510) at /home/simark/src/binutils-gdb/gdb/dwarf2/loc.c:3889 >>> #10 0x000055555f5192e0 in read_frame_arg (fp_opts=..., sym=0x621007a99bd0, frame=0x621007acc510, argp=0x7fffffffbf20, entryargp=0x7fffffffbf60) at /home/simark/src/binutils-gdb/gdb/stack.c:559 >>> #11 0x000055555f51c352 in print_frame_args (fp_opts=..., func=0x621007a99ad0, frame=0x621007acc510, num=-1, stream=0x6030000bad90) at /home/simark/src/binutils-gdb/gdb/stack.c:887 >>> #12 0x000055555f521919 in print_frame (fp_opts=..., frame=0x621007acc510, print_level=1, print_what=LOCATION, print_args=1, sal=...) at /home/simark/src/binutils-gdb/gdb/stack.c:1390 >>> #13 0x000055555f51f22e in print_frame_info (fp_opts=..., frame=0x621007acc510, print_level=1, print_what=LOCATION, print_args=1, set_current_sal=0) at /home/simark/src/binutils-gdb/gdb/stack.c:1116 >>> #14 0x000055555f526c6d in backtrace_command_1 (fp_opts=..., bt_opts=..., count_exp=0x0, from_tty=0) at /home/simark/src/binutils-gdb/gdb/stack.c:2079 >>> #15 0x000055555f527ae5 in backtrace_command (arg=0x0, from_tty=0) at /home/simark/src/binutils-gdb/gdb/stack.c:2198 >>> >>> The problem is that the type that gets passed down to >>> dwarf_expr_context::fetch_result (the type of a variable of which we're >>> trying to read the entry value) is a typedef whose size has never been >>> computed yet (check_typedef has never been called on it). As we get in >>> the DWARF_VALUE_STACK case (line 1028 of dwarf2/expr.c), the `len` >>> variable is therefore set to 0, instead of the actual type length. We >>> then call allocate_value on subobj_type, which does call check_typedef, >>> so the length of the typedef gets filled in at that point. We end up >>> passing to the copy function a source array view of length 0 and a >>> target array view of length 4, and the assertion fails. >>> >>> Fix this by calling check_typedef on both type and subobj_type at the >>> beginning of fetch_result. >>> >>> I tried writing a test for this using the DWARF assembler, but I haven't >>> succeeded. It's possible that we need to get into this specific code >>> path (value_of_dwarf_reg_entry and all) to manage to get to >>> dwarf_expr_context::fetch_result with a typedef type that has never been >>> resolved. In all my attempts, the typedef would always be resolved >>> already, so the bug wouldn't show up. >>> >>> As a fallback, I made a gdb.dwarf2 test with compiler-generated .S >>> files. I don't particularly like those, but I think it's better than no >>> test. The .cpp source code is the smallest reproducer I am able to make >>> from the reproducer given in the bug (thanks to Pedro for suggestions on >>> how to minimize it further than I had). Since I tested on both amd64 >>> and aarch64, I added versions of the test for these two architectures. >>> >>> Change-Id: I182733ad08e34df40d8bcc47af72c482fabf4900 >>> Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29374 >>> --- >>> gdb/dwarf2/expr.c | 5 + >>> .../gdb.dwarf2/entry-value-typedef-aarch64.S | 12885 +++++++++++++ >>> .../gdb.dwarf2/entry-value-typedef-amd64.S | 15545 ++++++++++++++++ >>> .../gdb.dwarf2/entry-value-typedef.cpp | 36 + >>> .../gdb.dwarf2/entry-value-typedef.exp | 45 + >>> 5 files changed, 28516 insertions(+) >>> create mode 100644 gdb/testsuite/gdb.dwarf2/entry-value-typedef-aarch64.S >>> create mode 100644 gdb/testsuite/gdb.dwarf2/entry-value-typedef-amd64.S >>> create mode 100644 gdb/testsuite/gdb.dwarf2/entry-value-typedef.cpp >>> create mode 100644 gdb/testsuite/gdb.dwarf2/entry-value-typedef.exp >> >> I pushed this patch. >> >> Simon > > It seems newer compilers on aarch64 (g++ 9.4.0 or 11.2.0) don't like this test. They complain with: > > gdb compile failed, /usr/bin/ld: /tmp/cc0vjoZT.o: relocation R_AARCH64_ADR_PREL_PG_HI21 against symbol `_ZNSsD1Ev@@GLIBCXX_3.4' which may bin > d externally can not be used when making a shared object; recompile with -fPIC > /usr/bin/ld: /tmp/cc0vjoZT.o(.text+0x38): unresolvable R_AARCH64_ADR_PREL_PG_HI21 relocation against symbol `_ZNSsD1Ev@@GLIBCXX_3.4' > /usr/bin/ld: final link failed: bad value > > So the test doesn't run properly. Is is that the old compiler I used (g++ 4.8 on Ubuntu 14.04, on the compile farm) generated non-position-independent code, but the linker of the newer toolchains try to build a position-independent executable? If so, we can re-generate the assembly files with -fPIE, and it should work, right? I'll give this a try, I have access to an AArch64 machine with Debian 11 & g++ 10.2.1. Simon ^ permalink raw reply [flat|nested] 7+ messages in thread
* [PATCH] gdb/testsuite: re-compile entry-value-typedef .S files with -fPIE 2022-08-18 17:34 ` Simon Marchi @ 2022-08-18 18:37 ` Simon Marchi 2022-08-19 12:42 ` Luis Machado 2022-08-19 10:35 ` [PATCH v3] gdb: call check_typedef at beginning of dwarf_expr_context::fetch_result Luis Machado 1 sibling, 1 reply; 7+ messages in thread From: Simon Marchi @ 2022-08-18 18:37 UTC (permalink / raw) To: gdb-patches; +Cc: Simon Marchi As Luis pointed out here [1], the AArch64 variant of the test doesn't work on systems that use PIE by default. For example, on this Debian 11: $ make check TESTS="gdb.dwarf2/entry-value-typedef.exp" gdb compile failed, /usr/bin/ld: /tmp/ccJE8ZSr.o: relocation R_AARCH64_ADR_PREL_PG_HI21 against symbol `_ZNSsD1Ev@@GLIBCXX_3.4' which may bind externally can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: /tmp/ccJE8ZSr.o(.text+0x38): unresolvable R_AARCH64_ADR_PREL_PG_HI21 relocation against symbol `_ZNSsD1Ev@@GLIBCXX_3.4' This is because entry-value-typedef-aarch64.S was generated on an old system that does not generate position-independent code by default, but the system the test runs on tries to link the test executable as position-independent. Fix this by regenerating the same binary on the same system as the original one, but with -fPIE this time. Do the same for the amd64 binary, although this one was already position-independent so the generated code doesn't change. With this patch applied, the test passes on the Debian 11 AArch64 system. [1] https://sourceware.org/pipermail/gdb-patches/2022-August/191462.html Change-Id: I68d55adaa56a7a3eddb0c13980b1a98b791f8144 --- .../gdb.dwarf2/entry-value-typedef-aarch64.S | 112 ++++++++++-------- .../gdb.dwarf2/entry-value-typedef-amd64.S | 6 +- 2 files changed, 64 insertions(+), 54 deletions(-) diff --git a/gdb/testsuite/gdb.dwarf2/entry-value-typedef-aarch64.S b/gdb/testsuite/gdb.dwarf2/entry-value-typedef-aarch64.S index a6d134f656d..f0f0b932b76 100644 --- a/gdb/testsuite/gdb.dwarf2/entry-value-typedef-aarch64.S +++ b/gdb/testsuite/gdb.dwarf2/entry-value-typedef-aarch64.S @@ -47,7 +47,8 @@ _ZL4funcRKi: .cfi_offset 20, -360 .LBB293: .loc 1 28 0 - add x0, x29, 32 + add x20, x29, 32 + mov x0, x20 .LVL1: mov w1, 16 .LEHB0: @@ -65,7 +66,7 @@ _ZL4funcRKi: .file 2 "/usr/include/c++/4.8/sstream" .loc 2 472 0 mov x8, x0 - add x0, x29, 40 + add x0, x20, 8 .LEHB1: bl _ZNKSt15basic_stringbufIcSt11char_traitsIcESaIcEE3strEv .LEHE1: @@ -74,33 +75,37 @@ _ZL4funcRKi: .LBE294: .loc 1 29 0 discriminator 1 mov x0, x19 - ldr x1, .LC0 - adrp x2, _ZNSsD1Ev - add x2, x2, :lo12:_ZNSsD1Ev + adrp x1, :got:_ZTISs + ldr x1, [x1, #:got_lo12:_ZTISs] + adrp x2, :got:_ZNSsD1Ev + ldr x2, [x2, #:got_lo12:_ZNSsD1Ev] .LEHB2: bl __cxa_throw .LEHE2: .LVL6: .L4: mov x20, x0 +.LVL7: .loc 1 29 0 is_stmt 0 mov x0, x19 bl __cxa_free_exception -.LVL7: +.LVL8: mov x19, x20 b .L3 +.LVL9: .L5: mov x19, x0 +.LVL10: .L3: add x0, x29, 32 -.LVL8: +.LVL11: bl _ZNSt19basic_ostringstreamIcSt11char_traitsIcESaIcEED1Ev -.LVL9: +.LVL12: mov x0, x19 .LEHB3: bl _Unwind_Resume .LEHE3: -.LVL10: +.LVL13: .LBE293: .cfi_endproc .LFE1299: @@ -131,9 +136,6 @@ _ZL4funcRKi: .LLSDACSE1299: .text .size _ZL4funcRKi, .-_ZL4funcRKi - .align 3 -.LC0: - .xword _ZTISs .align 2 .global main .type main, %function @@ -152,12 +154,12 @@ main: mov w1, 1234 str w1, [x0,-4]! bl _ZL4funcRKi -.LVL11: +.LVL14: .cfi_endproc .LFE1300: .size main, .-main .weak _ZTISs - .section .rodata._ZTISs,"aG",%progbits,_ZTISs,comdat + .section .data.rel.ro._ZTISs,"awG",%progbits,_ZTISs,comdat .align 3 .type _ZTISs, %object .size _ZTISs, 16 @@ -224,7 +226,7 @@ _ZTSSs: .file 51 "/usr/include/aarch64-linux-gnu/c++/4.8/bits/gthr-default.h" .section .debug_info,"",%progbits .Ldebug_info0: - .4byte 0x51c9 + .4byte 0x51bc .2byte 0x4 .4byte .Ldebug_abbrev0 .byte 0x8 @@ -5042,7 +5044,7 @@ _ZTSSs: .4byte 0x2be0 .4byte 0x2be6 .uleb128 0x18 - .4byte 0x5178 + .4byte 0x516b .byte 0 .uleb128 0x2b .4byte .LASF458 @@ -8958,17 +8960,17 @@ _ZTSSs: .8byte .LFE1299-.LFB1299 .uleb128 0x1 .byte 0x9c - .4byte 0x507d + .4byte 0x5070 .uleb128 0x73 .string "t" .byte 0x1 .byte 0x1a - .4byte 0x507d + .4byte 0x5070 .4byte .LLST0 .uleb128 0x74 .8byte .LBB293 .8byte .LBE293-.LBB293 - .4byte 0x5068 + .4byte 0x505b .uleb128 0x75 .string "oss" .byte 0x1 @@ -8994,8 +8996,8 @@ _ZTSSs: .uleb128 0x1 .byte 0x50 .uleb128 0x2 - .byte 0x8f - .sleb128 40 + .byte 0x84 + .sleb128 8 .byte 0 .byte 0 .uleb128 0x7a @@ -9010,12 +9012,12 @@ _ZTSSs: .uleb128 0x1 .byte 0x50 .uleb128 0x2 - .byte 0x8f - .sleb128 32 + .byte 0x84 + .sleb128 0 .byte 0 .uleb128 0x7b .8byte .LVL3 - .4byte 0x517e + .4byte 0x5171 .4byte 0x501a .uleb128 0x79 .uleb128 0x1 @@ -9025,14 +9027,8 @@ _ZTSSs: .byte 0 .uleb128 0x7b .8byte .LVL6 - .4byte 0x5192 - .4byte 0x503f - .uleb128 0x79 - .uleb128 0x1 - .byte 0x51 - .uleb128 0x9 - .byte 0x3 - .8byte _ZTISs + .4byte 0x5185 + .4byte 0x5032 .uleb128 0x79 .uleb128 0x1 .byte 0x50 @@ -9041,9 +9037,9 @@ _ZTSSs: .sleb128 0 .byte 0 .uleb128 0x7b - .8byte .LVL7 - .4byte 0x51ac - .4byte 0x5057 + .8byte .LVL8 + .4byte 0x519f + .4byte 0x504a .uleb128 0x79 .uleb128 0x1 .byte 0x50 @@ -9052,7 +9048,7 @@ _ZTSSs: .sleb128 0 .byte 0 .uleb128 0x7c - .8byte .LVL9 + .8byte .LVL12 .uleb128 0x79 .uleb128 0x1 .byte 0x50 @@ -9062,8 +9058,8 @@ _ZTSSs: .byte 0 .byte 0 .uleb128 0x78 - .8byte .LVL10 - .4byte 0x51bc + .8byte .LVL13 + .4byte 0x51af .uleb128 0x79 .uleb128 0x1 .byte 0x50 @@ -9073,10 +9069,10 @@ _ZTSSs: .byte 0 .byte 0 .uleb128 0x10 - .4byte 0x5082 + .4byte 0x5075 .uleb128 0x55 .byte 0x8 - .4byte 0x5088 + .4byte 0x507b .uleb128 0x10 .4byte 0x4872 .uleb128 0x7d @@ -9088,9 +9084,9 @@ _ZTSSs: .8byte .LFE1300-.LFB1300 .uleb128 0x1 .byte 0x9c - .4byte 0x50c7 + .4byte 0x50ba .uleb128 0x78 - .8byte .LVL11 + .8byte .LVL14 .4byte 0x4f63 .uleb128 0x7e .uleb128 0x1 @@ -9165,13 +9161,13 @@ _ZTSSs: .uleb128 0x86 .4byte .LASF799 .4byte 0x20d - .4byte 0x5192 + .4byte 0x5185 .uleb128 0x19 .4byte 0x221 .byte 0 .uleb128 0x87 .4byte .LASF801 - .4byte 0x51ac + .4byte 0x519f .uleb128 0x19 .4byte 0x20d .uleb128 0x19 @@ -9181,7 +9177,7 @@ _ZTSSs: .byte 0 .uleb128 0x87 .4byte .LASF802 - .4byte 0x51bc + .4byte 0x51af .uleb128 0x19 .4byte 0x20d .byte 0 @@ -11207,16 +11203,30 @@ _ZTSSs: .8byte 0 .LLST1: .8byte .LVL4-.Ltext0 - .8byte .LVL8-.Ltext0 + .8byte .LVL7-.Ltext0 + .2byte 0x1 + .byte 0x64 + .8byte .LVL7-.Ltext0 + .8byte .LVL9-.Ltext0 .2byte 0x3 .byte 0x8f .sleb128 32 .byte 0x9f - .8byte .LVL8-.Ltext0 - .8byte .LVL9-1-.Ltext0 + .8byte .LVL9-.Ltext0 + .8byte .LVL10-.Ltext0 + .2byte 0x1 + .byte 0x64 + .8byte .LVL10-.Ltext0 + .8byte .LVL11-.Ltext0 + .2byte 0x3 + .byte 0x8f + .sleb128 32 + .byte 0x9f + .8byte .LVL11-.Ltext0 + .8byte .LVL12-1-.Ltext0 .2byte 0x1 .byte 0x50 - .8byte .LVL9-1-.Ltext0 + .8byte .LVL12-1-.Ltext0 .8byte .LFE1299-.Ltext0 .2byte 0x3 .byte 0x8f @@ -11377,8 +11387,6 @@ _ZTSSs: .string "tm_isdst" .LASF654: .string "grouping" -.LASF804: - .string "GNU C++ 4.8.4 -g -O1 -std=c++11 -fstack-protector" .LASF20: .string "_lock" .LASF107: @@ -12523,6 +12531,8 @@ _ZTSSs: .string "_ZNKSs17find_first_not_ofERKSsm" .LASF30: .string "__FILE" +.LASF804: + .string "GNU C++ 4.8.4 -g -O1 -std=c++11 -fPIE -fstack-protector" .LASF247: .string "_ZNSspLESt16initializer_listIcE" .LASF587: diff --git a/gdb/testsuite/gdb.dwarf2/entry-value-typedef-amd64.S b/gdb/testsuite/gdb.dwarf2/entry-value-typedef-amd64.S index 1d86941ff1b..22fad8684d2 100644 --- a/gdb/testsuite/gdb.dwarf2/entry-value-typedef-amd64.S +++ b/gdb/testsuite/gdb.dwarf2/entry-value-typedef-amd64.S @@ -19,7 +19,7 @@ $ g++ --version g++ (Ubuntu 9.4.0-1ubuntu1~20.04.1) 9.4.0 - $ g++ entry-value-typedef.cpp -O1 -S -g -o entry-value-typedef-amd64.S + $ g++ entry-value-typedef.cpp -O1 -fPIE -S -g -o entry-value-typedef-amd64.S */ .file "entry-value-typedef.cpp" @@ -13647,8 +13647,6 @@ _ZTINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE: .section .debug_str,"MS",@progbits,1 .LASF739: .string "int_p_sep_by_space" -.LASF920: - .string "GNU C++14 9.4.0 -mtune=generic -march=x86-64 -g -O1 -fasynchronous-unwind-tables -fstack-protector-strong -fstack-clash-protection -fcf-protection" .LASF547: .string "char" .LASF487: @@ -15399,6 +15397,8 @@ _ZTINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE: .string "__int_least8_t" .LASF495: .string "base" +.LASF920: + .string "GNU C++14 9.4.0 -mtune=generic -march=x86-64 -g -O1 -fPIE -fasynchronous-unwind-tables -fstack-protector-strong -fstack-clash-protection -fcf-protection" .LASF17: .string "const_pointer" .LASF764: -- 2.37.1 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] gdb/testsuite: re-compile entry-value-typedef .S files with -fPIE 2022-08-18 18:37 ` [PATCH] gdb/testsuite: re-compile entry-value-typedef .S files with -fPIE Simon Marchi @ 2022-08-19 12:42 ` Luis Machado 2022-08-19 14:14 ` Simon Marchi 0 siblings, 1 reply; 7+ messages in thread From: Luis Machado @ 2022-08-19 12:42 UTC (permalink / raw) To: Simon Marchi, gdb-patches On 8/18/22 19:37, Simon Marchi via Gdb-patches wrote: > As Luis pointed out here [1], the AArch64 variant of the test doesn't > work on systems that use PIE by default. For example, on this Debian > 11: > > $ make check TESTS="gdb.dwarf2/entry-value-typedef.exp" > gdb compile failed, /usr/bin/ld: /tmp/ccJE8ZSr.o: relocation R_AARCH64_ADR_PREL_PG_HI21 against symbol `_ZNSsD1Ev@@GLIBCXX_3.4' which may bind externally can not be used when making a shared object; recompile with -fPIC > /usr/bin/ld: /tmp/ccJE8ZSr.o(.text+0x38): unresolvable R_AARCH64_ADR_PREL_PG_HI21 relocation against symbol `_ZNSsD1Ev@@GLIBCXX_3.4' > > This is because entry-value-typedef-aarch64.S was generated on an old > system that does not generate position-independent code by default, but > the system the test runs on tries to link the test executable as > position-independent. Fix this by regenerating the same binary on the > same system as the original one, but with -fPIE this time. Do the same > for the amd64 binary, although this one was already position-independent > so the generated code doesn't change. > > With this patch applied, the test passes on the Debian 11 AArch64 > system. > > [1] https://sourceware.org/pipermail/gdb-patches/2022-August/191462.html > > Change-Id: I68d55adaa56a7a3eddb0c13980b1a98b791f8144 > --- > .../gdb.dwarf2/entry-value-typedef-aarch64.S | 112 ++++++++++-------- > .../gdb.dwarf2/entry-value-typedef-amd64.S | 6 +- > 2 files changed, 64 insertions(+), 54 deletions(-) > > diff --git a/gdb/testsuite/gdb.dwarf2/entry-value-typedef-aarch64.S b/gdb/testsuite/gdb.dwarf2/entry-value-typedef-aarch64.S > index a6d134f656d..f0f0b932b76 100644 > --- a/gdb/testsuite/gdb.dwarf2/entry-value-typedef-aarch64.S > +++ b/gdb/testsuite/gdb.dwarf2/entry-value-typedef-aarch64.S > @@ -47,7 +47,8 @@ _ZL4funcRKi: > .cfi_offset 20, -360 > .LBB293: > .loc 1 28 0 > - add x0, x29, 32 > + add x20, x29, 32 > + mov x0, x20 > .LVL1: > mov w1, 16 > .LEHB0: > @@ -65,7 +66,7 @@ _ZL4funcRKi: > .file 2 "/usr/include/c++/4.8/sstream" > .loc 2 472 0 > mov x8, x0 > - add x0, x29, 40 > + add x0, x20, 8 > .LEHB1: > bl _ZNKSt15basic_stringbufIcSt11char_traitsIcESaIcEE3strEv > .LEHE1: > @@ -74,33 +75,37 @@ _ZL4funcRKi: > .LBE294: > .loc 1 29 0 discriminator 1 > mov x0, x19 > - ldr x1, .LC0 > - adrp x2, _ZNSsD1Ev > - add x2, x2, :lo12:_ZNSsD1Ev > + adrp x1, :got:_ZTISs > + ldr x1, [x1, #:got_lo12:_ZTISs] > + adrp x2, :got:_ZNSsD1Ev > + ldr x2, [x2, #:got_lo12:_ZNSsD1Ev] > .LEHB2: > bl __cxa_throw > .LEHE2: > .LVL6: > .L4: > mov x20, x0 > +.LVL7: > .loc 1 29 0 is_stmt 0 > mov x0, x19 > bl __cxa_free_exception > -.LVL7: > +.LVL8: > mov x19, x20 > b .L3 > +.LVL9: > .L5: > mov x19, x0 > +.LVL10: > .L3: > add x0, x29, 32 > -.LVL8: > +.LVL11: > bl _ZNSt19basic_ostringstreamIcSt11char_traitsIcESaIcEED1Ev > -.LVL9: > +.LVL12: > mov x0, x19 > .LEHB3: > bl _Unwind_Resume > .LEHE3: > -.LVL10: > +.LVL13: > .LBE293: > .cfi_endproc > .LFE1299: > @@ -131,9 +136,6 @@ _ZL4funcRKi: > .LLSDACSE1299: > .text > .size _ZL4funcRKi, .-_ZL4funcRKi > - .align 3 > -.LC0: > - .xword _ZTISs > .align 2 > .global main > .type main, %function > @@ -152,12 +154,12 @@ main: > mov w1, 1234 > str w1, [x0,-4]! > bl _ZL4funcRKi > -.LVL11: > +.LVL14: > .cfi_endproc > .LFE1300: > .size main, .-main > .weak _ZTISs > - .section .rodata._ZTISs,"aG",%progbits,_ZTISs,comdat > + .section .data.rel.ro._ZTISs,"awG",%progbits,_ZTISs,comdat > .align 3 > .type _ZTISs, %object > .size _ZTISs, 16 > @@ -224,7 +226,7 @@ _ZTSSs: > .file 51 "/usr/include/aarch64-linux-gnu/c++/4.8/bits/gthr-default.h" > .section .debug_info,"",%progbits > .Ldebug_info0: > - .4byte 0x51c9 > + .4byte 0x51bc > .2byte 0x4 > .4byte .Ldebug_abbrev0 > .byte 0x8 > @@ -5042,7 +5044,7 @@ _ZTSSs: > .4byte 0x2be0 > .4byte 0x2be6 > .uleb128 0x18 > - .4byte 0x5178 > + .4byte 0x516b > .byte 0 > .uleb128 0x2b > .4byte .LASF458 > @@ -8958,17 +8960,17 @@ _ZTSSs: > .8byte .LFE1299-.LFB1299 > .uleb128 0x1 > .byte 0x9c > - .4byte 0x507d > + .4byte 0x5070 > .uleb128 0x73 > .string "t" > .byte 0x1 > .byte 0x1a > - .4byte 0x507d > + .4byte 0x5070 > .4byte .LLST0 > .uleb128 0x74 > .8byte .LBB293 > .8byte .LBE293-.LBB293 > - .4byte 0x5068 > + .4byte 0x505b > .uleb128 0x75 > .string "oss" > .byte 0x1 > @@ -8994,8 +8996,8 @@ _ZTSSs: > .uleb128 0x1 > .byte 0x50 > .uleb128 0x2 > - .byte 0x8f > - .sleb128 40 > + .byte 0x84 > + .sleb128 8 > .byte 0 > .byte 0 > .uleb128 0x7a > @@ -9010,12 +9012,12 @@ _ZTSSs: > .uleb128 0x1 > .byte 0x50 > .uleb128 0x2 > - .byte 0x8f > - .sleb128 32 > + .byte 0x84 > + .sleb128 0 > .byte 0 > .uleb128 0x7b > .8byte .LVL3 > - .4byte 0x517e > + .4byte 0x5171 > .4byte 0x501a > .uleb128 0x79 > .uleb128 0x1 > @@ -9025,14 +9027,8 @@ _ZTSSs: > .byte 0 > .uleb128 0x7b > .8byte .LVL6 > - .4byte 0x5192 > - .4byte 0x503f > - .uleb128 0x79 > - .uleb128 0x1 > - .byte 0x51 > - .uleb128 0x9 > - .byte 0x3 > - .8byte _ZTISs > + .4byte 0x5185 > + .4byte 0x5032 > .uleb128 0x79 > .uleb128 0x1 > .byte 0x50 > @@ -9041,9 +9037,9 @@ _ZTSSs: > .sleb128 0 > .byte 0 > .uleb128 0x7b > - .8byte .LVL7 > - .4byte 0x51ac > - .4byte 0x5057 > + .8byte .LVL8 > + .4byte 0x519f > + .4byte 0x504a > .uleb128 0x79 > .uleb128 0x1 > .byte 0x50 > @@ -9052,7 +9048,7 @@ _ZTSSs: > .sleb128 0 > .byte 0 > .uleb128 0x7c > - .8byte .LVL9 > + .8byte .LVL12 > .uleb128 0x79 > .uleb128 0x1 > .byte 0x50 > @@ -9062,8 +9058,8 @@ _ZTSSs: > .byte 0 > .byte 0 > .uleb128 0x78 > - .8byte .LVL10 > - .4byte 0x51bc > + .8byte .LVL13 > + .4byte 0x51af > .uleb128 0x79 > .uleb128 0x1 > .byte 0x50 > @@ -9073,10 +9069,10 @@ _ZTSSs: > .byte 0 > .byte 0 > .uleb128 0x10 > - .4byte 0x5082 > + .4byte 0x5075 > .uleb128 0x55 > .byte 0x8 > - .4byte 0x5088 > + .4byte 0x507b > .uleb128 0x10 > .4byte 0x4872 > .uleb128 0x7d > @@ -9088,9 +9084,9 @@ _ZTSSs: > .8byte .LFE1300-.LFB1300 > .uleb128 0x1 > .byte 0x9c > - .4byte 0x50c7 > + .4byte 0x50ba > .uleb128 0x78 > - .8byte .LVL11 > + .8byte .LVL14 > .4byte 0x4f63 > .uleb128 0x7e > .uleb128 0x1 > @@ -9165,13 +9161,13 @@ _ZTSSs: > .uleb128 0x86 > .4byte .LASF799 > .4byte 0x20d > - .4byte 0x5192 > + .4byte 0x5185 > .uleb128 0x19 > .4byte 0x221 > .byte 0 > .uleb128 0x87 > .4byte .LASF801 > - .4byte 0x51ac > + .4byte 0x519f > .uleb128 0x19 > .4byte 0x20d > .uleb128 0x19 > @@ -9181,7 +9177,7 @@ _ZTSSs: > .byte 0 > .uleb128 0x87 > .4byte .LASF802 > - .4byte 0x51bc > + .4byte 0x51af > .uleb128 0x19 > .4byte 0x20d > .byte 0 > @@ -11207,16 +11203,30 @@ _ZTSSs: > .8byte 0 > .LLST1: > .8byte .LVL4-.Ltext0 > - .8byte .LVL8-.Ltext0 > + .8byte .LVL7-.Ltext0 > + .2byte 0x1 > + .byte 0x64 > + .8byte .LVL7-.Ltext0 > + .8byte .LVL9-.Ltext0 > .2byte 0x3 > .byte 0x8f > .sleb128 32 > .byte 0x9f > - .8byte .LVL8-.Ltext0 > - .8byte .LVL9-1-.Ltext0 > + .8byte .LVL9-.Ltext0 > + .8byte .LVL10-.Ltext0 > + .2byte 0x1 > + .byte 0x64 > + .8byte .LVL10-.Ltext0 > + .8byte .LVL11-.Ltext0 > + .2byte 0x3 > + .byte 0x8f > + .sleb128 32 > + .byte 0x9f > + .8byte .LVL11-.Ltext0 > + .8byte .LVL12-1-.Ltext0 > .2byte 0x1 > .byte 0x50 > - .8byte .LVL9-1-.Ltext0 > + .8byte .LVL12-1-.Ltext0 > .8byte .LFE1299-.Ltext0 > .2byte 0x3 > .byte 0x8f > @@ -11377,8 +11387,6 @@ _ZTSSs: > .string "tm_isdst" > .LASF654: > .string "grouping" > -.LASF804: > - .string "GNU C++ 4.8.4 -g -O1 -std=c++11 -fstack-protector" > .LASF20: > .string "_lock" > .LASF107: > @@ -12523,6 +12531,8 @@ _ZTSSs: > .string "_ZNKSs17find_first_not_ofERKSsm" > .LASF30: > .string "__FILE" > +.LASF804: > + .string "GNU C++ 4.8.4 -g -O1 -std=c++11 -fPIE -fstack-protector" > .LASF247: > .string "_ZNSspLESt16initializer_listIcE" > .LASF587: > diff --git a/gdb/testsuite/gdb.dwarf2/entry-value-typedef-amd64.S b/gdb/testsuite/gdb.dwarf2/entry-value-typedef-amd64.S > index 1d86941ff1b..22fad8684d2 100644 > --- a/gdb/testsuite/gdb.dwarf2/entry-value-typedef-amd64.S > +++ b/gdb/testsuite/gdb.dwarf2/entry-value-typedef-amd64.S > @@ -19,7 +19,7 @@ > > $ g++ --version > g++ (Ubuntu 9.4.0-1ubuntu1~20.04.1) 9.4.0 > - $ g++ entry-value-typedef.cpp -O1 -S -g -o entry-value-typedef-amd64.S > + $ g++ entry-value-typedef.cpp -O1 -fPIE -S -g -o entry-value-typedef-amd64.S > */ > > .file "entry-value-typedef.cpp" > @@ -13647,8 +13647,6 @@ _ZTINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE: > .section .debug_str,"MS",@progbits,1 > .LASF739: > .string "int_p_sep_by_space" > -.LASF920: > - .string "GNU C++14 9.4.0 -mtune=generic -march=x86-64 -g -O1 -fasynchronous-unwind-tables -fstack-protector-strong -fstack-clash-protection -fcf-protection" > .LASF547: > .string "char" > .LASF487: > @@ -15399,6 +15397,8 @@ _ZTINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE: > .string "__int_least8_t" > .LASF495: > .string "base" > +.LASF920: > + .string "GNU C++14 9.4.0 -mtune=generic -march=x86-64 -g -O1 -fPIE -fasynchronous-unwind-tables -fstack-protector-strong -fstack-clash-protection -fcf-protection" > .LASF17: > .string "const_pointer" > .LASF764: Great. Thanks Simon. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] gdb/testsuite: re-compile entry-value-typedef .S files with -fPIE 2022-08-19 12:42 ` Luis Machado @ 2022-08-19 14:14 ` Simon Marchi 0 siblings, 0 replies; 7+ messages in thread From: Simon Marchi @ 2022-08-19 14:14 UTC (permalink / raw) To: Luis Machado, gdb-patches > Great. Thanks Simon. Pushed, thanks for the report. Simon ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH v3] gdb: call check_typedef at beginning of dwarf_expr_context::fetch_result 2022-08-18 17:34 ` Simon Marchi 2022-08-18 18:37 ` [PATCH] gdb/testsuite: re-compile entry-value-typedef .S files with -fPIE Simon Marchi @ 2022-08-19 10:35 ` Luis Machado 1 sibling, 0 replies; 7+ messages in thread From: Luis Machado @ 2022-08-19 10:35 UTC (permalink / raw) To: Simon Marchi, Simon Marchi, gdb-patches On 8/18/22 18:34, Simon Marchi wrote: > On 8/18/22 12:51, Luis Machado wrote: >> On 8/18/22 17:16, Simon Marchi via Gdb-patches wrote: >>> On 7/28/22 11:33, Simon Marchi wrote: >>>> From: Simon Marchi <simon.marchi@polymtl.ca> >>>> >>>> New in this version: >>>> >>>> - add architecture check in test >>>> - add aarch64 version of the .S >>>> >>>> Bug 29374 shows this crash: >>>> >>>> $ ./gdb -nx --data-directory=data-directory -q -batch -ex "catch throw" -ex r -ex bt a.out >>>> ... >>>> /home/simark/src/binutils-gdb/gdb/../gdbsupport/array-view.h:217: internal-error: copy: Assertion `dest.size () == src.size ()' failed. >>>> >>>> The backtrace is: >>>> >>>> #0 internal_error (file=0x5555606504c0 "/home/simark/src/binutils-gdb/gdb/../gdbsupport/array-view.h", line=217, fmt=0x55556064b700 "%s: Assertion `%s' failed.") at /home/simark/src/binutils-gdb/gdbsupport/errors.cc:51 >>>> #1 0x000055555d41c0bb in gdb::copy<unsigned char const, unsigned char> (src=..., dest=...) at /home/simark/src/binutils-gdb/gdb/../gdbsupport/array-view.h:217 >>>> #2 0x000055555deef28c in dwarf_expr_context::fetch_result (this=0x7fffffffb830, type=0x621007a86830, subobj_type=0x621007a86830, subobj_offset=0, as_lval=false) at /home/simark/src/binutils-gdb/gdb/dwarf2/expr.c:1040 >>>> #3 0x000055555def0015 in dwarf_expr_context::evaluate (this=0x7fffffffb830, addr=0x62f00004313e "0", len=1, as_lval=false, per_cu=0x60b000069550, frame=0x621007c9e910, addr_info=0x0, type=0x621007a86830, subobj_type=0x621007a86830, subobj_offset=0) at /home/simark/src/binutils-gdb/gdb/dwarf2/expr.c:1091 >>>> #4 0x000055555e084327 in dwarf2_evaluate_loc_desc_full (type=0x621007a86830, frame=0x621007c9e910, data=0x62f00004313e "0", size=1, per_cu=0x60b000069550, per_objfile=0x613000006080, subobj_type=0x621007a86830, subobj_byte_offset=0, as_lval=false) at /home/simark/src/binutils-gdb/gdb/dwarf2/loc.c:1485 >>>> #5 0x000055555e0849e2 in dwarf2_evaluate_loc_desc (type=0x621007a86830, frame=0x621007c9e910, data=0x62f00004313e "0", size=1, per_cu=0x60b000069550, per_objfile=0x613000006080, as_lval=false) at /home/simark/src/binutils-gdb/gdb/dwarf2/loc.c:1529 >>>> #6 0x000055555e0828c6 in dwarf_entry_parameter_to_value (parameter=0x621007a96e58, deref_size=0x0, type=0x621007a86830, caller_frame=0x621007c9e910, per_cu=0x60b000069550, per_objfile=0x613000006080) at /home/simark/src/binutils-gdb/gdb/dwarf2/loc.c:1235 >>>> #7 0x000055555e082f55 in value_of_dwarf_reg_entry (type=0x621007a86890, frame=0x621007acc510, kind=CALL_SITE_PARAMETER_DWARF_REG, kind_u=...) at /home/simark/src/binutils-gdb/gdb/dwarf2/loc.c:1332 >>>> #8 0x000055555e083449 in value_of_dwarf_block_entry (type=0x621007a86890, frame=0x621007acc510, block=0x61e000033568 "T\004\205\001\240\004\004\243\001T\237\004\240\004\261\004\001T\004\261\004\304\005\004\243\001T\237\004\304\005\310\005\001T\004\310\005\311\005\004\243\001T\237", block_len=1) at /home/simark/src/binutils-gdb/gdb/dwarf2/loc.c:1365 >>>> #9 0x000055555e094d40 in loclist_read_variable_at_entry (symbol=0x621007a99bd0, frame=0x621007acc510) at /home/simark/src/binutils-gdb/gdb/dwarf2/loc.c:3889 >>>> #10 0x000055555f5192e0 in read_frame_arg (fp_opts=..., sym=0x621007a99bd0, frame=0x621007acc510, argp=0x7fffffffbf20, entryargp=0x7fffffffbf60) at /home/simark/src/binutils-gdb/gdb/stack.c:559 >>>> #11 0x000055555f51c352 in print_frame_args (fp_opts=..., func=0x621007a99ad0, frame=0x621007acc510, num=-1, stream=0x6030000bad90) at /home/simark/src/binutils-gdb/gdb/stack.c:887 >>>> #12 0x000055555f521919 in print_frame (fp_opts=..., frame=0x621007acc510, print_level=1, print_what=LOCATION, print_args=1, sal=...) at /home/simark/src/binutils-gdb/gdb/stack.c:1390 >>>> #13 0x000055555f51f22e in print_frame_info (fp_opts=..., frame=0x621007acc510, print_level=1, print_what=LOCATION, print_args=1, set_current_sal=0) at /home/simark/src/binutils-gdb/gdb/stack.c:1116 >>>> #14 0x000055555f526c6d in backtrace_command_1 (fp_opts=..., bt_opts=..., count_exp=0x0, from_tty=0) at /home/simark/src/binutils-gdb/gdb/stack.c:2079 >>>> #15 0x000055555f527ae5 in backtrace_command (arg=0x0, from_tty=0) at /home/simark/src/binutils-gdb/gdb/stack.c:2198 >>>> >>>> The problem is that the type that gets passed down to >>>> dwarf_expr_context::fetch_result (the type of a variable of which we're >>>> trying to read the entry value) is a typedef whose size has never been >>>> computed yet (check_typedef has never been called on it). As we get in >>>> the DWARF_VALUE_STACK case (line 1028 of dwarf2/expr.c), the `len` >>>> variable is therefore set to 0, instead of the actual type length. We >>>> then call allocate_value on subobj_type, which does call check_typedef, >>>> so the length of the typedef gets filled in at that point. We end up >>>> passing to the copy function a source array view of length 0 and a >>>> target array view of length 4, and the assertion fails. >>>> >>>> Fix this by calling check_typedef on both type and subobj_type at the >>>> beginning of fetch_result. >>>> >>>> I tried writing a test for this using the DWARF assembler, but I haven't >>>> succeeded. It's possible that we need to get into this specific code >>>> path (value_of_dwarf_reg_entry and all) to manage to get to >>>> dwarf_expr_context::fetch_result with a typedef type that has never been >>>> resolved. In all my attempts, the typedef would always be resolved >>>> already, so the bug wouldn't show up. >>>> >>>> As a fallback, I made a gdb.dwarf2 test with compiler-generated .S >>>> files. I don't particularly like those, but I think it's better than no >>>> test. The .cpp source code is the smallest reproducer I am able to make >>>> from the reproducer given in the bug (thanks to Pedro for suggestions on >>>> how to minimize it further than I had). Since I tested on both amd64 >>>> and aarch64, I added versions of the test for these two architectures. >>>> >>>> Change-Id: I182733ad08e34df40d8bcc47af72c482fabf4900 >>>> Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29374 >>>> --- >>>> gdb/dwarf2/expr.c | 5 + >>>> .../gdb.dwarf2/entry-value-typedef-aarch64.S | 12885 +++++++++++++ >>>> .../gdb.dwarf2/entry-value-typedef-amd64.S | 15545 ++++++++++++++++ >>>> .../gdb.dwarf2/entry-value-typedef.cpp | 36 + >>>> .../gdb.dwarf2/entry-value-typedef.exp | 45 + >>>> 5 files changed, 28516 insertions(+) >>>> create mode 100644 gdb/testsuite/gdb.dwarf2/entry-value-typedef-aarch64.S >>>> create mode 100644 gdb/testsuite/gdb.dwarf2/entry-value-typedef-amd64.S >>>> create mode 100644 gdb/testsuite/gdb.dwarf2/entry-value-typedef.cpp >>>> create mode 100644 gdb/testsuite/gdb.dwarf2/entry-value-typedef.exp >>> >>> I pushed this patch. >>> >>> Simon >> >> It seems newer compilers on aarch64 (g++ 9.4.0 or 11.2.0) don't like this test. They complain with: >> >> gdb compile failed, /usr/bin/ld: /tmp/cc0vjoZT.o: relocation R_AARCH64_ADR_PREL_PG_HI21 against symbol `_ZNSsD1Ev@@GLIBCXX_3.4' which may bin >> d externally can not be used when making a shared object; recompile with -fPIC >> /usr/bin/ld: /tmp/cc0vjoZT.o(.text+0x38): unresolvable R_AARCH64_ADR_PREL_PG_HI21 relocation against symbol `_ZNSsD1Ev@@GLIBCXX_3.4' >> /usr/bin/ld: final link failed: bad value >> >> So the test doesn't run properly. > > Is is that the old compiler I used (g++ 4.8 on Ubuntu 14.04, on the > compile farm) generated non-position-independent code, but the linker > of the newer toolchains try to build a position-independent executable? > If so, we can re-generate the assembly files with -fPIE, and it should > work, right? I'll give this a try, I have access to an AArch64 machine > with Debian 11 & g++ 10.2.1. > > Simon Yes, that might be the case. Let me know if you'd like me to regenerate it. ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2022-08-19 14:14 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <20220728153340.4052079-1-simon.marchi@efficios.com>
2022-08-18 16:16 ` [PATCH v3] gdb: call check_typedef at beginning of dwarf_expr_context::fetch_result Simon Marchi
2022-08-18 16:51 ` Luis Machado
2022-08-18 17:34 ` Simon Marchi
2022-08-18 18:37 ` [PATCH] gdb/testsuite: re-compile entry-value-typedef .S files with -fPIE Simon Marchi
2022-08-19 12:42 ` Luis Machado
2022-08-19 14:14 ` Simon Marchi
2022-08-19 10:35 ` [PATCH v3] gdb: call check_typedef at beginning of dwarf_expr_context::fetch_result Luis Machado
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).