* 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 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
* 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
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).