* [PATCH][gdb/testsuite] Fix gdb.dwarf2/dw2-dir-file-name.exp
@ 2022-08-11 11:58 Tom de Vries
2022-08-12 9:33 ` Luis Machado
0 siblings, 1 reply; 12+ messages in thread
From: Tom de Vries @ 2022-08-11 11:58 UTC (permalink / raw)
To: gdb-patches
Hi,
When running test-case gdb.dwarf2/dw2-dir-file-name.exp on x86_64-linux, we
have:
...
(gdb) break compdir_missing__ldir_missing__file_basename^M
Breakpoint 2 at 0x4004c4: file tmp-dw2-dir-file-name.c, line 999.^M
(gdb) continue^M
Continuing.^M
^M
Breakpoint 2, 0x00000000004004c4 in \
compdir_missing__ldir_missing__file_basename () \
at tmp-dw2-dir-file-name.c:999^M
(gdb) PASS: gdb.dwarf2/dw2-dir-file-name.exp: \
compdir_missing__ldir_missing__file_basename: continue to breakpoint: \
compdir_missing__ldir_missing__file_basename
...
When trying to set a breakpoint on
compdir_missing__ldir_missing__file_basename, the architecture-specific
prologue skipper starts at 0x4004c0 and skips past two insns, to 0x4004c4:
...
00000000004004c0 <compdir_missing__ldir_missing__file_basename>:
4004c0: 55 push %rbp
4004c1: 48 89 e5 mov %rsp,%rbp
4004c4: 8b 05 72 1b 20 00 mov 0x201b72(%rip),%eax # 60203c <v>
4004ca: 83 c0 01 add $0x1,%eax
4004cd: 89 05 69 1b 20 00 mov %eax,0x201b69(%rip) # 60203c <v>
4004d3: 90 nop
4004d4: 5d pop %rbp
4004d5: c3 ret
...
And because the line table info is rudamentary:
...
CU: tmp-dw2-dir-file-name.c:
File name Line number Starting address View Stmt
tmp-dw2-dir-file-name.c 999 0x4004c0 x
tmp-dw2-dir-file-name.c 1000 0x4004d6 x
tmp-dw2-dir-file-name.c - 0x4004d6
...
the address does not fall at an actual line, so the breakpoint is shown with
address, both when setting it and hitting it.
when running the test-case with aarch64-linux, we have similarly:
...
(gdb) break compdir_missing__ldir_missing__file_basename^M
Breakpoint 2 at 0x400618: file tmp-dw2-dir-file-name.c, line 999.^M
...
due to the architecture-specific prologue skipper starting at 0x400610 and
skipping past two insns, to 0x400618:
...
0000000000400610 <compdir_missing__ldir_missing__file_basename>:
400610: 90000100 adrp x0, 420000 <__libc_start_main@GLIBC_2.17>
400614: 9100b000 add x0, x0, #0x2c
400618: b9400000 ldr w0, [x0]
40061c: 11000401 add w1, w0, #0x1
400620: 90000100 adrp x0, 420000 <__libc_start_main@GLIBC_2.17>
400624: 9100b000 add x0, x0, #0x2c
400628: b9000001 str w1, [x0]
40062c: d503201f nop
400630: d65f03c0 ret
...
But interestingly, the aarch64 architecture-specific prologue skipper is
wrong. There is no prologue, and the breakpoint should be set at 0x400610.
By using "break *compdir_missing__ldir_missing__file_basename"
we can get the breakpoint set at 0x400610:
...
(gdb) break *compdir_missing__ldir_missing__file_basename^M
Breakpoint 2 at 0x400610: file tmp-dw2-dir-file-name.c, line 999.^M
...
and make the test-case independent of prologue analysis.
This requires us to update the expected patterns.
The fix ensures that once the aarch64 architecture-specific prologue skipper
will be fixed, this test-case won't start failing.
Tested on x86_64-linux.
Any comments?
Thanks,
- Tom
[gdb/testsuite] Fix gdb.dwarf2/dw2-dir-file-name.exp
---
gdb/testsuite/gdb.dwarf2/dw2-dir-file-name.exp | 8 ++++----
gdb/testsuite/lib/gdb.exp | 7 ++++++-
2 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/gdb/testsuite/gdb.dwarf2/dw2-dir-file-name.exp b/gdb/testsuite/gdb.dwarf2/dw2-dir-file-name.exp
index 4d3f767f597..4c4c1ff07af 100644
--- a/gdb/testsuite/gdb.dwarf2/dw2-dir-file-name.exp
+++ b/gdb/testsuite/gdb.dwarf2/dw2-dir-file-name.exp
@@ -396,20 +396,20 @@ proc test { func compdir filename } {
error "not absolute"
}
- gdb_breakpoint $func
+ gdb_breakpoint *$func
gdb_continue_to_breakpoint $func "$func \\(\\) at .*"
gdb_test_no_output "set filename-display absolute"
verbose -log "expect: ${absolute}"
- gdb_test "frame" " in $func \\(\\) at [string_to_regexp ${absolute}]:999" "absolute"
+ gdb_test "frame" "#0 $func \\(\\) at [string_to_regexp ${absolute}]:999" "absolute"
gdb_test_no_output "set filename-display basename"
verbose -log "expect: [file tail $filename]"
- gdb_test "frame" " in $func \\(\\) at [string_to_regexp [file tail $filename]]:999" "basename"
+ gdb_test "frame" "#0 $func \\(\\) at [string_to_regexp [file tail $filename]]:999" "basename"
gdb_test_no_output "set filename-display relative"
verbose -log "expect: $filename"
- gdb_test "frame" " in $func \\(\\) at [string_to_regexp $filename]:999" "relative"
+ gdb_test "frame" "#0 $func \\(\\) at [string_to_regexp $filename]:999" "relative"
}
}
diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp
index a8f25b5f0dd..70fc019eeb9 100644
--- a/gdb/testsuite/lib/gdb.exp
+++ b/gdb/testsuite/lib/gdb.exp
@@ -787,9 +787,14 @@ proc gdb_continue_to_breakpoint {name {location_pattern .*}} {
global gdb_prompt
set full_name "continue to breakpoint: $name"
+ set re_at_in " (at|in) "
+ if { [regexp $re_at_in $location_pattern] } {
+ set re_at_in " "
+ }
+
set kfail_pattern "Process record does not support instruction 0xfae64 at.*"
gdb_test_multiple "continue" $full_name {
- -re "(?:Breakpoint|Temporary breakpoint) .* (at|in) $location_pattern\r\n$gdb_prompt $" {
+ -re "(?:Breakpoint|Temporary breakpoint) .*$re_at_in$location_pattern\r\n$gdb_prompt $" {
pass $full_name
}
-re "\[\r\n\]*(?:$kfail_pattern)\[\r\n\]+$gdb_prompt $" {
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH][gdb/testsuite] Fix gdb.dwarf2/dw2-dir-file-name.exp
2022-08-11 11:58 [PATCH][gdb/testsuite] Fix gdb.dwarf2/dw2-dir-file-name.exp Tom de Vries
@ 2022-08-12 9:33 ` Luis Machado
2022-08-15 16:01 ` Carl Love
0 siblings, 1 reply; 12+ messages in thread
From: Luis Machado @ 2022-08-12 9:33 UTC (permalink / raw)
To: Tom de Vries, gdb-patches
On 8/11/22 12:58, Tom de Vries wrote:
> Hi,
>
> When running test-case gdb.dwarf2/dw2-dir-file-name.exp on x86_64-linux, we
> have:
> ...
> (gdb) break compdir_missing__ldir_missing__file_basename^M
> Breakpoint 2 at 0x4004c4: file tmp-dw2-dir-file-name.c, line 999.^M
> (gdb) continue^M
> Continuing.^M
> ^M
> Breakpoint 2, 0x00000000004004c4 in \
> compdir_missing__ldir_missing__file_basename () \
> at tmp-dw2-dir-file-name.c:999^M
> (gdb) PASS: gdb.dwarf2/dw2-dir-file-name.exp: \
> compdir_missing__ldir_missing__file_basename: continue to breakpoint: \
> compdir_missing__ldir_missing__file_basename
> ...
>
> When trying to set a breakpoint on
> compdir_missing__ldir_missing__file_basename, the architecture-specific
> prologue skipper starts at 0x4004c0 and skips past two insns, to 0x4004c4:
> ...
> 00000000004004c0 <compdir_missing__ldir_missing__file_basename>:
> 4004c0: 55 push %rbp
> 4004c1: 48 89 e5 mov %rsp,%rbp
> 4004c4: 8b 05 72 1b 20 00 mov 0x201b72(%rip),%eax # 60203c <v>
> 4004ca: 83 c0 01 add $0x1,%eax
> 4004cd: 89 05 69 1b 20 00 mov %eax,0x201b69(%rip) # 60203c <v>
> 4004d3: 90 nop
> 4004d4: 5d pop %rbp
> 4004d5: c3 ret
> ...
>
> And because the line table info is rudamentary:
> ...
> CU: tmp-dw2-dir-file-name.c:
> File name Line number Starting address View Stmt
> tmp-dw2-dir-file-name.c 999 0x4004c0 x
> tmp-dw2-dir-file-name.c 1000 0x4004d6 x
> tmp-dw2-dir-file-name.c - 0x4004d6
> ...
> the address does not fall at an actual line, so the breakpoint is shown with
> address, both when setting it and hitting it.
>
> when running the test-case with aarch64-linux, we have similarly:
> ...
> (gdb) break compdir_missing__ldir_missing__file_basename^M
> Breakpoint 2 at 0x400618: file tmp-dw2-dir-file-name.c, line 999.^M
> ...
> due to the architecture-specific prologue skipper starting at 0x400610 and
> skipping past two insns, to 0x400618:
> ...
> 0000000000400610 <compdir_missing__ldir_missing__file_basename>:
> 400610: 90000100 adrp x0, 420000 <__libc_start_main@GLIBC_2.17>
> 400614: 9100b000 add x0, x0, #0x2c
> 400618: b9400000 ldr w0, [x0]
> 40061c: 11000401 add w1, w0, #0x1
> 400620: 90000100 adrp x0, 420000 <__libc_start_main@GLIBC_2.17>
> 400624: 9100b000 add x0, x0, #0x2c
> 400628: b9000001 str w1, [x0]
> 40062c: d503201f nop
> 400630: d65f03c0 ret
> ...
>
> But interestingly, the aarch64 architecture-specific prologue skipper is
> wrong. There is no prologue, and the breakpoint should be set at 0x400610.
>
> By using "break *compdir_missing__ldir_missing__file_basename"
> we can get the breakpoint set at 0x400610:
> ...
> (gdb) break *compdir_missing__ldir_missing__file_basename^M
> Breakpoint 2 at 0x400610: file tmp-dw2-dir-file-name.c, line 999.^M
> ...
> and make the test-case independent of prologue analysis.
>
> This requires us to update the expected patterns.
>
> The fix ensures that once the aarch64 architecture-specific prologue skipper
> will be fixed, this test-case won't start failing.
>
> Tested on x86_64-linux.
>
> Any comments?
>
> Thanks,
> - Tom
>
> [gdb/testsuite] Fix gdb.dwarf2/dw2-dir-file-name.exp
>
> ---
> gdb/testsuite/gdb.dwarf2/dw2-dir-file-name.exp | 8 ++++----
> gdb/testsuite/lib/gdb.exp | 7 ++++++-
> 2 files changed, 10 insertions(+), 5 deletions(-)
>
> diff --git a/gdb/testsuite/gdb.dwarf2/dw2-dir-file-name.exp b/gdb/testsuite/gdb.dwarf2/dw2-dir-file-name.exp
> index 4d3f767f597..4c4c1ff07af 100644
> --- a/gdb/testsuite/gdb.dwarf2/dw2-dir-file-name.exp
> +++ b/gdb/testsuite/gdb.dwarf2/dw2-dir-file-name.exp
> @@ -396,20 +396,20 @@ proc test { func compdir filename } {
> error "not absolute"
> }
>
> - gdb_breakpoint $func
> + gdb_breakpoint *$func
> gdb_continue_to_breakpoint $func "$func \\(\\) at .*"
>
> gdb_test_no_output "set filename-display absolute"
> verbose -log "expect: ${absolute}"
> - gdb_test "frame" " in $func \\(\\) at [string_to_regexp ${absolute}]:999" "absolute"
> + gdb_test "frame" "#0 $func \\(\\) at [string_to_regexp ${absolute}]:999" "absolute"
>
> gdb_test_no_output "set filename-display basename"
> verbose -log "expect: [file tail $filename]"
> - gdb_test "frame" " in $func \\(\\) at [string_to_regexp [file tail $filename]]:999" "basename"
> + gdb_test "frame" "#0 $func \\(\\) at [string_to_regexp [file tail $filename]]:999" "basename"
>
> gdb_test_no_output "set filename-display relative"
> verbose -log "expect: $filename"
> - gdb_test "frame" " in $func \\(\\) at [string_to_regexp $filename]:999" "relative"
> + gdb_test "frame" "#0 $func \\(\\) at [string_to_regexp $filename]:999" "relative"
> }
> }
>
> diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp
> index a8f25b5f0dd..70fc019eeb9 100644
> --- a/gdb/testsuite/lib/gdb.exp
> +++ b/gdb/testsuite/lib/gdb.exp
> @@ -787,9 +787,14 @@ proc gdb_continue_to_breakpoint {name {location_pattern .*}} {
> global gdb_prompt
> set full_name "continue to breakpoint: $name"
>
> + set re_at_in " (at|in) "
> + if { [regexp $re_at_in $location_pattern] } {
> + set re_at_in " "
> + }
> +
> set kfail_pattern "Process record does not support instruction 0xfae64 at.*"
> gdb_test_multiple "continue" $full_name {
> - -re "(?:Breakpoint|Temporary breakpoint) .* (at|in) $location_pattern\r\n$gdb_prompt $" {
> + -re "(?:Breakpoint|Temporary breakpoint) .*$re_at_in$location_pattern\r\n$gdb_prompt $" {
> pass $full_name
> }
> -re "\[\r\n\]*(?:$kfail_pattern)\[\r\n\]+$gdb_prompt $" {
LGTM
I agree that having a test that doesn't rely on prologue analysis is a good move. I'll track the aarch64 prologue analysis
hiccup separate.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH][gdb/testsuite] Fix gdb.dwarf2/dw2-dir-file-name.exp
2022-08-12 9:33 ` Luis Machado
@ 2022-08-15 16:01 ` Carl Love
2022-08-15 16:54 ` Carl Love
0 siblings, 1 reply; 12+ messages in thread
From: Carl Love @ 2022-08-15 16:01 UTC (permalink / raw)
To: Luis Machado, Tom de Vries, gdb-patches
Tom:
Looks like the patch was applied last Friday. We are now seeing 129
test failures related to this commit on PowerPC. The failures are seen
on Power 8, 9 and 10.
Here is an initial bit of the failures:
...
Breakpoint 2 at 0x100006e0: file tmp-dw2-dir-file-name.c, line 999.
(gdb) continue
Continuing.
[Inferior 1 (process 2520351) exited normally]
(gdb) FAIL: gdb.dwarf2/dw2-dir-file-name.exp: compdir_missing__ldir_missing__file_basename: continue to breakpoint: compdir_missing__ldir_missing__file_basename (the program exited)
set filename-display absolute
(gdb) PASS: gdb.dwarf2/dw2-dir-file-name.exp: compdir_missing__ldir_missing__file_basename: set filename-display absolute
expect: /home/carll/GDB/build-current/gdb/testsuite/outputs/gdb.dwarf2/dw2-dir-file-name/dw2-dir-file-name.d/rdir/tmp-dw2-dir-file-name.c
frame
No stack.
(gdb) FAIL: gdb.dwarf2/dw2-dir-file-name.exp: compdir_missing__ldir_missing__file_basename: absolute
set filename-display basename
(gdb) PASS: gdb.dwarf2/dw2-dir-file-name.exp: compdir_missing__ldir_missing__file_basename: set filename-display basename
expect: tmp-dw2-dir-file-name.c
frame
No stack.
(gdb) FAIL: gdb.dwarf2/dw2-dir-file-name.exp: compdir_missing__ldir_missing__file_basename: basename
set filename-display relative
(gdb) PASS: gdb.dwarf2/dw2-dir-file-name.exp: compdir_missing__ldir_missing__file_basename: set filename-display relative
expect: tmp-dw2-dir-file-name.c
frame
No stack.
(gdb) FAIL: gdb.dwarf2/dw2-dir-file-name.exp: compdir_missing__ldir_missing__file_basename: relative
set directories
(gdb) PASS: gdb.dwarf2/dw2-dir-file-name.exp: compdir_missing__ldir_missing__file_relative: set directories
break *compdir_missing__ldir_missing__file_relative
Breakpoint 3 at 0x10000728: file fdir/tmp-dw2-dir-file-name.c, line 999.
(gdb) continue
The program is not being run.
etc.
=== gdb Summary ===
# of expected passes 129
# of unexpected failures 128
I have not had time yet to try and dig into the failures to figure out
the cause. I will take a look at the failures to see what is going on.
Anyway, just wanted to let you know what I am seeing on PowerPC.
Carl
On Fri, 2022-08-12 at 10:33 +0100, Luis Machado via Gdb-patches wrote:
> On 8/11/22 12:58, Tom de Vries wrote:
> > Hi,
> >
> > When running test-case gdb.dwarf2/dw2-dir-file-name.exp on x86_64-
> > linux, we
> > have:
> > ...
> > (gdb) break compdir_missing__ldir_missing__file_basename^M
> > Breakpoint 2 at 0x4004c4: file tmp-dw2-dir-file-name.c, line 999.^M
> > (gdb) continue^M
> > Continuing.^M
> > ^M
> > Breakpoint 2, 0x00000000004004c4 in \
> > compdir_missing__ldir_missing__file_basename () \
> > at tmp-dw2-dir-file-name.c:999^M
> > (gdb) PASS: gdb.dwarf2/dw2-dir-file-name.exp: \
> > compdir_missing__ldir_missing__file_basename: continue to
> > breakpoint: \
> > compdir_missing__ldir_missing__file_basename
> > ...
> >
> > When trying to set a breakpoint on
> > compdir_missing__ldir_missing__file_basename, the architecture-
> > specific
> > prologue skipper starts at 0x4004c0 and skips past two insns, to
> > 0x4004c4:
> > ...
> > 00000000004004c0 <compdir_missing__ldir_missing__file_basename>:
> > 4004c0: 55 push %rbp
> > 4004c1: 48 89 e5 mov %rsp,%rbp
> > 4004c4: 8b 05 72 1b 20
> > 00 mov 0x201b72(%rip),%eax # 60203c <v>
> > 4004ca: 83 c0 01 add $0x1,%eax
> > 4004cd: 89 05 69 1b 20
> > 00 mov %eax,0x201b69(%rip) # 60203c <v>
> > 4004d3: 90 nop
> > 4004d4: 5d pop %rbp
> > 4004d5: c3 ret
> > ...
> >
> > And because the line table info is rudamentary:
> > ...
> > CU: tmp-dw2-dir-file-name.c:
> > File name Line number Starting
> > address View Stmt
> > tmp-dw2-dir-file-
> > name.c 999 0x4004c0 x
> > tmp-dw2-dir-file-
> > name.c 1000 0x4004d6 x
> > tmp-dw2-dir-file-name.c - 0x4004d6
> > ...
> > the address does not fall at an actual line, so the breakpoint is
> > shown with
> > address, both when setting it and hitting it.
> >
> > when running the test-case with aarch64-linux, we have similarly:
> > ...
> > (gdb) break compdir_missing__ldir_missing__file_basename^M
> > Breakpoint 2 at 0x400618: file tmp-dw2-dir-file-name.c, line 999.^M
> > ...
> > due to the architecture-specific prologue skipper starting at
> > 0x400610 and
> > skipping past two insns, to 0x400618:
> > ...
> > 0000000000400610 <compdir_missing__ldir_missing__file_basename>:
> > 400610: 90000100 adrp x0, 420000 <
> > __libc_start_main@GLIBC_2.17>
> > 400614: 9100b000 add x0, x0, #0x2c
> > 400618: b9400000 ldr w0, [x0]
> > 40061c: 11000401 add w1, w0, #0x1
> > 400620: 90000100 adrp x0, 420000 <
> > __libc_start_main@GLIBC_2.17>
> > 400624: 9100b000 add x0, x0, #0x2c
> > 400628: b9000001 str w1, [x0]
> > 40062c: d503201f nop
> > 400630: d65f03c0 ret
> > ...
> >
> > But interestingly, the aarch64 architecture-specific prologue
> > skipper is
> > wrong. There is no prologue, and the breakpoint should be set at
> > 0x400610.
> >
> > By using "break *compdir_missing__ldir_missing__file_basename"
> > we can get the breakpoint set at 0x400610:
> > ...
> > (gdb) break *compdir_missing__ldir_missing__file_basename^M
> > Breakpoint 2 at 0x400610: file tmp-dw2-dir-file-name.c, line 999.^M
> > ...
> > and make the test-case independent of prologue analysis.
> >
> > This requires us to update the expected patterns.
> >
> > The fix ensures that once the aarch64 architecture-specific
> > prologue skipper
> > will be fixed, this test-case won't start failing.
> >
> > Tested on x86_64-linux.
> >
> > Any comments?
> >
> > Thanks,
> > - Tom
> >
> > [gdb/testsuite] Fix gdb.dwarf2/dw2-dir-file-name.exp
> >
> > ---
> > gdb/testsuite/gdb.dwarf2/dw2-dir-file-name.exp | 8 ++++----
> > gdb/testsuite/lib/gdb.exp | 7 ++++++-
> > 2 files changed, 10 insertions(+), 5 deletions(-)
> >
> > diff --git a/gdb/testsuite/gdb.dwarf2/dw2-dir-file-name.exp
> > b/gdb/testsuite/gdb.dwarf2/dw2-dir-file-name.exp
> > index 4d3f767f597..4c4c1ff07af 100644
> > --- a/gdb/testsuite/gdb.dwarf2/dw2-dir-file-name.exp
> > +++ b/gdb/testsuite/gdb.dwarf2/dw2-dir-file-name.exp
> > @@ -396,20 +396,20 @@ proc test { func compdir filename } {
> > error "not absolute"
> > }
> >
> > - gdb_breakpoint $func
> > + gdb_breakpoint *$func
> > gdb_continue_to_breakpoint $func "$func \\(\\) at .*"
> >
> > gdb_test_no_output "set filename-display absolute"
> > verbose -log "expect: ${absolute}"
> > - gdb_test "frame" " in $func \\(\\) at [string_to_regexp
> > ${absolute}]:999" "absolute"
> > + gdb_test "frame" "#0 $func \\(\\) at [string_to_regexp
> > ${absolute}]:999" "absolute"
> >
> > gdb_test_no_output "set filename-display basename"
> > verbose -log "expect: [file tail $filename]"
> > - gdb_test "frame" " in $func \\(\\) at [string_to_regexp [file
> > tail $filename]]:999" "basename"
> > + gdb_test "frame" "#0 $func \\(\\) at [string_to_regexp [file
> > tail $filename]]:999" "basename"
> >
> > gdb_test_no_output "set filename-display relative"
> > verbose -log "expect: $filename"
> > - gdb_test "frame" " in $func \\(\\) at [string_to_regexp
> > $filename]:999" "relative"
> > + gdb_test "frame" "#0 $func \\(\\) at [string_to_regexp
> > $filename]:999" "relative"
> > }
> > }
> >
> > diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp
> > index a8f25b5f0dd..70fc019eeb9 100644
> > --- a/gdb/testsuite/lib/gdb.exp
> > +++ b/gdb/testsuite/lib/gdb.exp
> > @@ -787,9 +787,14 @@ proc gdb_continue_to_breakpoint {name
> > {location_pattern .*}} {
> > global gdb_prompt
> > set full_name "continue to breakpoint: $name"
> >
> > + set re_at_in " (at|in) "
> > + if { [regexp $re_at_in $location_pattern] } {
> > + set re_at_in " "
> > + }
> > +
> > set kfail_pattern "Process record does not support
> > instruction 0xfae64 at.*"
> > gdb_test_multiple "continue" $full_name {
> > - -re "(?:Breakpoint|Temporary breakpoint) .* (at|in)
> > $location_pattern\r\n$gdb_prompt $" {
> > + -re "(?:Breakpoint|Temporary breakpoint)
> > .*$re_at_in$location_pattern\r\n$gdb_prompt $" {
> > pass $full_name
> > }
> > -re "\[\r\n\]*(?:$kfail_pattern)\[\r\n\]+$gdb_prompt $" {
>
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH][gdb/testsuite] Fix gdb.dwarf2/dw2-dir-file-name.exp
2022-08-15 16:01 ` Carl Love
@ 2022-08-15 16:54 ` Carl Love
2022-08-15 19:12 ` will schmidt
` (2 more replies)
0 siblings, 3 replies; 12+ messages in thread
From: Carl Love @ 2022-08-15 16:54 UTC (permalink / raw)
To: Luis Machado, Tom de Vries, gdb-patches, Ulrich Weigand
Tom:
OK, I took a look at how the test used to work and how it is now
working and I see what the issue is.
PowerPC has two entry points, local and global. The test used to set
the breakpoint for the function at the local entry point. With your
changes, the breakpoint is now being set at the global breakpoint which
is before the local breakpoint. The function is actually entered at
the local breakpoint thus gdb never "sees" the breakpoint that was set.
Specfically, here is the objdump for the test:
00000000100006e0 <compdir_missing__ldir_missing__file_basename>:
100006e0: 02 10 40 3c lis r2,4098 <- Global entry point
100006e4: 00 7f 42 38 addi r2,r2,32512
100006e8: f8 ff e1 fb std r31,-8(r1)
100006ec: d1 ff 21 f8 stdu r1,-48(r1)
100006f0: 78 0b 3f 7c mr r31,r1
100006f4: 00 00 00 60 nop <- Local entry point
100006f8: 28 81 22 39 addi r9,r2,-32472
100006fc: 00 00 29 81 lwz r9,0(r9)
10000700: 01 00 49 39 addi r10,r9,1
10000704: 00 00 00 60 nop
10000708: 28 81 22 39 addi r9,r2,-32472
1000070c: 00 00 49 91 stw r10,0(r9)
10000710: 30 00 3f 38 addi r1,r31,48
10000714: f8 ff e1 eb ld r31,-8(r1)
10000718: 20 00 80 4e blr
When I look at the output before the patch, we see:
Breakpoint 2, 0x00000000100006f4 in compdir_missing__ldir_missing__file_basename () at tmp-dw2-dir-file-name.c:999
(gdb) PASS: gdb.dwarf2/dw2-dir-file-name.exp: compdir_missing__ldir_missing__file_basename: continue to breakpoint: compdir_missing__ldir_missing__file_basename
set filename-display absolute
Note the breakpoint 2 address is 0x00000000100006f4 which is on the
NOP. Instructions at addresses 0x100006e0 to 100006f0 are part of the
code when the function is called via the global entry point. So
previously, the breakpoint was set at local entry point.
With the patch, we now see:
Breakpoint 2 at 0x100006e0: file tmp-dw2-dir-file-name.c, line 999.
(gdb) continue
Continuing.
[Inferior 1 (process 2520351) exited normally]
(gdb) FAIL: gdb.dwarf2/dw2-dir-file-name.exp: compdir_missing__ldir_missing__file_basename: continue to breakpoint: compdir_missing__ldir_missing__file_basename (the program exited)
Now we note that the breakpoint 2 is set at 0x100006e0 which is the
global entry point.
It looks to me that we need to make sure we set the breakpoint at the
local address.
Off hand, I am not sure how to get your changes to "proc
gdb_continue_to_breakpoint" to select the local entry point not the
global entry point. Perhaps Ulrich has some ideas???
Carl Love
On Mon, 2022-08-15 at 09:01 -0700, Carl Love wrote:
>
> Looks like the patch was applied last Friday. We are now seeing 129
> test failures related to this commit on PowerPC. The failures are
> seen
> on Power 8, 9 and 10.
>
> Here is an initial bit of the failures:
>
> ...
> Breakpoint 2 at 0x100006e0: file tmp-dw2-dir-file-name.c, line 999.
> (gdb) continue
> Continuing.
> [Inferior 1 (process 2520351) exited normally]
> (gdb) FAIL: gdb.dwarf2/dw2-dir-file-name.exp:
> compdir_missing__ldir_missing__file_basename: continue to breakpoint:
> compdir_missing__ldir_missing__file_basename (the program exited)
> set filename-display absolute
> (gdb) PASS: gdb.dwarf2/dw2-dir-file-name.exp:
> compdir_missing__ldir_missing__file_basename: set filename-display
> absolute
> expect: /home/carll/GDB/build-
> current/gdb/testsuite/outputs/gdb.dwarf2/dw2-dir-file-name/dw2-dir-
> file-name.d/rdir/tmp-dw2-dir-file-name.c
> frame
> No stack.
> (gdb) FAIL: gdb.dwarf2/dw2-dir-file-name.exp:
> compdir_missing__ldir_missing__file_basename: absolute
> set filename-display basename
> (gdb) PASS: gdb.dwarf2/dw2-dir-file-name.exp:
> compdir_missing__ldir_missing__file_basename: set filename-display
> basename
> expect: tmp-dw2-dir-file-name.c
> frame
> No stack.
> (gdb) FAIL: gdb.dwarf2/dw2-dir-file-name.exp:
> compdir_missing__ldir_missing__file_basename: basename
> set filename-display relative
> (gdb) PASS: gdb.dwarf2/dw2-dir-file-name.exp:
> compdir_missing__ldir_missing__file_basename: set filename-display
> relative
> expect: tmp-dw2-dir-file-name.c
> frame
> No stack.
> (gdb) FAIL: gdb.dwarf2/dw2-dir-file-name.exp:
> compdir_missing__ldir_missing__file_basename: relative
> set directories
> (gdb) PASS: gdb.dwarf2/dw2-dir-file-name.exp:
> compdir_missing__ldir_missing__file_relative: set directories
> break *compdir_missing__ldir_missing__file_relative
> Breakpoint 3 at 0x10000728: file fdir/tmp-dw2-dir-file-name.c, line
> 999.
> (gdb) continue
> The program is not being run.
>
> etc.
>
> === gdb Summary ===
>
> # of expected passes 129
> # of unexpected failures 128
>
> I have not had time yet to try and dig into the failures to figure
> out
> the cause. I will take a look at the failures to see what is going
> on.
>
> Anyway, just wanted to let you know what I am seeing on PowerPC.
>
> Carl
>
> On Fri, 2022-08-12 at 10:33 +0100, Luis Machado via Gdb-patches
> wrote:
> > On 8/11/22 12:58, Tom de Vries wrote:
> > > Hi,
> > >
> > > When running test-case gdb.dwarf2/dw2-dir-file-name.exp on
> > > x86_64-
> > > linux, we
> > > have:
> > > ...
> > > (gdb) break compdir_missing__ldir_missing__file_basename^M
> > > Breakpoint 2 at 0x4004c4: file tmp-dw2-dir-file-name.c, line
> > > 999.^M
> > > (gdb) continue^M
> > > Continuing.^M
> > > ^M
> > > Breakpoint 2, 0x00000000004004c4 in \
> > > compdir_missing__ldir_missing__file_basename () \
> > > at tmp-dw2-dir-file-name.c:999^M
> > > (gdb) PASS: gdb.dwarf2/dw2-dir-file-name.exp: \
> > > compdir_missing__ldir_missing__file_basename: continue to
> > > breakpoint: \
> > > compdir_missing__ldir_missing__file_basename
> > > ...
> > >
> > > When trying to set a breakpoint on
> > > compdir_missing__ldir_missing__file_basename, the architecture-
> > > specific
> > > prologue skipper starts at 0x4004c0 and skips past two insns, to
> > > 0x4004c4:
> > > ...
> > > 00000000004004c0 <compdir_missing__ldir_missing__file_basename>:
> > > 4004c0: 55 push %rbp
> > > 4004c1: 48 89 e5 mov %rsp,%rbp
> > > 4004c4: 8b 05 72 1b 20
> > > 00 mov 0x201b72(%rip),%eax # 60203c <v>
> > > 4004ca: 83 c0 01 add $0x1,%eax
> > > 4004cd: 89 05 69 1b 20
> > > 00 mov %eax,0x201b69(%rip) # 60203c <v>
> > > 4004d3: 90 nop
> > > 4004d4: 5d pop %rbp
> > > 4004d5: c3 ret
> > > ...
> > >
> > > And because the line table info is rudamentary:
> > > ...
> > > CU: tmp-dw2-dir-file-name.c:
> > > File name Line number Starting
> > > address View Stmt
> > > tmp-dw2-dir-file-
> > > name.c 999 0x4004c0 x
> > > tmp-dw2-dir-file-
> > > name.c 1000 0x4004d6 x
> > > tmp-dw2-dir-file-name.c - 0x4004d6
> > > ...
> > > the address does not fall at an actual line, so the breakpoint is
> > > shown with
> > > address, both when setting it and hitting it.
> > >
> > > when running the test-case with aarch64-linux, we have similarly:
> > > ...
> > > (gdb) break compdir_missing__ldir_missing__file_basename^M
> > > Breakpoint 2 at 0x400618: file tmp-dw2-dir-file-name.c, line
> > > 999.^M
> > > ...
> > > due to the architecture-specific prologue skipper starting at
> > > 0x400610 and
> > > skipping past two insns, to 0x400618:
> > > ...
> > > 0000000000400610 <compdir_missing__ldir_missing__file_basename>:
> > > 400610: 90000100 adrp x0, 420000 <
> > > __libc_start_main@GLIBC_2.17>
> > > 400614: 9100b000 add x0, x0, #0x2c
> > > 400618: b9400000 ldr w0, [x0]
> > > 40061c: 11000401 add w1, w0, #0x1
> > > 400620: 90000100 adrp x0, 420000 <
> > > __libc_start_main@GLIBC_2.17>
> > > 400624: 9100b000 add x0, x0, #0x2c
> > > 400628: b9000001 str w1, [x0]
> > > 40062c: d503201f nop
> > > 400630: d65f03c0 ret
> > > ...
> > >
> > > But interestingly, the aarch64 architecture-specific prologue
> > > skipper is
> > > wrong. There is no prologue, and the breakpoint should be set at
> > > 0x400610.
> > >
> > > By using "break *compdir_missing__ldir_missing__file_basename"
> > > we can get the breakpoint set at 0x400610:
> > > ...
> > > (gdb) break *compdir_missing__ldir_missing__file_basename^M
> > > Breakpoint 2 at 0x400610: file tmp-dw2-dir-file-name.c, line
> > > 999.^M
> > > ...
> > > and make the test-case independent of prologue analysis.
> > >
> > > This requires us to update the expected patterns.
> > >
> > > The fix ensures that once the aarch64 architecture-specific
> > > prologue skipper
> > > will be fixed, this test-case won't start failing.
> > >
> > > Tested on x86_64-linux.
> > >
> > > Any comments?
> > >
> > > Thanks,
> > > - Tom
> > >
> > > [gdb/testsuite] Fix gdb.dwarf2/dw2-dir-file-name.exp
> > >
> > > ---
> > > gdb/testsuite/gdb.dwarf2/dw2-dir-file-name.exp | 8 ++++----
> > > gdb/testsuite/lib/gdb.exp | 7 ++++++-
> > > 2 files changed, 10 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/gdb/testsuite/gdb.dwarf2/dw2-dir-file-name.exp
> > > b/gdb/testsuite/gdb.dwarf2/dw2-dir-file-name.exp
> > > index 4d3f767f597..4c4c1ff07af 100644
> > > --- a/gdb/testsuite/gdb.dwarf2/dw2-dir-file-name.exp
> > > +++ b/gdb/testsuite/gdb.dwarf2/dw2-dir-file-name.exp
> > > @@ -396,20 +396,20 @@ proc test { func compdir filename } {
> > > error "not absolute"
> > > }
> > >
> > > - gdb_breakpoint $func
> > > + gdb_breakpoint *$func
> > > gdb_continue_to_breakpoint $func "$func \\(\\) at .*"
> > >
> > > gdb_test_no_output "set filename-display absolute"
> > > verbose -log "expect: ${absolute}"
> > > - gdb_test "frame" " in $func \\(\\) at [string_to_regexp
> > > ${absolute}]:999" "absolute"
> > > + gdb_test "frame" "#0 $func \\(\\) at [string_to_regexp
> > > ${absolute}]:999" "absolute"
> > >
> > > gdb_test_no_output "set filename-display basename"
> > > verbose -log "expect: [file tail $filename]"
> > > - gdb_test "frame" " in $func \\(\\) at [string_to_regexp [file
> > > tail $filename]]:999" "basename"
> > > + gdb_test "frame" "#0 $func \\(\\) at [string_to_regexp [file
> > > tail $filename]]:999" "basename"
> > >
> > > gdb_test_no_output "set filename-display relative"
> > > verbose -log "expect: $filename"
> > > - gdb_test "frame" " in $func \\(\\) at [string_to_regexp
> > > $filename]:999" "relative"
> > > + gdb_test "frame" "#0 $func \\(\\) at [string_to_regexp
> > > $filename]:999" "relative"
> > > }
> > > }
> > >
> > > diff --git a/gdb/testsuite/lib/gdb.exp
> > > b/gdb/testsuite/lib/gdb.exp
> > > index a8f25b5f0dd..70fc019eeb9 100644
> > > --- a/gdb/testsuite/lib/gdb.exp
> > > +++ b/gdb/testsuite/lib/gdb.exp
> > > @@ -787,9 +787,14 @@ proc gdb_continue_to_breakpoint {name
> > > {location_pattern .*}} {
> > > global gdb_prompt
> > > set full_name "continue to breakpoint: $name"
> > >
> > > + set re_at_in " (at|in) " <-NEED TO FIX TO ALWAYS GIVE local entry point for POWERPC ??
> > > + if { [regexp $re_at_in $location_pattern] } {
> > > + set re_at_in " "
> > > + }
> > > +
> > > set kfail_pattern "Process record does not support
> > > instruction 0xfae64 at.*"
> > > gdb_test_multiple "continue" $full_name {
> > > - -re "(?:Breakpoint|Temporary breakpoint) .* (at|in)
> > > $location_pattern\r\n$gdb_prompt $" {
> > > + -re "(?:Breakpoint|Temporary breakpoint)
> > > .*$re_at_in$location_pattern\r\n$gdb_prompt $" {
> > > pass $full_name
> > > }
> > > -re "\[\r\n\]*(?:$kfail_pattern)\[\r\n\]+$gdb_prompt $"
> > > {
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH][gdb/testsuite] Fix gdb.dwarf2/dw2-dir-file-name.exp
2022-08-15 16:54 ` Carl Love
@ 2022-08-15 19:12 ` will schmidt
2022-08-15 19:31 ` Thiago Jung Bauermann
2022-08-16 7:43 ` Luis Machado
2022-08-17 12:01 ` Ulrich Weigand
2022-09-01 14:16 ` Tom de Vries
2 siblings, 2 replies; 12+ messages in thread
From: will schmidt @ 2022-08-15 19:12 UTC (permalink / raw)
To: Carl Love, Luis Machado, Tom de Vries, gdb-patches, Ulrich Weigand
On Mon, 2022-08-15 at 09:54 -0700, Carl Love wrote:
> Tom:
>
> OK, I took a look at how the test used to work and how it is now
> working and I see what the issue is.
>
> PowerPC has two entry points, local and global. The test used to set
> the breakpoint for the function at the local entry point. With your
> changes, the breakpoint is now being set at the global breakpoint
> which
> is before the local breakpoint. The function is actually entered at
> the local breakpoint thus gdb never "sees" the breakpoint that was
> set.
> Specfically, here is the objdump for the test:
>
> 00000000100006e0 <compdir_missing__ldir_missing__file_basename>:
> 100006e0: 02 10 40
> 3c lis r2,4098 <- Global entry point
> 100006e4: 00 7f 42 38 addi r2,r2,32512
> 100006e8: f8 ff e1 fb std r31,-8(r1)
> 100006ec: d1 ff 21 f8 stdu r1,-48(r1)
> 100006f0: 78 0b 3f 7c mr r31,r1
> 100006f4: 00 00 00
> 60 nop <- Local entry point
> 100006f8: 28 81 22 39 addi r9,r2,-32472
> 100006fc: 00 00 29 81 lwz r9,0(r9)
> 10000700: 01 00 49 39 addi r10,r9,1
> 10000704: 00 00 00 60 nop
> 10000708: 28 81 22 39 addi r9,r2,-32472
> 1000070c: 00 00 49 91 stw r10,0(r9)
> 10000710: 30 00 3f 38 addi r1,r31,48
> 10000714: f8 ff e1 eb ld r31,-8(r1)
> 10000718: 20 00 80 4e blr
>
> When I look at the output before the patch, we see:
>
> Breakpoint 2, 0x00000000100006f4 in
> compdir_missing__ldir_missing__file_basename () at tmp-dw2-dir-file-
> name.c:999
>
> (gdb) PASS: gdb.dwarf2/dw2-dir-file-name.exp:
> compdir_missing__ldir_missing__file_basename: continue to breakpoint:
> compdir_missing__ldir_missing__file_basename
> set filename-display absolute
>
>
> Note the breakpoint 2 address is 0x00000000100006f4 which is on the
> NOP. Instructions at addresses 0x100006e0 to 100006f0 are part of
> the
> code when the function is called via the global entry point. So
> previously, the breakpoint was set at local entry point.
>
> With the patch, we now see:
>
> Breakpoint 2 at 0x100006e0: file tmp-dw2-dir-file-name.c, line
> 999.
> (gdb) continue
>
> Continuing.
> [Inferior 1 (process 2520351) exited normally]
> (gdb) FAIL: gdb.dwarf2/dw2-dir-file-name.exp:
> compdir_missing__ldir_missing__file_basename: continue to breakpoint:
> compdir_missing__ldir_missing__file_basename (the program exited)
>
> Now we note that the breakpoint 2 is set at 0x100006e0 which is the
> global entry point.
>
> It looks to me that we need to make sure we set the breakpoint at the
> local address.
>
> Off hand, I am not sure how to get your changes to "proc
> gdb_continue_to_breakpoint" to select the local entry point not the
> global entry point. Perhaps Ulrich has some ideas???
From a glance that the patch that updated dw2-dir-file-name.exp;
( commit cd919f5533cc8aa495acd75a6f059e5fcf2e6af9 )
the change there was effectively
- gdb_breakpoint $func
+ gdb_breakpoint *$func
with assorted regexp changes to match.
The patch description goes into detail, but I interpret the gist of it
as avoiding the aarch64 architecture prologue skipper, since that
prologue skipper does something wrong, with entanglements in the line
table info.
The powerpc prologue skipper (wherever it is) was presumably handling
the local/global entry points properly. Since the test now species a
specific address (*$func), the prologue skipper is no longer involved.
The patch should probably be reverted, but I defer to others if I've
misunderstood part of this issue..
Thanks
-Will
>
> Carl Love
>
>
> On Mon, 2022-08-15 at 09:01 -0700, Carl Love wrote:
>
> > Looks like the patch was applied last Friday. We are now seeing
> > 129
> > test failures related to this commit on PowerPC. The failures are
> > seen
> > on Power 8, 9 and 10.
> >
> > Here is an initial bit of the failures:
> >
> > ...
> > Breakpoint 2 at 0x100006e0: file tmp-dw2-dir-file-name.c, line 999.
> > (gdb) continue
> > Continuing.
> > [Inferior 1 (process 2520351) exited normally]
> > (gdb) FAIL: gdb.dwarf2/dw2-dir-file-name.exp:
> > compdir_missing__ldir_missing__file_basename: continue to
> > breakpoint:
> > compdir_missing__ldir_missing__file_basename (the program exited)
> > set filename-display absolute
> > (gdb) PASS: gdb.dwarf2/dw2-dir-file-name.exp:
> > compdir_missing__ldir_missing__file_basename: set filename-display
> > absolute
> > expect: /home/carll/GDB/build-
> > current/gdb/testsuite/outputs/gdb.dwarf2/dw2-dir-file-name/dw2-dir-
> > file-name.d/rdir/tmp-dw2-dir-file-name.c
> > frame
> > No stack.
> > (gdb) FAIL: gdb.dwarf2/dw2-dir-file-name.exp:
> > compdir_missing__ldir_missing__file_basename: absolute
> > set filename-display basename
> > (gdb) PASS: gdb.dwarf2/dw2-dir-file-name.exp:
> > compdir_missing__ldir_missing__file_basename: set filename-display
> > basename
> > expect: tmp-dw2-dir-file-name.c
> > frame
> > No stack.
> > (gdb) FAIL: gdb.dwarf2/dw2-dir-file-name.exp:
> > compdir_missing__ldir_missing__file_basename: basename
> > set filename-display relative
> > (gdb) PASS: gdb.dwarf2/dw2-dir-file-name.exp:
> > compdir_missing__ldir_missing__file_basename: set filename-display
> > relative
> > expect: tmp-dw2-dir-file-name.c
> > frame
> > No stack.
> > (gdb) FAIL: gdb.dwarf2/dw2-dir-file-name.exp:
> > compdir_missing__ldir_missing__file_basename: relative
> > set directories
> > (gdb) PASS: gdb.dwarf2/dw2-dir-file-name.exp:
> > compdir_missing__ldir_missing__file_relative: set directories
> > break *compdir_missing__ldir_missing__file_relative
> > Breakpoint 3 at 0x10000728: file fdir/tmp-dw2-dir-file-name.c, line
> > 999.
> > (gdb) continue
> > The program is not being run.
> >
> > etc.
> >
> > === gdb Summary ===
> >
> > # of expected passes 129
> > # of unexpected failures 128
> >
> > I have not had time yet to try and dig into the failures to figure
> > out
> > the cause. I will take a look at the failures to see what is going
> > on.
> >
> > Anyway, just wanted to let you know what I am seeing on PowerPC.
> >
> > Carl
> >
> > On Fri, 2022-08-12 at 10:33 +0100, Luis Machado via Gdb-patches
> > wrote:
> > > On 8/11/22 12:58, Tom de Vries wrote:
> > > > Hi,
> > > >
> > > > When running test-case gdb.dwarf2/dw2-dir-file-name.exp on
> > > > x86_64-
> > > > linux, we
> > > > have:
> > > > ...
> > > > (gdb) break compdir_missing__ldir_missing__file_basename^M
> > > > Breakpoint 2 at 0x4004c4: file tmp-dw2-dir-file-name.c, line
> > > > 999.^M
> > > > (gdb) continue^M
> > > > Continuing.^M
> > > > ^M
> > > > Breakpoint 2, 0x00000000004004c4 in \
> > > > compdir_missing__ldir_missing__file_basename () \
> > > > at tmp-dw2-dir-file-name.c:999^M
> > > > (gdb) PASS: gdb.dwarf2/dw2-dir-file-name.exp: \
> > > > compdir_missing__ldir_missing__file_basename: continue to
> > > > breakpoint: \
> > > > compdir_missing__ldir_missing__file_basename
> > > > ...
> > > >
> > > > When trying to set a breakpoint on
> > > > compdir_missing__ldir_missing__file_basename, the architecture-
> > > > specific
> > > > prologue skipper starts at 0x4004c0 and skips past two insns,
> > > > to
> > > > 0x4004c4:
> > > > ...
> > > > 00000000004004c0
> > > > <compdir_missing__ldir_missing__file_basename>:
> > > > 4004c0: 55 push %rbp
> > > > 4004c1: 48 89 e5 mov %rsp,%rbp
> > > > 4004c4: 8b 05 72 1b 20
> > > > 00 mov 0x201b72(%rip),%eax # 60203c <v>
> > > > 4004ca: 83 c0 01 add $0x1,%eax
> > > > 4004cd: 89 05 69 1b 20
> > > > 00 mov %eax,0x201b69(%rip) # 60203c <v>
> > > > 4004d3: 90 nop
> > > > 4004d4: 5d pop %rbp
> > > > 4004d5: c3 ret
> > > > ...
> > > >
> > > > And because the line table info is rudamentary:
> > > > ...
> > > > CU: tmp-dw2-dir-file-name.c:
> > > > File name Line number Starting
> > > > address View Stmt
> > > > tmp-dw2-dir-file-
> > > > name.c 999 0x4004c0 x
> > > > tmp-dw2-dir-file-
> > > > name.c 1000 0x4004d6 x
> > > > tmp-dw2-dir-file-name.c - 0x4004d6
> > > > ...
> > > > the address does not fall at an actual line, so the breakpoint
> > > > is
> > > > shown with
> > > > address, both when setting it and hitting it.
> > > >
> > > > when running the test-case with aarch64-linux, we have
> > > > similarly:
> > > > ...
> > > > (gdb) break compdir_missing__ldir_missing__file_basename^M
> > > > Breakpoint 2 at 0x400618: file tmp-dw2-dir-file-name.c, line
> > > > 999.^M
> > > > ...
> > > > due to the architecture-specific prologue skipper starting at
> > > > 0x400610 and
> > > > skipping past two insns, to 0x400618:
> > > > ...
> > > > 0000000000400610
> > > > <compdir_missing__ldir_missing__file_basename>:
> > > > 400610: 90000100 adrp x0, 420000 <
> > > > __libc_start_main@GLIBC_2.17>
> > > > 400614: 9100b000 add x0, x0, #0x2c
> > > > 400618: b9400000 ldr w0, [x0]
> > > > 40061c: 11000401 add w1, w0, #0x1
> > > > 400620: 90000100 adrp x0, 420000 <
> > > > __libc_start_main@GLIBC_2.17>
> > > > 400624: 9100b000 add x0, x0, #0x2c
> > > > 400628: b9000001 str w1, [x0]
> > > > 40062c: d503201f nop
> > > > 400630: d65f03c0 ret
> > > > ...
> > > >
> > > > But interestingly, the aarch64 architecture-specific prologue
> > > > skipper is
> > > > wrong. There is no prologue, and the breakpoint should be set
> > > > at
> > > > 0x400610.
> > > >
> > > > By using "break *compdir_missing__ldir_missing__file_basename"
> > > > we can get the breakpoint set at 0x400610:
> > > > ...
> > > > (gdb) break *compdir_missing__ldir_missing__file_basename^M
> > > > Breakpoint 2 at 0x400610: file tmp-dw2-dir-file-name.c, line
> > > > 999.^M
> > > > ...
> > > > and make the test-case independent of prologue analysis.
> > > >
> > > > This requires us to update the expected patterns.
> > > >
> > > > The fix ensures that once the aarch64 architecture-specific
> > > > prologue skipper
> > > > will be fixed, this test-case won't start failing.
> > > >
> > > > Tested on x86_64-linux.
> > > >
> > > > Any comments?
> > > >
> > > > Thanks,
> > > > - Tom
> > > >
> > > > [gdb/testsuite] Fix gdb.dwarf2/dw2-dir-file-name.exp
> > > >
> > > > ---
> > > > gdb/testsuite/gdb.dwarf2/dw2-dir-file-name.exp | 8 ++++----
> > > > gdb/testsuite/lib/gdb.exp | 7 ++++++-
> > > > 2 files changed, 10 insertions(+), 5 deletions(-)
> > > >
> > > > diff --git a/gdb/testsuite/gdb.dwarf2/dw2-dir-file-name.exp
> > > > b/gdb/testsuite/gdb.dwarf2/dw2-dir-file-name.exp
> > > > index 4d3f767f597..4c4c1ff07af 100644
> > > > --- a/gdb/testsuite/gdb.dwarf2/dw2-dir-file-name.exp
> > > > +++ b/gdb/testsuite/gdb.dwarf2/dw2-dir-file-name.exp
> > > > @@ -396,20 +396,20 @@ proc test { func compdir filename } {
> > > > error "not absolute"
> > > > }
> > > >
> > > > - gdb_breakpoint $func
> > > > + gdb_breakpoint *$func
> > > > gdb_continue_to_breakpoint $func "$func \\(\\) at .*"
> > > >
> > > > gdb_test_no_output "set filename-display absolute"
> > > > verbose -log "expect: ${absolute}"
> > > > - gdb_test "frame" " in $func \\(\\) at [string_to_regexp
> > > > ${absolute}]:999" "absolute"
> > > > + gdb_test "frame" "#0 $func \\(\\) at [string_to_regexp
> > > > ${absolute}]:999" "absolute"
> > > >
> > > > gdb_test_no_output "set filename-display basename"
> > > > verbose -log "expect: [file tail $filename]"
> > > > - gdb_test "frame" " in $func \\(\\) at [string_to_regexp
> > > > [file
> > > > tail $filename]]:999" "basename"
> > > > + gdb_test "frame" "#0 $func \\(\\) at [string_to_regexp
> > > > [file
> > > > tail $filename]]:999" "basename"
> > > >
> > > > gdb_test_no_output "set filename-display relative"
> > > > verbose -log "expect: $filename"
> > > > - gdb_test "frame" " in $func \\(\\) at [string_to_regexp
> > > > $filename]:999" "relative"
> > > > + gdb_test "frame" "#0 $func \\(\\) at [string_to_regexp
> > > > $filename]:999" "relative"
> > > > }
> > > > }
> > > >
> > > > diff --git a/gdb/testsuite/lib/gdb.exp
> > > > b/gdb/testsuite/lib/gdb.exp
> > > > index a8f25b5f0dd..70fc019eeb9 100644
> > > > --- a/gdb/testsuite/lib/gdb.exp
> > > > +++ b/gdb/testsuite/lib/gdb.exp
> > > > @@ -787,9 +787,14 @@ proc gdb_continue_to_breakpoint {name
> > > > {location_pattern .*}} {
> > > > global gdb_prompt
> > > > set full_name "continue to breakpoint: $name"
> > > >
> > > > + set re_at_in " (at|in) " <-NEED
> > > > TO FIX TO ALWAYS GIVE local entry point for POWERPC
> > > > ??
> > > >
> > > > + if { [regexp $re_at_in $location_pattern] } {
> > > > + set re_at_in " "
> > > > + }
> > > > +
> > > > set kfail_pattern "Process record does not support
> > > > instruction 0xfae64 at.*"
> > > > gdb_test_multiple "continue" $full_name {
> > > > - -re "(?:Breakpoint|Temporary breakpoint) .* (at|in)
> > > > $location_pattern\r\n$gdb_prompt $" {
> > > > + -re "(?:Breakpoint|Temporary breakpoint)
> > > > .*$re_at_in$location_pattern\r\n$gdb_prompt $" {
> > > > pass $full_name
> > > > }
> > > > -re "\[\r\n\]*(?:$kfail_pattern)\[\r\n\]+$gdb_prompt $"
> > > > {
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH][gdb/testsuite] Fix gdb.dwarf2/dw2-dir-file-name.exp
2022-08-15 19:12 ` will schmidt
@ 2022-08-15 19:31 ` Thiago Jung Bauermann
2022-08-15 21:33 ` will schmidt
2022-08-16 7:43 ` Luis Machado
1 sibling, 1 reply; 12+ messages in thread
From: Thiago Jung Bauermann @ 2022-08-15 19:31 UTC (permalink / raw)
To: will schmidt
Cc: Carl Love, Luis Machado, Tom de Vries, Ulrich Weigand, gdb-patches
Hello,
will schmidt via Gdb-patches <gdb-patches@sourceware.org> writes:
> On Mon, 2022-08-15 at 09:54 -0700, Carl Love wrote:
>> Tom:
>>
>> OK, I took a look at how the test used to work and how it is now
>> working and I see what the issue is.
>>
>> PowerPC has two entry points, local and global. The test used to set
>> the breakpoint for the function at the local entry point. With your
>> changes, the breakpoint is now being set at the global breakpoint
>> which
>> is before the local breakpoint. The function is actually entered at
>> the local breakpoint thus gdb never "sees" the breakpoint that was
>> set.
[ <snip> ]
>> It looks to me that we need to make sure we set the breakpoint at the
>> local address.
>>
>> Off hand, I am not sure how to get your changes to "proc
>> gdb_continue_to_breakpoint" to select the local entry point not the
>> global entry point. Perhaps Ulrich has some ideas???
>
>
> From a glance that the patch that updated dw2-dir-file-name.exp;
> ( commit cd919f5533cc8aa495acd75a6f059e5fcf2e6af9 )
> the change there was effectively
>
> - gdb_breakpoint $func
> + gdb_breakpoint *$func
>
> with assorted regexp changes to match.
>
> The patch description goes into detail, but I interpret the gist of it
> as avoiding the aarch64 architecture prologue skipper, since that
> prologue skipper does something wrong, with entanglements in the line
> table info.
>
> The powerpc prologue skipper (wherever it is) was presumably handling
> the local/global entry points properly. Since the test now species a
> specific address (*$func), the prologue skipper is no longer involved.
>
> The patch should probably be reverted, but I defer to others if I've
> misunderstood part of this issue..
Is it possible to force the compiler to use the global entry point?
Perhaps by calling the function via a function pointer rather than as a
regular function call? That would allow preserving the change to the
testcase and making it work on ppc64le.
--
Thiago
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH][gdb/testsuite] Fix gdb.dwarf2/dw2-dir-file-name.exp
2022-08-15 19:31 ` Thiago Jung Bauermann
@ 2022-08-15 21:33 ` will schmidt
0 siblings, 0 replies; 12+ messages in thread
From: will schmidt @ 2022-08-15 21:33 UTC (permalink / raw)
To: Thiago Jung Bauermann
Cc: Carl Love, Luis Machado, Tom de Vries, Ulrich Weigand, gdb-patches
On Mon, 2022-08-15 at 19:31 +0000, Thiago Jung Bauermann wrote:
> Hello,
>
> will schmidt via Gdb-patches <gdb-patches@sourceware.org> writes:
>
> > On Mon, 2022-08-15 at 09:54 -0700, Carl Love wrote:
> > > Tom:
> > >
> > > OK, I took a look at how the test used to work and how it is now
> > > working and I see what the issue is.
> > >
> > > PowerPC has two entry points, local and global. The test used to
> > > set
> > > the breakpoint for the function at the local entry point. With
> > > your
> > > changes, the breakpoint is now being set at the global breakpoint
> > > which
> > > is before the local breakpoint. The function is actually entered
> > > at
> > > the local breakpoint thus gdb never "sees" the breakpoint that
> > > was
> > > set.
>
> [ <snip> ]
>
> > > It looks to me that we need to make sure we set the breakpoint at
> > > the
> > > local address.
> > >
> > > Off hand, I am not sure how to get your changes to "proc
> > > gdb_continue_to_breakpoint" to select the local entry point not
> > > the
> > > global entry point. Perhaps Ulrich has some ideas???
> >
> > From a glance that the patch that updated dw2-dir-file-name.exp;
> > ( commit cd919f5533cc8aa495acd75a6f059e5fcf2e6af9 )
> > the change there was effectively
> >
> > - gdb_breakpoint $func
> > + gdb_breakpoint *$func
> >
> > with assorted regexp changes to match.
> >
> > The patch description goes into detail, but I interpret the gist of
> > it
> > as avoiding the aarch64 architecture prologue skipper, since that
> > prologue skipper does something wrong, with entanglements in the
> > line
> > table info.
> >
> > The powerpc prologue skipper (wherever it is) was presumably
> > handling
> > the local/global entry points properly. Since the test now species
> > a
> > specific address (*$func), the prologue skipper is no longer
> > involved.
> >
> > The patch should probably be reverted, but I defer to others if
> > I've
> > misunderstood part of this issue..
>
> Is it possible to force the compiler to use the global entry point?
No. :-)
> Perhaps by calling the function via a function pointer rather than as
> a
> regular function call? That would allow preserving the change to the
> testcase and making it work on ppc64le.
>
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH][gdb/testsuite] Fix gdb.dwarf2/dw2-dir-file-name.exp
2022-08-15 19:12 ` will schmidt
2022-08-15 19:31 ` Thiago Jung Bauermann
@ 2022-08-16 7:43 ` Luis Machado
2022-08-16 16:00 ` will schmidt
1 sibling, 1 reply; 12+ messages in thread
From: Luis Machado @ 2022-08-16 7:43 UTC (permalink / raw)
To: will schmidt, Carl Love, Tom de Vries, gdb-patches, Ulrich Weigand
On 8/15/22 20:12, will schmidt wrote:
> On Mon, 2022-08-15 at 09:54 -0700, Carl Love wrote:
>> Tom:
>>
>> OK, I took a look at how the test used to work and how it is now
>> working and I see what the issue is.
>>
>> PowerPC has two entry points, local and global. The test used to set
>> the breakpoint for the function at the local entry point. With your
>> changes, the breakpoint is now being set at the global breakpoint
>> which
>> is before the local breakpoint. The function is actually entered at
>> the local breakpoint thus gdb never "sees" the breakpoint that was
>> set.
>> Specfically, here is the objdump for the test:
>>
>> 00000000100006e0 <compdir_missing__ldir_missing__file_basename>:
>> 100006e0: 02 10 40
>> 3c lis r2,4098 <- Global entry point
>> 100006e4: 00 7f 42 38 addi r2,r2,32512
>> 100006e8: f8 ff e1 fb std r31,-8(r1)
>> 100006ec: d1 ff 21 f8 stdu r1,-48(r1)
>> 100006f0: 78 0b 3f 7c mr r31,r1
>> 100006f4: 00 00 00
>> 60 nop <- Local entry point
>> 100006f8: 28 81 22 39 addi r9,r2,-32472
>> 100006fc: 00 00 29 81 lwz r9,0(r9)
>> 10000700: 01 00 49 39 addi r10,r9,1
>> 10000704: 00 00 00 60 nop
>> 10000708: 28 81 22 39 addi r9,r2,-32472
>> 1000070c: 00 00 49 91 stw r10,0(r9)
>> 10000710: 30 00 3f 38 addi r1,r31,48
>> 10000714: f8 ff e1 eb ld r31,-8(r1)
>> 10000718: 20 00 80 4e blr
>>
>> When I look at the output before the patch, we see:
>>
>> Breakpoint 2, 0x00000000100006f4 in
>> compdir_missing__ldir_missing__file_basename () at tmp-dw2-dir-file-
>> name.c:999
>>
>> (gdb) PASS: gdb.dwarf2/dw2-dir-file-name.exp:
>> compdir_missing__ldir_missing__file_basename: continue to breakpoint:
>> compdir_missing__ldir_missing__file_basename
>> set filename-display absolute
>>
>>
>> Note the breakpoint 2 address is 0x00000000100006f4 which is on the
>> NOP. Instructions at addresses 0x100006e0 to 100006f0 are part of
>> the
>> code when the function is called via the global entry point. So
>> previously, the breakpoint was set at local entry point.
>>
>> With the patch, we now see:
>>
>> Breakpoint 2 at 0x100006e0: file tmp-dw2-dir-file-name.c, line
>> 999.
>> (gdb) continue
>>
>> Continuing.
>> [Inferior 1 (process 2520351) exited normally]
>> (gdb) FAIL: gdb.dwarf2/dw2-dir-file-name.exp:
>> compdir_missing__ldir_missing__file_basename: continue to breakpoint:
>> compdir_missing__ldir_missing__file_basename (the program exited)
>>
>> Now we note that the breakpoint 2 is set at 0x100006e0 which is the
>> global entry point.
>>
>> It looks to me that we need to make sure we set the breakpoint at the
>> local address.
>>
>> Off hand, I am not sure how to get your changes to "proc
>> gdb_continue_to_breakpoint" to select the local entry point not the
>> global entry point. Perhaps Ulrich has some ideas???
>
>
> From a glance that the patch that updated dw2-dir-file-name.exp;
> ( commit cd919f5533cc8aa495acd75a6f059e5fcf2e6af9 )
> the change there was effectively
>
> - gdb_breakpoint $func
> + gdb_breakpoint *$func
>
> with assorted regexp changes to match.
>
> The patch description goes into detail, but I interpret the gist of it
> as avoiding the aarch64 architecture prologue skipper, since that
> prologue skipper does something wrong, with entanglements in the line
> table info.
Though the aarch64 prologue skipper is indeed mistaken here, Tom's patch only
makes the test less reliant on whatever prologue skippers do and instead just
got for a breakpoint straight at the entry point.
It is a void function with void return type, so no much going on. Maybe it needs
to be adapted somewhat to the PowerPC case?
>
> The powerpc prologue skipper (wherever it is) was presumably handling
> the local/global entry points properly. Since the test now species a
> specific address (*$func), the prologue skipper is no longer involved.
How does powerpc handle a breakpoint at a particular address?
>
> The patch should probably be reverted, but I defer to others if I've
> misunderstood part of this issue..
>
> Thanks
> -Will
>
>
>
>
>
>
>
>
>>
>> Carl Love
>>
>>
>> On Mon, 2022-08-15 at 09:01 -0700, Carl Love wrote:
>>
>>> Looks like the patch was applied last Friday. We are now seeing
>>> 129
>>> test failures related to this commit on PowerPC. The failures are
>>> seen
>>> on Power 8, 9 and 10.
>>>
>>> Here is an initial bit of the failures:
>>>
>>> ...
>>> Breakpoint 2 at 0x100006e0: file tmp-dw2-dir-file-name.c, line 999.
>>> (gdb) continue
>>> Continuing.
>>> [Inferior 1 (process 2520351) exited normally]
>>> (gdb) FAIL: gdb.dwarf2/dw2-dir-file-name.exp:
>>> compdir_missing__ldir_missing__file_basename: continue to
>>> breakpoint:
>>> compdir_missing__ldir_missing__file_basename (the program exited)
>>> set filename-display absolute
>>> (gdb) PASS: gdb.dwarf2/dw2-dir-file-name.exp:
>>> compdir_missing__ldir_missing__file_basename: set filename-display
>>> absolute
>>> expect: /home/carll/GDB/build-
>>> current/gdb/testsuite/outputs/gdb.dwarf2/dw2-dir-file-name/dw2-dir-
>>> file-name.d/rdir/tmp-dw2-dir-file-name.c
>>> frame
>>> No stack.
>>> (gdb) FAIL: gdb.dwarf2/dw2-dir-file-name.exp:
>>> compdir_missing__ldir_missing__file_basename: absolute
>>> set filename-display basename
>>> (gdb) PASS: gdb.dwarf2/dw2-dir-file-name.exp:
>>> compdir_missing__ldir_missing__file_basename: set filename-display
>>> basename
>>> expect: tmp-dw2-dir-file-name.c
>>> frame
>>> No stack.
>>> (gdb) FAIL: gdb.dwarf2/dw2-dir-file-name.exp:
>>> compdir_missing__ldir_missing__file_basename: basename
>>> set filename-display relative
>>> (gdb) PASS: gdb.dwarf2/dw2-dir-file-name.exp:
>>> compdir_missing__ldir_missing__file_basename: set filename-display
>>> relative
>>> expect: tmp-dw2-dir-file-name.c
>>> frame
>>> No stack.
>>> (gdb) FAIL: gdb.dwarf2/dw2-dir-file-name.exp:
>>> compdir_missing__ldir_missing__file_basename: relative
>>> set directories
>>> (gdb) PASS: gdb.dwarf2/dw2-dir-file-name.exp:
>>> compdir_missing__ldir_missing__file_relative: set directories
>>> break *compdir_missing__ldir_missing__file_relative
>>> Breakpoint 3 at 0x10000728: file fdir/tmp-dw2-dir-file-name.c, line
>>> 999.
>>> (gdb) continue
>>> The program is not being run.
>>>
>>> etc.
>>>
>>> === gdb Summary ===
>>>
>>> # of expected passes 129
>>> # of unexpected failures 128
>>>
>>> I have not had time yet to try and dig into the failures to figure
>>> out
>>> the cause. I will take a look at the failures to see what is going
>>> on.
>>>
>>> Anyway, just wanted to let you know what I am seeing on PowerPC.
>>>
>>> Carl
>>>
>>> On Fri, 2022-08-12 at 10:33 +0100, Luis Machado via Gdb-patches
>>> wrote:
>>>> On 8/11/22 12:58, Tom de Vries wrote:
>>>>> Hi,
>>>>>
>>>>> When running test-case gdb.dwarf2/dw2-dir-file-name.exp on
>>>>> x86_64-
>>>>> linux, we
>>>>> have:
>>>>> ...
>>>>> (gdb) break compdir_missing__ldir_missing__file_basename^M
>>>>> Breakpoint 2 at 0x4004c4: file tmp-dw2-dir-file-name.c, line
>>>>> 999.^M
>>>>> (gdb) continue^M
>>>>> Continuing.^M
>>>>> ^M
>>>>> Breakpoint 2, 0x00000000004004c4 in \
>>>>> compdir_missing__ldir_missing__file_basename () \
>>>>> at tmp-dw2-dir-file-name.c:999^M
>>>>> (gdb) PASS: gdb.dwarf2/dw2-dir-file-name.exp: \
>>>>> compdir_missing__ldir_missing__file_basename: continue to
>>>>> breakpoint: \
>>>>> compdir_missing__ldir_missing__file_basename
>>>>> ...
>>>>>
>>>>> When trying to set a breakpoint on
>>>>> compdir_missing__ldir_missing__file_basename, the architecture-
>>>>> specific
>>>>> prologue skipper starts at 0x4004c0 and skips past two insns,
>>>>> to
>>>>> 0x4004c4:
>>>>> ...
>>>>> 00000000004004c0
>>>>> <compdir_missing__ldir_missing__file_basename>:
>>>>> 4004c0: 55 push %rbp
>>>>> 4004c1: 48 89 e5 mov %rsp,%rbp
>>>>> 4004c4: 8b 05 72 1b 20
>>>>> 00 mov 0x201b72(%rip),%eax # 60203c <v>
>>>>> 4004ca: 83 c0 01 add $0x1,%eax
>>>>> 4004cd: 89 05 69 1b 20
>>>>> 00 mov %eax,0x201b69(%rip) # 60203c <v>
>>>>> 4004d3: 90 nop
>>>>> 4004d4: 5d pop %rbp
>>>>> 4004d5: c3 ret
>>>>> ...
>>>>>
>>>>> And because the line table info is rudamentary:
>>>>> ...
>>>>> CU: tmp-dw2-dir-file-name.c:
>>>>> File name Line number Starting
>>>>> address View Stmt
>>>>> tmp-dw2-dir-file-
>>>>> name.c 999 0x4004c0 x
>>>>> tmp-dw2-dir-file-
>>>>> name.c 1000 0x4004d6 x
>>>>> tmp-dw2-dir-file-name.c - 0x4004d6
>>>>> ...
>>>>> the address does not fall at an actual line, so the breakpoint
>>>>> is
>>>>> shown with
>>>>> address, both when setting it and hitting it.
>>>>>
>>>>> when running the test-case with aarch64-linux, we have
>>>>> similarly:
>>>>> ...
>>>>> (gdb) break compdir_missing__ldir_missing__file_basename^M
>>>>> Breakpoint 2 at 0x400618: file tmp-dw2-dir-file-name.c, line
>>>>> 999.^M
>>>>> ...
>>>>> due to the architecture-specific prologue skipper starting at
>>>>> 0x400610 and
>>>>> skipping past two insns, to 0x400618:
>>>>> ...
>>>>> 0000000000400610
>>>>> <compdir_missing__ldir_missing__file_basename>:
>>>>> 400610: 90000100 adrp x0, 420000 <
>>>>> __libc_start_main@GLIBC_2.17>
>>>>> 400614: 9100b000 add x0, x0, #0x2c
>>>>> 400618: b9400000 ldr w0, [x0]
>>>>> 40061c: 11000401 add w1, w0, #0x1
>>>>> 400620: 90000100 adrp x0, 420000 <
>>>>> __libc_start_main@GLIBC_2.17>
>>>>> 400624: 9100b000 add x0, x0, #0x2c
>>>>> 400628: b9000001 str w1, [x0]
>>>>> 40062c: d503201f nop
>>>>> 400630: d65f03c0 ret
>>>>> ...
>>>>>
>>>>> But interestingly, the aarch64 architecture-specific prologue
>>>>> skipper is
>>>>> wrong. There is no prologue, and the breakpoint should be set
>>>>> at
>>>>> 0x400610.
>>>>>
>>>>> By using "break *compdir_missing__ldir_missing__file_basename"
>>>>> we can get the breakpoint set at 0x400610:
>>>>> ...
>>>>> (gdb) break *compdir_missing__ldir_missing__file_basename^M
>>>>> Breakpoint 2 at 0x400610: file tmp-dw2-dir-file-name.c, line
>>>>> 999.^M
>>>>> ...
>>>>> and make the test-case independent of prologue analysis.
>>>>>
>>>>> This requires us to update the expected patterns.
>>>>>
>>>>> The fix ensures that once the aarch64 architecture-specific
>>>>> prologue skipper
>>>>> will be fixed, this test-case won't start failing.
>>>>>
>>>>> Tested on x86_64-linux.
>>>>>
>>>>> Any comments?
>>>>>
>>>>> Thanks,
>>>>> - Tom
>>>>>
>>>>> [gdb/testsuite] Fix gdb.dwarf2/dw2-dir-file-name.exp
>>>>>
>>>>> ---
>>>>> gdb/testsuite/gdb.dwarf2/dw2-dir-file-name.exp | 8 ++++----
>>>>> gdb/testsuite/lib/gdb.exp | 7 ++++++-
>>>>> 2 files changed, 10 insertions(+), 5 deletions(-)
>>>>>
>>>>> diff --git a/gdb/testsuite/gdb.dwarf2/dw2-dir-file-name.exp
>>>>> b/gdb/testsuite/gdb.dwarf2/dw2-dir-file-name.exp
>>>>> index 4d3f767f597..4c4c1ff07af 100644
>>>>> --- a/gdb/testsuite/gdb.dwarf2/dw2-dir-file-name.exp
>>>>> +++ b/gdb/testsuite/gdb.dwarf2/dw2-dir-file-name.exp
>>>>> @@ -396,20 +396,20 @@ proc test { func compdir filename } {
>>>>> error "not absolute"
>>>>> }
>>>>>
>>>>> - gdb_breakpoint $func
>>>>> + gdb_breakpoint *$func
>>>>> gdb_continue_to_breakpoint $func "$func \\(\\) at .*"
>>>>>
>>>>> gdb_test_no_output "set filename-display absolute"
>>>>> verbose -log "expect: ${absolute}"
>>>>> - gdb_test "frame" " in $func \\(\\) at [string_to_regexp
>>>>> ${absolute}]:999" "absolute"
>>>>> + gdb_test "frame" "#0 $func \\(\\) at [string_to_regexp
>>>>> ${absolute}]:999" "absolute"
>>>>>
>>>>> gdb_test_no_output "set filename-display basename"
>>>>> verbose -log "expect: [file tail $filename]"
>>>>> - gdb_test "frame" " in $func \\(\\) at [string_to_regexp
>>>>> [file
>>>>> tail $filename]]:999" "basename"
>>>>> + gdb_test "frame" "#0 $func \\(\\) at [string_to_regexp
>>>>> [file
>>>>> tail $filename]]:999" "basename"
>>>>>
>>>>> gdb_test_no_output "set filename-display relative"
>>>>> verbose -log "expect: $filename"
>>>>> - gdb_test "frame" " in $func \\(\\) at [string_to_regexp
>>>>> $filename]:999" "relative"
>>>>> + gdb_test "frame" "#0 $func \\(\\) at [string_to_regexp
>>>>> $filename]:999" "relative"
>>>>> }
>>>>> }
>>>>>
>>>>> diff --git a/gdb/testsuite/lib/gdb.exp
>>>>> b/gdb/testsuite/lib/gdb.exp
>>>>> index a8f25b5f0dd..70fc019eeb9 100644
>>>>> --- a/gdb/testsuite/lib/gdb.exp
>>>>> +++ b/gdb/testsuite/lib/gdb.exp
>>>>> @@ -787,9 +787,14 @@ proc gdb_continue_to_breakpoint {name
>>>>> {location_pattern .*}} {
>>>>> global gdb_prompt
>>>>> set full_name "continue to breakpoint: $name"
>>>>>
>>>>> + set re_at_in " (at|in) " <-NEED
>>>>> TO FIX TO ALWAYS GIVE local entry point for POWERPC
>>>>> ??
>>>>>
>>>>> + if { [regexp $re_at_in $location_pattern] } {
>>>>> + set re_at_in " "
>>>>> + }
>>>>> +
>>>>> set kfail_pattern "Process record does not support
>>>>> instruction 0xfae64 at.*"
>>>>> gdb_test_multiple "continue" $full_name {
>>>>> - -re "(?:Breakpoint|Temporary breakpoint) .* (at|in)
>>>>> $location_pattern\r\n$gdb_prompt $" {
>>>>> + -re "(?:Breakpoint|Temporary breakpoint)
>>>>> .*$re_at_in$location_pattern\r\n$gdb_prompt $" {
>>>>> pass $full_name
>>>>> }
>>>>> -re "\[\r\n\]*(?:$kfail_pattern)\[\r\n\]+$gdb_prompt $"
>>>>> {
>
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH][gdb/testsuite] Fix gdb.dwarf2/dw2-dir-file-name.exp
2022-08-16 7:43 ` Luis Machado
@ 2022-08-16 16:00 ` will schmidt
0 siblings, 0 replies; 12+ messages in thread
From: will schmidt @ 2022-08-16 16:00 UTC (permalink / raw)
To: Luis Machado, Carl Love, Tom de Vries, gdb-patches, Ulrich Weigand
On Tue, 2022-08-16 at 08:43 +0100, Luis Machado wrote:
> On 8/15/22 20:12, will schmidt wrote:
> > On Mon, 2022-08-15 at 09:54 -0700, Carl Love wrote:
> > > Tom:
> > >
> > > OK, I took a look at how the test used to work and how it is now
> > > working and I see what the issue is.
> > >
> > > PowerPC has two entry points, local and global. The test used to set
> > > the breakpoint for the function at the local entry point. With your
> > > changes, the breakpoint is now being set at the global breakpoint
> > > which
> > > is before the local breakpoint. The function is actually entered at
> > > the local breakpoint thus gdb never "sees" the breakpoint that was
> > > set.
> > > Specfically, here is the objdump for the test:
> > >
> > > 00000000100006e0 <compdir_missing__ldir_missing__file_basename>:
> > > 100006e0: 02 10 40
> > > 3c lis r2,4098 <- Global entry point
> > > 100006e4: 00 7f 42 38 addi r2,r2,32512
> > > 100006e8: f8 ff e1 fb std r31,-8(r1)
> > > 100006ec: d1 ff 21 f8 stdu r1,-48(r1)
> > > 100006f0: 78 0b 3f 7c mr r31,r1
> > > 100006f4: 00 00 00
> > > 60 nop <- Local entry point
> > > 100006f8: 28 81 22 39 addi r9,r2,-32472
> > > 100006fc: 00 00 29 81 lwz r9,0(r9)
> > > 10000700: 01 00 49 39 addi r10,r9,1
> > > 10000704: 00 00 00 60 nop
> > > 10000708: 28 81 22 39 addi r9,r2,-32472
> > > 1000070c: 00 00 49 91 stw r10,0(r9)
> > > 10000710: 30 00 3f 38 addi r1,r31,48
> > > 10000714: f8 ff e1 eb ld r31,-8(r1)
> > > 10000718: 20 00 80 4e blr
> > >
> > > When I look at the output before the patch, we see:
> > >
> > > Breakpoint 2, 0x00000000100006f4 in
> > > compdir_missing__ldir_missing__file_basename () at tmp-dw2-dir-file-
> > > name.c:999
> > >
> > > (gdb) PASS: gdb.dwarf2/dw2-dir-file-name.exp:
> > > compdir_missing__ldir_missing__file_basename: continue to breakpoint:
> > > compdir_missing__ldir_missing__file_basename
> > > set filename-display absolute
> > >
> > >
> > > Note the breakpoint 2 address is 0x00000000100006f4 which is on the
> > > NOP. Instructions at addresses 0x100006e0 to 100006f0 are part of
> > > the
> > > code when the function is called via the global entry point. So
> > > previously, the breakpoint was set at local entry point.
> > >
> > > With the patch, we now see:
> > >
> > > Breakpoint 2 at 0x100006e0: file tmp-dw2-dir-file-name.c, line
> > > 999.
> > > (gdb) continue
> > >
> > > Continuing.
> > > [Inferior 1 (process 2520351) exited normally]
> > > (gdb) FAIL: gdb.dwarf2/dw2-dir-file-name.exp:
> > > compdir_missing__ldir_missing__file_basename: continue to breakpoint:
> > > compdir_missing__ldir_missing__file_basename (the program exited)
> > >
> > > Now we note that the breakpoint 2 is set at 0x100006e0 which is the
> > > global entry point.
> > >
> > > It looks to me that we need to make sure we set the breakpoint at the
> > > local address.
> > >
> > > Off hand, I am not sure how to get your changes to "proc
> > > gdb_continue_to_breakpoint" to select the local entry point not the
> > > global entry point. Perhaps Ulrich has some ideas???
> >
> > From a glance that the patch that updated dw2-dir-file-name.exp;
> > ( commit cd919f5533cc8aa495acd75a6f059e5fcf2e6af9 )
> > the change there was effectively
> >
> > - gdb_breakpoint $func
> > + gdb_breakpoint *$func
> >
> > with assorted regexp changes to match.
> >
> > The patch description goes into detail, but I interpret the gist of it
> > as avoiding the aarch64 architecture prologue skipper, since that
> > prologue skipper does something wrong, with entanglements in the line
> > table info.
>
> Though the aarch64 prologue skipper is indeed mistaken here, Tom's patch only
> makes the test less reliant on whatever prologue skippers do and instead just
> got for a breakpoint straight at the entry point.
I don't have the code up in front of me, I'll punt to Carl to point out
where things are, if necessary.. :-)
For PowerPC, as described in the
ELFv2 ABI, that entry point is the global entry point (GEP). We also
have (and use as much as possible) a local entry point (LEP). Code to
update the TOC pointer (R2) exists between the two entry points, so
when a local function calls this function, the TOC set-up is skipped.
This was a significant part of the new ABI.
And though I was hung up on
the GEP/LEP gunk, I recognize the prologue skipping code also skips therest of the, um, prologue.
It is perfectly fine to set a breakpoint between the two entry points,
or anywhere within the prologue, we just can't expect it to hit
anything between the entry points unless we are called via the global
entry point.
So for instance ...
Dump of assembler code for function parse_size:
0x000000000000091c <+0>: addis r2,r12,2 << GEP,*parse_size
0x0000000000000920 <+4>: addi r2,r2,30180
0x0000000000000924 <+8>: mflr r0 << LEP
0x0000000000000928 <+12>: std r0,16(r1)
0x000000000000092c <+16>: std r31,-8(r1)
0x0000000000000930 <+20>: stdu r1,-144(r1)
0x0000000000000934 <+24>: mr r31,r1
0x0000000000000938 <+28>: std r3,104(r31) << End of Prologue.
0x000000000000093c <+32>: li r9,1 << start
(gdb) break parse_size
Breakpoint 1 at 0x93c: file get_page_size.c, line
11.
(gdb) break *parse_size
Breakpoint 2 at 0x91c: file get_page_size.c,
line 9.
(gdb) break * 0x000000000000091c
Note: breakpoint 2 also set at
pc 0x91c.
Breakpoint 3 at 0x91c: file get_page_size.c, line 9.
Thanks,
-Will
>
> It is a void function with void return type, so no much going on. Maybe it needs
> to be adapted somewhat to the PowerPC case?
>
>
> > The powerpc prologue skipper (wherever it is) was presumably handling
> > the local/global entry points properly. Since the test now species a
> > specific address (*$func), the prologue skipper is no longer involved.
>
> How does powerpc handle a breakpoint at a particular address?
>
> > The patch should probably be reverted, but I defer to others if I've
> > misunderstood part of this issue..
> >
> > Thanks
> > -Will
> >
> >
> >
> >
> >
> >
> >
> >
> > > Carl Love
> > >
> > >
> > > On Mon, 2022-08-15 at 09:01 -0700, Carl Love wrote:
> > >
> > > > Looks like the patch was applied last Friday. We are now seeing
> > > > 129
> > > > test failures related to this commit on PowerPC. The failures are
> > > > seen
> > > > on Power 8, 9 and 10.
> > > >
> > > > Here is an initial bit of the failures:
> > > >
> > > > ...
> > > > Breakpoint 2 at 0x100006e0: file tmp-dw2-dir-file-name.c, line 999.
> > > > (gdb) continue
> > > > Continuing.
> > > > [Inferior 1 (process 2520351) exited normally]
> > > > (gdb) FAIL: gdb.dwarf2/dw2-dir-file-name.exp:
> > > > compdir_missing__ldir_missing__file_basename: continue to
> > > > breakpoint:
> > > > compdir_missing__ldir_missing__file_basename (the program exited)
> > > > set filename-display absolute
> > > > (gdb) PASS: gdb.dwarf2/dw2-dir-file-name.exp:
> > > > compdir_missing__ldir_missing__file_basename: set filename-display
> > > > absolute
> > > > expect: /home/carll/GDB/build-
> > > > current/gdb/testsuite/outputs/gdb.dwarf2/dw2-dir-file-name/dw2-dir-
> > > > file-name.d/rdir/tmp-dw2-dir-file-name.c
> > > > frame
> > > > No stack.
> > > > (gdb) FAIL: gdb.dwarf2/dw2-dir-file-name.exp:
> > > > compdir_missing__ldir_missing__file_basename: absolute
> > > > set filename-display basename
> > > > (gdb) PASS: gdb.dwarf2/dw2-dir-file-name.exp:
> > > > compdir_missing__ldir_missing__file_basename: set filename-display
> > > > basename
> > > > expect: tmp-dw2-dir-file-name.c
> > > > frame
> > > > No stack.
> > > > (gdb) FAIL: gdb.dwarf2/dw2-dir-file-name.exp:
> > > > compdir_missing__ldir_missing__file_basename: basename
> > > > set filename-display relative
> > > > (gdb) PASS: gdb.dwarf2/dw2-dir-file-name.exp:
> > > > compdir_missing__ldir_missing__file_basename: set filename-display
> > > > relative
> > > > expect: tmp-dw2-dir-file-name.c
> > > > frame
> > > > No stack.
> > > > (gdb) FAIL: gdb.dwarf2/dw2-dir-file-name.exp:
> > > > compdir_missing__ldir_missing__file_basename: relative
> > > > set directories
> > > > (gdb) PASS: gdb.dwarf2/dw2-dir-file-name.exp:
> > > > compdir_missing__ldir_missing__file_relative: set directories
> > > > break *compdir_missing__ldir_missing__file_relative
> > > > Breakpoint 3 at 0x10000728: file fdir/tmp-dw2-dir-file-name.c, line
> > > > 999.
> > > > (gdb) continue
> > > > The program is not being run.
> > > >
> > > > etc.
> > > >
> > > > === gdb Summary ===
> > > >
> > > > # of expected passes 129
> > > > # of unexpected failures 128
> > > >
> > > > I have not had time yet to try and dig into the failures to figure
> > > > out
> > > > the cause. I will take a look at the failures to see what is going
> > > > on.
> > > >
> > > > Anyway, just wanted to let you know what I am seeing on PowerPC.
> > > >
> > > > Carl
> > > >
> > > > On Fri, 2022-08-12 at 10:33 +0100, Luis Machado via Gdb-patches
> > > > wrote:
> > > > > On 8/11/22 12:58, Tom de Vries wrote:
> > > > > > Hi,
> > > > > >
> > > > > > When running test-case gdb.dwarf2/dw2-dir-file-name.exp on
> > > > > > x86_64-
> > > > > > linux, we
> > > > > > have:
> > > > > > ...
> > > > > > (gdb) break compdir_missing__ldir_missing__file_basename^M
> > > > > > Breakpoint 2 at 0x4004c4: file tmp-dw2-dir-file-name.c, line
> > > > > > 999.^M
> > > > > > (gdb) continue^M
> > > > > > Continuing.^M
> > > > > > ^M
> > > > > > Breakpoint 2, 0x00000000004004c4 in \
> > > > > > compdir_missing__ldir_missing__file_basename () \
> > > > > > at tmp-dw2-dir-file-name.c:999^M
> > > > > > (gdb) PASS: gdb.dwarf2/dw2-dir-file-name.exp: \
> > > > > > compdir_missing__ldir_missing__file_basename: continue to
> > > > > > breakpoint: \
> > > > > > compdir_missing__ldir_missing__file_basename
> > > > > > ...
> > > > > >
> > > > > > When trying to set a breakpoint on
> > > > > > compdir_missing__ldir_missing__file_basename, the architecture-
> > > > > > specific
> > > > > > prologue skipper starts at 0x4004c0 and skips past two insns,
> > > > > > to
> > > > > > 0x4004c4:
> > > > > > ...
> > > > > > 00000000004004c0
> > > > > > <compdir_missing__ldir_missing__file_basename>:
> > > > > > 4004c0: 55 push %rbp
> > > > > > 4004c1: 48 89 e5 mov %rsp,%rbp
> > > > > > 4004c4: 8b 05 72 1b 20
> > > > > > 00 mov 0x201b72(%rip),%eax # 60203c <v>
> > > > > > 4004ca: 83 c0 01 add $0x1,%eax
> > > > > > 4004cd: 89 05 69 1b 20
> > > > > > 00 mov %eax,0x201b69(%rip) # 60203c <v>
> > > > > > 4004d3: 90 nop
> > > > > > 4004d4: 5d pop %rbp
> > > > > > 4004d5: c3 ret
> > > > > > ...
> > > > > >
> > > > > > And because the line table info is rudamentary:
> > > > > > ...
> > > > > > CU: tmp-dw2-dir-file-name.c:
> > > > > > File name Line number Starting
> > > > > > address View Stmt
> > > > > > tmp-dw2-dir-file-
> > > > > > name.c 999 0x4004c0 x
> > > > > > tmp-dw2-dir-file-
> > > > > > name.c 1000 0x4004d6 x
> > > > > > tmp-dw2-dir-file-name.c - 0x4004d6
> > > > > > ...
> > > > > > the address does not fall at an actual line, so the breakpoint
> > > > > > is
> > > > > > shown with
> > > > > > address, both when setting it and hitting it.
> > > > > >
> > > > > > when running the test-case with aarch64-linux, we have
> > > > > > similarly:
> > > > > > ...
> > > > > > (gdb) break compdir_missing__ldir_missing__file_basename^M
> > > > > > Breakpoint 2 at 0x400618: file tmp-dw2-dir-file-name.c, line
> > > > > > 999.^M
> > > > > > ...
> > > > > > due to the architecture-specific prologue skipper starting at
> > > > > > 0x400610 and
> > > > > > skipping past two insns, to 0x400618:
> > > > > > ...
> > > > > > 0000000000400610
> > > > > > <compdir_missing__ldir_missing__file_basename>:
> > > > > > 400610: 90000100 adrp x0, 420000 <
> > > > > > __libc_start_main@GLIBC_2.17>
> > > > > > 400614: 9100b000 add x0, x0, #0x2c
> > > > > > 400618: b9400000 ldr w0, [x0]
> > > > > > 40061c: 11000401 add w1, w0, #0x1
> > > > > > 400620: 90000100 adrp x0, 420000 <
> > > > > > __libc_start_main@GLIBC_2.17>
> > > > > > 400624: 9100b000 add x0, x0, #0x2c
> > > > > > 400628: b9000001 str w1, [x0]
> > > > > > 40062c: d503201f nop
> > > > > > 400630: d65f03c0 ret
> > > > > > ...
> > > > > >
> > > > > > But interestingly, the aarch64 architecture-specific prologue
> > > > > > skipper is
> > > > > > wrong. There is no prologue, and the breakpoint should be set
> > > > > > at
> > > > > > 0x400610.
> > > > > >
> > > > > > By using "break *compdir_missing__ldir_missing__file_basename"
> > > > > > we can get the breakpoint set at 0x400610:
> > > > > > ...
> > > > > > (gdb) break *compdir_missing__ldir_missing__file_basename^M
> > > > > > Breakpoint 2 at 0x400610: file tmp-dw2-dir-file-name.c, line
> > > > > > 999.^M
> > > > > > ...
> > > > > > and make the test-case independent of prologue analysis.
> > > > > >
> > > > > > This requires us to update the expected patterns.
> > > > > >
> > > > > > The fix ensures that once the aarch64 architecture-specific
> > > > > > prologue skipper
> > > > > > will be fixed, this test-case won't start failing.
> > > > > >
> > > > > > Tested on x86_64-linux.
> > > > > >
> > > > > > Any comments?
> > > > > >
> > > > > > Thanks,
> > > > > > - Tom
> > > > > >
> > > > > > [gdb/testsuite] Fix gdb.dwarf2/dw2-dir-file-name.exp
> > > > > >
> > > > > > ---
> > > > > > gdb/testsuite/gdb.dwarf2/dw2-dir-file-name.exp | 8 ++++----
> > > > > > gdb/testsuite/lib/gdb.exp | 7 ++++++-
> > > > > > 2 files changed, 10 insertions(+), 5 deletions(-)
> > > > > >
> > > > > > diff --git a/gdb/testsuite/gdb.dwarf2/dw2-dir-file-name.exp
> > > > > > b/gdb/testsuite/gdb.dwarf2/dw2-dir-file-name.exp
> > > > > > index 4d3f767f597..4c4c1ff07af 100644
> > > > > > --- a/gdb/testsuite/gdb.dwarf2/dw2-dir-file-name.exp
> > > > > > +++ b/gdb/testsuite/gdb.dwarf2/dw2-dir-file-name.exp
> > > > > > @@ -396,20 +396,20 @@ proc test { func compdir filename } {
> > > > > > error "not absolute"
> > > > > > }
> > > > > >
> > > > > > - gdb_breakpoint $func
> > > > > > + gdb_breakpoint *$func
> > > > > > gdb_continue_to_breakpoint $func "$func \\(\\) at .*"
> > > > > >
> > > > > > gdb_test_no_output "set filename-display absolute"
> > > > > > verbose -log "expect: ${absolute}"
> > > > > > - gdb_test "frame" " in $func \\(\\) at [string_to_regexp
> > > > > > ${absolute}]:999" "absolute"
> > > > > > + gdb_test "frame" "#0 $func \\(\\) at [string_to_regexp
> > > > > > ${absolute}]:999" "absolute"
> > > > > >
> > > > > > gdb_test_no_output "set filename-display basename"
> > > > > > verbose -log "expect: [file tail $filename]"
> > > > > > - gdb_test "frame" " in $func \\(\\) at [string_to_regexp
> > > > > > [file
> > > > > > tail $filename]]:999" "basename"
> > > > > > + gdb_test "frame" "#0 $func \\(\\) at [string_to_regexp
> > > > > > [file
> > > > > > tail $filename]]:999" "basename"
> > > > > >
> > > > > > gdb_test_no_output "set filename-display relative"
> > > > > > verbose -log "expect: $filename"
> > > > > > - gdb_test "frame" " in $func \\(\\) at [string_to_regexp
> > > > > > $filename]:999" "relative"
> > > > > > + gdb_test "frame" "#0 $func \\(\\) at [string_to_regexp
> > > > > > $filename]:999" "relative"
> > > > > > }
> > > > > > }
> > > > > >
> > > > > > diff --git a/gdb/testsuite/lib/gdb.exp
> > > > > > b/gdb/testsuite/lib/gdb.exp
> > > > > > index a8f25b5f0dd..70fc019eeb9 100644
> > > > > > --- a/gdb/testsuite/lib/gdb.exp
> > > > > > +++ b/gdb/testsuite/lib/gdb.exp
> > > > > > @@ -787,9 +787,14 @@ proc gdb_continue_to_breakpoint {name
> > > > > > {location_pattern .*}} {
> > > > > > global gdb_prompt
> > > > > > set full_name "continue to breakpoint: $name"
> > > > > >
> > > > > > + set re_at_in " (at|in) " <-NEED
> > > > > > TO FIX TO ALWAYS GIVE local entry point for POWERPC
> > > > > > ??
> > > > > >
> > > > > > + if { [regexp $re_at_in $location_pattern] } {
> > > > > > + set re_at_in " "
> > > > > > + }
> > > > > > +
> > > > > > set kfail_pattern "Process record does not support
> > > > > > instruction 0xfae64 at.*"
> > > > > > gdb_test_multiple "continue" $full_name {
> > > > > > - -re "(?:Breakpoint|Temporary breakpoint) .* (at|in)
> > > > > > $location_pattern\r\n$gdb_prompt $" {
> > > > > > + -re "(?:Breakpoint|Temporary breakpoint)
> > > > > > .*$re_at_in$location_pattern\r\n$gdb_prompt $" {
> > > > > > pass $full_name
> > > > > > }
> > > > > > -re "\[\r\n\]*(?:$kfail_pattern)\[\r\n\]+$gdb_prompt $"
> > > > > > {
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH][gdb/testsuite] Fix gdb.dwarf2/dw2-dir-file-name.exp
2022-08-15 16:54 ` Carl Love
2022-08-15 19:12 ` will schmidt
@ 2022-08-17 12:01 ` Ulrich Weigand
2022-09-01 14:40 ` Tom de Vries
2022-09-01 14:16 ` Tom de Vries
2 siblings, 1 reply; 12+ messages in thread
From: Ulrich Weigand @ 2022-08-17 12:01 UTC (permalink / raw)
To: gdb-patches, luis.machado, tdevries, cel
Carl Love <cel@us.ibm.com> wrote:
>PowerPC has two entry points, local and global. The test used to set
>the breakpoint for the function at the local entry point. With your
>changes, the breakpoint is now being set at the global breakpoint
which
>is before the local breakpoint. The function is actually entered at
>the local breakpoint thus gdb never "sees" the breakpoint that was
set.
>Specfically, here is the objdump for the test:
>00000000100006e0 <compdir_missing__ldir_missing__file_basename>:
> 100006e0: 02 10 40 3c lis r2,4098 <-
>Global entry point
> 100006e4: 00 7f 42 38 addi r2,r2,32512
The local enty point is actually here:
> 100006e8: f8 ff e1 fb std r31,-8(r1)
> 100006ec: d1 ff 21 f8 stdu r1,-48(r1)
> 100006f0: 78 0b 3f 7c mr r31,r1
> 100006f4: 00 00 00 60 nop <-
>Local entry point
> 100006f8: 28 81 22 39 addi r9,r2,-32472
Not here. This point might be the end of the prologue, which is a
separate question from the local vs. global entry point issue.
>Perhaps Ulrich has some ideas???
This:
+ gdb_breakpoint *$func
is nearly always wrong, and test cases shouldn't be using it.
I know that in the past, this construct was sometimes used with an
intended meaning of "set a breakpoint at the start of a function
without skipping the prologue", but it does *not* actually mean that.
The "*" operator tells the breakpoint logic to set a breakpoint on an
absolute address. If followed by a symbol, that symbol's value is used
as that absolute address. Now, on many platform, that symbol value
matches the address of the first instruction of a function, so the
"break *func" does more or less what's intended above.
But there are other platforms where this is not true, and the
relationship between the function symbol value and the address of the
first executed instruction is more complex. This specifically applies
to targets that implement gdbarch_deprecated_function_start_offset
and/or gdbarch_skip_entrypoint. (ppc64le uses the latter.)
Note that these are *independent* of prologue skipping, and on
platforms where it matters, they have to be used even when avoiding
prologue skipping, in order to correctly find the first instruction of
a function to set a breakpoint on. "break *func" ignores this,
leading to failures on such platforms.
As I said initially, I think this construct should never be used in
test cases (at least not in scenerios where it is intended to set a
breakpoint that will actually be hit).
For this specific test, if the underlying problem is a bug in some
architecture's prologue parser, then ideally this bug simply should be
fixed. If we need to actually avoid prologue skipping for some real
underlying reason, we should use a way that still handles function
start offsets and entrypoint skipping. For example, in a function with
debug info including valid location lists, GDB will always avoid
prologue skipping. We could also think of adding an explicit linespec
modifier that would allow to explicitly set a breakpoint on the first
instruction of a function without skipping prologue ...
Bye,
Ulrich
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH][gdb/testsuite] Fix gdb.dwarf2/dw2-dir-file-name.exp
2022-08-15 16:54 ` Carl Love
2022-08-15 19:12 ` will schmidt
2022-08-17 12:01 ` Ulrich Weigand
@ 2022-09-01 14:16 ` Tom de Vries
2 siblings, 0 replies; 12+ messages in thread
From: Tom de Vries @ 2022-09-01 14:16 UTC (permalink / raw)
To: Carl Love, Luis Machado, gdb-patches, Ulrich Weigand
On 8/15/22 18:54, Carl Love via Gdb-patches wrote:
> Tom:
>
> OK, I took a look at how the test used to work and how it is now
> working and I see what the issue is.
>
> PowerPC has two entry points, local and global. The test used to set
> the breakpoint for the function at the local entry point. With your
> changes, the breakpoint is now being set at the global breakpoint which
> is before the local breakpoint. The function is actually entered at
> the local breakpoint thus gdb never "sees" the breakpoint that was set.
> Specfically, here is the objdump for the test:
>
> 00000000100006e0 <compdir_missing__ldir_missing__file_basename>:
> 100006e0: 02 10 40 3c lis r2,4098 <- Global entry point
> 100006e4: 00 7f 42 38 addi r2,r2,32512
> 100006e8: f8 ff e1 fb std r31,-8(r1)
> 100006ec: d1 ff 21 f8 stdu r1,-48(r1)
> 100006f0: 78 0b 3f 7c mr r31,r1
> 100006f4: 00 00 00 60 nop <- Local entry point
> 100006f8: 28 81 22 39 addi r9,r2,-32472
> 100006fc: 00 00 29 81 lwz r9,0(r9)
> 10000700: 01 00 49 39 addi r10,r9,1
> 10000704: 00 00 00 60 nop
> 10000708: 28 81 22 39 addi r9,r2,-32472
> 1000070c: 00 00 49 91 stw r10,0(r9)
> 10000710: 30 00 3f 38 addi r1,r31,48
> 10000714: f8 ff e1 eb ld r31,-8(r1)
> 10000718: 20 00 80 4e blr
>
> When I look at the output before the patch, we see:
>
> Breakpoint 2, 0x00000000100006f4 in compdir_missing__ldir_missing__file_basename () at tmp-dw2-dir-file-name.c:999
>
> (gdb) PASS: gdb.dwarf2/dw2-dir-file-name.exp: compdir_missing__ldir_missing__file_basename: continue to breakpoint: compdir_missing__ldir_missing__file_basename
> set filename-display absolute
>
>
> Note the breakpoint 2 address is 0x00000000100006f4 which is on the
> NOP. Instructions at addresses 0x100006e0 to 100006f0 are part of the
> code when the function is called via the global entry point. So
> previously, the breakpoint was set at local entry point.
>
> With the patch, we now see:
>
> Breakpoint 2 at 0x100006e0: file tmp-dw2-dir-file-name.c, line 999.
> (gdb) continue
>
> Continuing.
> [Inferior 1 (process 2520351) exited normally]
> (gdb) FAIL: gdb.dwarf2/dw2-dir-file-name.exp: compdir_missing__ldir_missing__file_basename: continue to breakpoint: compdir_missing__ldir_missing__file_basename (the program exited)
>
> Now we note that the breakpoint 2 is set at 0x100006e0 which is the
> global entry point.
>
> It looks to me that we need to make sure we set the breakpoint at the
> local address.
>
> Off hand, I am not sure how to get your changes to "proc
> gdb_continue_to_breakpoint" to select the local entry point not the
> global entry point. Perhaps Ulrich has some ideas???
>
Hi Carl,
thanks for reporting this, and the analysis.
I've submitted a patch to fix this here (
https://sourceware.org/pipermail/gdb-patches/2022-September/191647.html ).
Thanks,
- Tom
> Carl Love
>
>
> On Mon, 2022-08-15 at 09:01 -0700, Carl Love wrote:
>
>>
>> Looks like the patch was applied last Friday. We are now seeing 129
>> test failures related to this commit on PowerPC. The failures are
>> seen
>> on Power 8, 9 and 10.
>>
>> Here is an initial bit of the failures:
>>
>> ...
>> Breakpoint 2 at 0x100006e0: file tmp-dw2-dir-file-name.c, line 999.
>> (gdb) continue
>> Continuing.
>> [Inferior 1 (process 2520351) exited normally]
>> (gdb) FAIL: gdb.dwarf2/dw2-dir-file-name.exp:
>> compdir_missing__ldir_missing__file_basename: continue to breakpoint:
>> compdir_missing__ldir_missing__file_basename (the program exited)
>> set filename-display absolute
>> (gdb) PASS: gdb.dwarf2/dw2-dir-file-name.exp:
>> compdir_missing__ldir_missing__file_basename: set filename-display
>> absolute
>> expect: /home/carll/GDB/build-
>> current/gdb/testsuite/outputs/gdb.dwarf2/dw2-dir-file-name/dw2-dir-
>> file-name.d/rdir/tmp-dw2-dir-file-name.c
>> frame
>> No stack.
>> (gdb) FAIL: gdb.dwarf2/dw2-dir-file-name.exp:
>> compdir_missing__ldir_missing__file_basename: absolute
>> set filename-display basename
>> (gdb) PASS: gdb.dwarf2/dw2-dir-file-name.exp:
>> compdir_missing__ldir_missing__file_basename: set filename-display
>> basename
>> expect: tmp-dw2-dir-file-name.c
>> frame
>> No stack.
>> (gdb) FAIL: gdb.dwarf2/dw2-dir-file-name.exp:
>> compdir_missing__ldir_missing__file_basename: basename
>> set filename-display relative
>> (gdb) PASS: gdb.dwarf2/dw2-dir-file-name.exp:
>> compdir_missing__ldir_missing__file_basename: set filename-display
>> relative
>> expect: tmp-dw2-dir-file-name.c
>> frame
>> No stack.
>> (gdb) FAIL: gdb.dwarf2/dw2-dir-file-name.exp:
>> compdir_missing__ldir_missing__file_basename: relative
>> set directories
>> (gdb) PASS: gdb.dwarf2/dw2-dir-file-name.exp:
>> compdir_missing__ldir_missing__file_relative: set directories
>> break *compdir_missing__ldir_missing__file_relative
>> Breakpoint 3 at 0x10000728: file fdir/tmp-dw2-dir-file-name.c, line
>> 999.
>> (gdb) continue
>> The program is not being run.
>>
>> etc.
>>
>> === gdb Summary ===
>>
>> # of expected passes 129
>> # of unexpected failures 128
>>
>> I have not had time yet to try and dig into the failures to figure
>> out
>> the cause. I will take a look at the failures to see what is going
>> on.
>>
>> Anyway, just wanted to let you know what I am seeing on PowerPC.
>>
>> Carl
>>
>> On Fri, 2022-08-12 at 10:33 +0100, Luis Machado via Gdb-patches
>> wrote:
>>> On 8/11/22 12:58, Tom de Vries wrote:
>>>> Hi,
>>>>
>>>> When running test-case gdb.dwarf2/dw2-dir-file-name.exp on
>>>> x86_64-
>>>> linux, we
>>>> have:
>>>> ...
>>>> (gdb) break compdir_missing__ldir_missing__file_basename^M
>>>> Breakpoint 2 at 0x4004c4: file tmp-dw2-dir-file-name.c, line
>>>> 999.^M
>>>> (gdb) continue^M
>>>> Continuing.^M
>>>> ^M
>>>> Breakpoint 2, 0x00000000004004c4 in \
>>>> compdir_missing__ldir_missing__file_basename () \
>>>> at tmp-dw2-dir-file-name.c:999^M
>>>> (gdb) PASS: gdb.dwarf2/dw2-dir-file-name.exp: \
>>>> compdir_missing__ldir_missing__file_basename: continue to
>>>> breakpoint: \
>>>> compdir_missing__ldir_missing__file_basename
>>>> ...
>>>>
>>>> When trying to set a breakpoint on
>>>> compdir_missing__ldir_missing__file_basename, the architecture-
>>>> specific
>>>> prologue skipper starts at 0x4004c0 and skips past two insns, to
>>>> 0x4004c4:
>>>> ...
>>>> 00000000004004c0 <compdir_missing__ldir_missing__file_basename>:
>>>> 4004c0: 55 push %rbp
>>>> 4004c1: 48 89 e5 mov %rsp,%rbp
>>>> 4004c4: 8b 05 72 1b 20
>>>> 00 mov 0x201b72(%rip),%eax # 60203c <v>
>>>> 4004ca: 83 c0 01 add $0x1,%eax
>>>> 4004cd: 89 05 69 1b 20
>>>> 00 mov %eax,0x201b69(%rip) # 60203c <v>
>>>> 4004d3: 90 nop
>>>> 4004d4: 5d pop %rbp
>>>> 4004d5: c3 ret
>>>> ...
>>>>
>>>> And because the line table info is rudamentary:
>>>> ...
>>>> CU: tmp-dw2-dir-file-name.c:
>>>> File name Line number Starting
>>>> address View Stmt
>>>> tmp-dw2-dir-file-
>>>> name.c 999 0x4004c0 x
>>>> tmp-dw2-dir-file-
>>>> name.c 1000 0x4004d6 x
>>>> tmp-dw2-dir-file-name.c - 0x4004d6
>>>> ...
>>>> the address does not fall at an actual line, so the breakpoint is
>>>> shown with
>>>> address, both when setting it and hitting it.
>>>>
>>>> when running the test-case with aarch64-linux, we have similarly:
>>>> ...
>>>> (gdb) break compdir_missing__ldir_missing__file_basename^M
>>>> Breakpoint 2 at 0x400618: file tmp-dw2-dir-file-name.c, line
>>>> 999.^M
>>>> ...
>>>> due to the architecture-specific prologue skipper starting at
>>>> 0x400610 and
>>>> skipping past two insns, to 0x400618:
>>>> ...
>>>> 0000000000400610 <compdir_missing__ldir_missing__file_basename>:
>>>> 400610: 90000100 adrp x0, 420000 <
>>>> __libc_start_main@GLIBC_2.17>
>>>> 400614: 9100b000 add x0, x0, #0x2c
>>>> 400618: b9400000 ldr w0, [x0]
>>>> 40061c: 11000401 add w1, w0, #0x1
>>>> 400620: 90000100 adrp x0, 420000 <
>>>> __libc_start_main@GLIBC_2.17>
>>>> 400624: 9100b000 add x0, x0, #0x2c
>>>> 400628: b9000001 str w1, [x0]
>>>> 40062c: d503201f nop
>>>> 400630: d65f03c0 ret
>>>> ...
>>>>
>>>> But interestingly, the aarch64 architecture-specific prologue
>>>> skipper is
>>>> wrong. There is no prologue, and the breakpoint should be set at
>>>> 0x400610.
>>>>
>>>> By using "break *compdir_missing__ldir_missing__file_basename"
>>>> we can get the breakpoint set at 0x400610:
>>>> ...
>>>> (gdb) break *compdir_missing__ldir_missing__file_basename^M
>>>> Breakpoint 2 at 0x400610: file tmp-dw2-dir-file-name.c, line
>>>> 999.^M
>>>> ...
>>>> and make the test-case independent of prologue analysis.
>>>>
>>>> This requires us to update the expected patterns.
>>>>
>>>> The fix ensures that once the aarch64 architecture-specific
>>>> prologue skipper
>>>> will be fixed, this test-case won't start failing.
>>>>
>>>> Tested on x86_64-linux.
>>>>
>>>> Any comments?
>>>>
>>>> Thanks,
>>>> - Tom
>>>>
>>>> [gdb/testsuite] Fix gdb.dwarf2/dw2-dir-file-name.exp
>>>>
>>>> ---
>>>> gdb/testsuite/gdb.dwarf2/dw2-dir-file-name.exp | 8 ++++----
>>>> gdb/testsuite/lib/gdb.exp | 7 ++++++-
>>>> 2 files changed, 10 insertions(+), 5 deletions(-)
>>>>
>>>> diff --git a/gdb/testsuite/gdb.dwarf2/dw2-dir-file-name.exp
>>>> b/gdb/testsuite/gdb.dwarf2/dw2-dir-file-name.exp
>>>> index 4d3f767f597..4c4c1ff07af 100644
>>>> --- a/gdb/testsuite/gdb.dwarf2/dw2-dir-file-name.exp
>>>> +++ b/gdb/testsuite/gdb.dwarf2/dw2-dir-file-name.exp
>>>> @@ -396,20 +396,20 @@ proc test { func compdir filename } {
>>>> error "not absolute"
>>>> }
>>>>
>>>> - gdb_breakpoint $func
>>>> + gdb_breakpoint *$func
>>>> gdb_continue_to_breakpoint $func "$func \\(\\) at .*"
>>>>
>>>> gdb_test_no_output "set filename-display absolute"
>>>> verbose -log "expect: ${absolute}"
>>>> - gdb_test "frame" " in $func \\(\\) at [string_to_regexp
>>>> ${absolute}]:999" "absolute"
>>>> + gdb_test "frame" "#0 $func \\(\\) at [string_to_regexp
>>>> ${absolute}]:999" "absolute"
>>>>
>>>> gdb_test_no_output "set filename-display basename"
>>>> verbose -log "expect: [file tail $filename]"
>>>> - gdb_test "frame" " in $func \\(\\) at [string_to_regexp [file
>>>> tail $filename]]:999" "basename"
>>>> + gdb_test "frame" "#0 $func \\(\\) at [string_to_regexp [file
>>>> tail $filename]]:999" "basename"
>>>>
>>>> gdb_test_no_output "set filename-display relative"
>>>> verbose -log "expect: $filename"
>>>> - gdb_test "frame" " in $func \\(\\) at [string_to_regexp
>>>> $filename]:999" "relative"
>>>> + gdb_test "frame" "#0 $func \\(\\) at [string_to_regexp
>>>> $filename]:999" "relative"
>>>> }
>>>> }
>>>>
>>>> diff --git a/gdb/testsuite/lib/gdb.exp
>>>> b/gdb/testsuite/lib/gdb.exp
>>>> index a8f25b5f0dd..70fc019eeb9 100644
>>>> --- a/gdb/testsuite/lib/gdb.exp
>>>> +++ b/gdb/testsuite/lib/gdb.exp
>>>> @@ -787,9 +787,14 @@ proc gdb_continue_to_breakpoint {name
>>>> {location_pattern .*}} {
>>>> global gdb_prompt
>>>> set full_name "continue to breakpoint: $name"
>>>>
>>>> + set re_at_in " (at|in) " <-NEED TO FIX TO ALWAYS GIVE local entry point for POWERPC ??
>>>> + if { [regexp $re_at_in $location_pattern] } {
>>>> + set re_at_in " "
>>>> + }
>>>> +
>>>> set kfail_pattern "Process record does not support
>>>> instruction 0xfae64 at.*"
>>>> gdb_test_multiple "continue" $full_name {
>>>> - -re "(?:Breakpoint|Temporary breakpoint) .* (at|in)
>>>> $location_pattern\r\n$gdb_prompt $" {
>>>> + -re "(?:Breakpoint|Temporary breakpoint)
>>>> .*$re_at_in$location_pattern\r\n$gdb_prompt $" {
>>>> pass $full_name
>>>> }
>>>> -re "\[\r\n\]*(?:$kfail_pattern)\[\r\n\]+$gdb_prompt $"
>>>> {
>
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH][gdb/testsuite] Fix gdb.dwarf2/dw2-dir-file-name.exp
2022-08-17 12:01 ` Ulrich Weigand
@ 2022-09-01 14:40 ` Tom de Vries
0 siblings, 0 replies; 12+ messages in thread
From: Tom de Vries @ 2022-09-01 14:40 UTC (permalink / raw)
To: Ulrich Weigand, gdb-patches, luis.machado, cel
On 8/17/22 14:01, Ulrich Weigand wrote:
> Carl Love <cel@us.ibm.com> wrote:
>
>> PowerPC has two entry points, local and global. The test used to set
>> the breakpoint for the function at the local entry point. With your
>> changes, the breakpoint is now being set at the global breakpoint
> which
>> is before the local breakpoint. The function is actually entered at
>> the local breakpoint thus gdb never "sees" the breakpoint that was
> set.
>> Specfically, here is the objdump for the test:
>
>> 00000000100006e0 <compdir_missing__ldir_missing__file_basename>:
>> 100006e0: 02 10 40 3c lis r2,4098 <-
>> Global entry point
>> 100006e4: 00 7f 42 38 addi r2,r2,32512
> The local enty point is actually here:
>> 100006e8: f8 ff e1 fb std r31,-8(r1)
>> 100006ec: d1 ff 21 f8 stdu r1,-48(r1)
>> 100006f0: 78 0b 3f 7c mr r31,r1
>> 100006f4: 00 00 00 60 nop <-
>> Local entry point
>> 100006f8: 28 81 22 39 addi r9,r2,-32472
>
> Not here. This point might be the end of the prologue, which is a
> separate question from the local vs. global entry point issue.
>
>> Perhaps Ulrich has some ideas???
>
> This:
> + gdb_breakpoint *$func
> is nearly always wrong, and test cases shouldn't be using it.
>
Ack, I've posted a fix that doesn't use that construct anymore.
> I know that in the past, this construct was sometimes used with an
> intended meaning of "set a breakpoint at the start of a function
> without skipping the prologue", but it does *not* actually mean that.
>
> The "*" operator tells the breakpoint logic to set a breakpoint on an
> absolute address. If followed by a symbol, that symbol's value is used
> as that absolute address. Now, on many platform, that symbol value
> matches the address of the first instruction of a function, so the
> "break *func" does more or less what's intended above.
>
> But there are other platforms where this is not true, and the
> relationship between the function symbol value and the address of the
> first executed instruction is more complex. This specifically applies
> to targets that implement gdbarch_deprecated_function_start_offset
> and/or gdbarch_skip_entrypoint. (ppc64le uses the latter.)
>
I think we could add a note to the docs explaining this.
> Note that these are *independent* of prologue skipping, and on
> platforms where it matters, they have to be used even when avoiding
> prologue skipping, in order to correctly find the first instruction of
> a function to set a breakpoint on. "break *func" ignores this,
> leading to failures on such platforms.
>
>
> As I said initially, I think this construct should never be used in
> test cases (at least not in scenerios where it is intended to set a
> breakpoint that will actually be hit).
>
> For this specific test, if the underlying problem is a bug in some
> architecture's prologue parser, then ideally this bug simply should be
> fixed.
Yes, it should, and a test-case should be added for that.
In this test-case, we try to test a feature that has nothing to do with
architecture-specific prologue skipping, so given that there can be
problems with it on various targets, the test-case should simply skip it.
Thanks,
- Tom
> If we need to actually avoid prologue skipping for some real
> underlying reason, we should use a way that still handles function
> start offsets and entrypoint skipping. For example, in a function with
> debug info including valid location lists, GDB will always avoid
> prologue skipping. We could also think of adding an explicit linespec
> modifier that would allow to explicitly set a breakpoint on the first
> instruction of a function without skipping prologue ...
>
>
> Bye,
> Ulrich
>
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2022-09-01 14:40 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-08-11 11:58 [PATCH][gdb/testsuite] Fix gdb.dwarf2/dw2-dir-file-name.exp Tom de Vries
2022-08-12 9:33 ` Luis Machado
2022-08-15 16:01 ` Carl Love
2022-08-15 16:54 ` Carl Love
2022-08-15 19:12 ` will schmidt
2022-08-15 19:31 ` Thiago Jung Bauermann
2022-08-15 21:33 ` will schmidt
2022-08-16 7:43 ` Luis Machado
2022-08-16 16:00 ` will schmidt
2022-08-17 12:01 ` Ulrich Weigand
2022-09-01 14:40 ` Tom de Vries
2022-09-01 14:16 ` Tom de Vries
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).