summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2018-01-17Relax gdb.compile/compile.exp to match the address printed for frameYao Qi
One test in gdb.compile/compile.exp passes on one fedora builder, bt #0 0x00007ffff7ff43f6 in _gdb_expr (__regs=0x7ffff7ff2000) at gdb command line:1^M #1 <function called from gdb>^M #2 main () at /home/gdb-buildbot/fedora-x86-64-1/fedora-x86-64/build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.compile/compile.c:106^M (gdb) PASS: gdb.compile/compile.exp: bt but fails on my machine with gcc trunk, bt^M #0 _gdb_expr (__regs=0x7ffff7ff3000) at gdb command line:1^M #1 <function called from gdb>^M #2 main () at gdb/testsuite/gdb.compile/compile.c:106^M (gdb) FAIL: gdb.compile/compile.exp: bt The test should be tweaked to match both cases (pc in the start of line vs pc in the middle of line). Note that I am not clear that why libcc1 emits debug info this way so that the address is in the middle of line. gdb/testsuite: 2018-01-17 Yao Qi <yao.qi@linaro.org> * gdb.compile/compile.exp: Match the address printed for frame in the output of command "bt".
2018-01-17Automatic date update in version.inGDB Administrator
2018-01-16Automatic date update in version.inGDB Administrator
2018-01-15Fix scm-ports.exp regressionTom Tromey
In https://sourceware.org/ml/gdb-patches/2017-12/msg00215.html, Jan pointed out that the scalar printing patches caused a regression in scm-ports.exp on x86. What happens is that on x86, this: set sp_reg [get_integer_valueof "\$sp" 0] ... ends up setting sp_reg to a negative value, because get_integer_valueof uses "print/d": print /d $sp $1 = -11496 Then later the test suite does: gdb_test "guile (print (seek rw-mem-port (value->integer sp-reg) SEEK_SET))" \ "= $sp_reg" \ "seek to \$sp" ... expecting this value to be identical to the saved $sp_reg value. However it gets: guile (print (seek rw-mem-port (value->integer sp-reg) SEEK_SET)) = 4294955800 "print" is just a wrapper for guile's format: gdb_test_no_output "guile (define (print x) (format #t \"= ~A\" x) (newline))" The seek function returns a scm_t_off, the printing of which is handled by guile, not by gdb. Tested on x86-64 Fedora 26 using an ordinary build and also a -m32 build. 2018-01-15 Tom Tromey <tom@tromey.com> * gdb.guile/scm-ports.exp (test_mem_port_rw): Use get_valueof to compute sp_reg.
2018-01-15Automatic date update in version.inGDB Administrator
2018-01-14Automatic date update in version.inGDB Administrator
2018-01-13Automatic date update in version.inGDB Administrator
2018-01-12Add testcase for GDB hang fixed by previous commitPedro Alves
This adds a testcase for the previous commit. The regression was related to in-line step overs. The reason we didn't see it on native x86-64/s390 GNU/Linux testing is that native debugging uses displaced stepping by default (because native debugging defaults to "maint set target-non-stop on"), unlike remote debugging. So in order to trigger the bug with native debugging as well, the testcase disables displaced stepping explicitly. Also, instead of using watchpoints to trigger the regression, the testcase uses a breakpoint at address 0, which should be more portable. gdb/testsuite/ChangeLog: 2018-01-12 Pedro Alves <palves@redhat.com> * gdb.base/continue-after-aborted-step-over.c: New. * gdb.base/continue-after-aborted-step-over.exp: New.
2018-01-12Fix GDB hang with remote after error from resumeAndreas Arnez
Since this commit -- Fix PR18360 - internal error when using "interrupt -a" (https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=c65d6b55) -- the testsuite shows long delays on s390 with native-gdbserver when executing certain tests, such as watchpoints.exp. These hangs have been discussed before in the context of buildbot problems, see here: https://sourceware.org/ml/gdb-patches/2017-12/msg00413.html The problem can easily be triggered by stopping on a breakpoint, then setting impossible watchpoints, and finally doing "continue". Then, after having set the step-over state (in keep_going_pass_signal in infrun.c), GDB tries to insert breakpoints and watchpoints into the inferior. This fails, and the "continue" command is aborted. But the step-over state is not cleared in this case, which causes future step-over attempts to be skipped since GDB thinks that "we already have an in-line step-over operation ongoing" (see start_step_over in infrun.c). Thus the next "continue" just goes on to wait for events from the remote, which will never occur. The problem can also be reproduced on amd64 with native-gdbserver, using the following change to watchpoints.exp: -- >8 -- --- a/gdb/testsuite/gdb.base/watchpoints.exp +++ b/gdb/testsuite/gdb.base/watchpoints.exp @@ -61,2 +61,3 @@ with_test_prefix "before inferior start" { gdb_test "watch ival3" ".*" "" + gdb_test "watch *(char \[256\] *) main" -- >8 -- To fix the hang, this patch clears the step-over info when insert_breakpoints has failed. Of course, with native-gdbserver the watchpoints.exp test case still causes many FAILs on s390, because gdbserver does not support watchpoints for that target. This is a separate issue. gdb/ChangeLog: 2018-01-12 Andreas Arnez <arnez@linux.vnet.ibm.com> * infrun.c (keep_going_pass_signal): Clear step-over info when insert_breakpoints fails.
2018-01-12Bump GDB version number to 8.0.91.DATE-git.Joel Brobecker
gdb/ChangeLog: * version.in: Set GDB version number to 8.0.91.DATE-git. * PROBLEMS: Likewise.
2018-01-12Document the GDB 8.0.91 release in gdb/ChangeLogJoel Brobecker
gdb/ChangeLog: GDB 8.0.91 released.
2018-01-12Set GDB version number to 8.0.91.Joel Brobecker
gdb/ChangeLog: * version.in: Set GDB version number to 8.0.91. * PROBLEMS: Likewise.
2018-01-12gdb/NEWS: Rename "Changes since 8.0" into "Changes in 8.1".Joel Brobecker
gdb/ChangeLog: * NEWS: Rename "Changes since 8.0" into "Changes in 8.1".
2018-01-12Automatic date update in version.inGDB Administrator
2018-01-11gdb.base/breakpoint-in-ro-region.exp regression on sss targets (PR gdb/22583)Pedro Alves
As Maciej reported at <https://sourceware.org/ml/gdb-patches/2017-12/msg00212.html>, this commit: commit d930703d68ae160ddfe8ebe5fdcf416fb6090e1e Date: Thu Nov 16 18:44:43 2017 +0000 Subject: Don't ever Quit out of resume caused regressions on software single-set targets, specifically: FAIL: gdb.base/breakpoint-in-ro-region.exp: always-inserted off: auto-hw off: single-step breakpoint is not left behind FAIL: gdb.base/breakpoint-in-ro-region.exp: always-inserted off: auto-hw on: single-step breakpoint is not left behind FAIL: gdb.base/breakpoint-in-ro-region.exp: always-inserted on: auto-hw off: step in ro region (cannot insert hw break) FAIL: gdb.base/breakpoint-in-ro-region.exp: always-inserted on: auto-hw off: single-step breakpoint is not left behind FAIL: gdb.base/breakpoint-in-ro-region.exp: always-inserted on: auto-hw on: single-step breakpoint is not left behind and indeed detailed logs indicate a breakpoint is left lingering, e.g.: (gdb) PASS: gdb.base/breakpoint-in-ro-region.exp: always-inserted off: auto-hw off: step in ro region (cannot insert sw break) maint info breakpoints 0 Num Type Disp Enb Address What 0 sw single-step keep y 0x00400774 in main at [...]/gdb/testsuite/gdb.base/breakpoint-in-ro-region.c:24 inf 1 thread 1 stop only in thread 1 (gdb) FAIL: gdb.base/breakpoint-in-ro-region.exp: always-inserted off: auto-hw off: single-step breakpoint is not left behind vs: (gdb) PASS: gdb.base/breakpoint-in-ro-region.exp: always-inserted off: auto-hw off: step in ro region (cannot insert sw break) maint info breakpoints 0 No breakpoint or watchpoint matching '0'. (gdb) PASS: gdb.base/breakpoint-in-ro-region.exp: always-inserted off: auto-hw off: single-step breakpoint is not left behind as at commit d930703d68ae^. Before commit d930703d68ae, we had a cleanup installed in 'resume' that would delete single-step breakpoints on error: /* Resuming. */ /* Things to clean up if we QUIT out of resume (). */ static void resume_cleanups (void *ignore) { if (!ptid_equal (inferior_ptid, null_ptid)) delete_single_step_breakpoints (inferior_thread ()); normal_stop (); } That whole function was removed by d930703d68ae mainly to eliminate the normal_stop call: ~~~~ Note that the exception called from within resume ends up calling normal_stop via resume_cleanups. That's very borked though, because normal_stop is going to re-handle whatever was the last reported event, possibly even re-running a hook stop... ~~~~ But as the regression shows, removing resume_cleanups completely went a bit too far, as the delete_single_step_breakpoints call is still necessary. So fix the regression by reinstating the delete_single_step_breakpoints call on error. However, since we're trying to eliminate cleanups, restore it in a different form (using TRY/CATCH). Tested on x86-64 GNU/Linux both top of master and on top of a series that implements software single-step on x86. gdb/ChangeLog: 2018-01-11 Pedro Alves <palves@redhat.com> PR gdb/22583 * infrun.c (resume): Rename to ... (resume_1): ... this. (resume): Reimplement as wrapper around resume_1.
2018-01-11Fix backwards compatibility with old GDBservers (PR remote/22597)Pedro Alves
At <https://sourceware.org/ml/gdb-patches/2017-12/msg00285.html>, Maciej reported that commit: commit 5cd63fda035d4ba949e6478406162c4673b3c9ef Date: Wed Oct 4 18:21:10 2017 +0100 Subject: Fix "Remote 'g' packet reply is too long" problems with multiple inferiors made GDB stop working with older stubs. Any attempt to continue execution after the initial connection fails with: [...] Process .../gdb/testsuite/outputs/gdb.base/advance/advance created; pid = 2670 Listening on port 2346 target remote [...]:2346 Remote debugging using [...]:2346 Reading symbols from .../lib64/ld.so.1...done. [Switching to Thread <main>] (gdb) continue Cannot execute this command without a live selected thread. (gdb) The problem is: (gdb) c Cannot execute this command without a live selected thread. (gdb) info threads Id Target Id Frame 1 Thread 14917 0x00007f341cd98ed0 in _start () from /lib64/ld-linux-x86-64.so.2 The current thread <Thread ID 2> has terminated. See `help thread'. ^^^^^^^^^^^ (gdb) Note, thread _2_. There's really only one thread in the inferior (it's still at the entry point), but still GDB added a bogus second thread. The reason GDB started adding a second thread after 5cd63fda035d is this hunk: + if (event->ptid == null_ptid) + { + const char *thr = strstr (p1 + 1, ";thread:"); + if (thr != NULL) + event->ptid = read_ptid (thr + strlen (";thread:"), + NULL); + else + event->ptid = magic_null_ptid; + } Note the else branch that falls back to magic_null_ptid. We reach that when we process the initial stop reply sent back in response to the the "?" (status) packet early in the connection setup: Sending packet: $?#3f...Ack Packet received: T0506:0000000000000000;07:40a510f4fd7f0000;10:d0fe1201577f0000; And note that that response does not include a ";thread:XXX" part. This stop reply is processed after listing threads with qfThreadInfo / qsThreadInfo : Sending packet: $qfThreadInfo#bb...Ack Packet received: m3915 Sending packet: $qsThreadInfo#c8...Ack Packet received: l meaning, when we process that stop reply, we treat the event as coming from a thread with ptid == magic_null_ptid, which is not yet in the thread list, so we add it then: (top-gdb) p ptid $1 = {m_pid = 42000, m_lwp = -1, m_tid = 1} (top-gdb) bt #0 0x0000000000840a8c in add_thread_silent(ptid_t) (ptid=...) at src/gdb/thread.c:269 #1 0x00000000007ad61d in remote_add_thread(ptid_t, int, int) (ptid=..., running=0, executing=0) at src/gdb/remote.c:1838 #2 0x00000000007ad8de in remote_notice_new_inferior(ptid_t, int) (currthread=..., executing=0) at src/gdb/remote.c:1921 #3 0x00000000007b758b in process_stop_reply(stop_reply*, target_waitstatus*) (stop_reply=0x1158860, status=0x7fffffffcc00) at src/gdb/remote.c:7217 #4 0x00000000007b7a38 in remote_wait_as(ptid_t, target_waitstatus*, int) (ptid=..., status=0x7fffffffcc00, options=0) at src/gdb/remote.c:7380 #5 0x00000000007b7cd1 in remote_wait(target_ops*, ptid_t, target_waitstatus*, int) (ops=0x102fac0 <remote_ops>, ptid=..., status=0x7fffffffcc00, options=0) at src/gdb/remote.c:7446 #6 0x000000000081587b in delegate_wait(target_ops*, ptid_t, target_waitstatus*, int) (self=0x102fac0 <remote_ops>, arg1=..., arg2=0x7fffffffcc00, arg3=0) at src/gdb/target-delegates.c:138 #7 0x0000000000827d77 in target_wait(ptid_t, target_waitstatus*, int) (ptid=..., status=0x7fffffffcc00, options=0) at src/gdb/target.c:2179 #8 0x0000000000715fda in do_target_wait(ptid_t, target_waitstatus*, int) (ptid=..., status=0x7fffffffcc00, options=0) at src/gdb/infrun.c:3589 #9 0x0000000000716351 in wait_for_inferior() () at src/gdb/infrun.c:3707 #10 0x0000000000715435 in start_remote(int) (from_tty=1) at src/gdb/infrun.c:3212 things go downhill from this. We don't see the problem with current master gdbserver, because that version always sends the ";thread:" part in the initial stop reply: Sending packet: $?#3f...Packet received: T0506:0000000000000000;07:a0d4ffffff7f0000;10:d05eddf7ff7f0000;thread:p3cea.3cea;core:3; Years ago I had added a "--disable-packet=" command line option to gdbserver which comes in handy for testing this, since the existing "--disable-packet=Tthread" precisely makes gdbserver not send that ";thread:" part in stop replies. The testcase added by this commit emulates old gdbserver making use of that. I've compared a testrun at 5cd63fda035d^ (before regression) with 'current master+patch', against old gdbserver at f8b73d13b7ca^. I hacked out --once, and "monitor exit" to be able to test. The results are a bit too unstable to tell accurately, but it looked like there were no regressions. Maciej confirmed this worked for him as well. No regressions on master (against master gdbserver). gdb/ChangeLog: 2018-01-11 Pedro Alves <palves@redhat.com> PR remote/22597 * remote.c (remote_parse_stop_reply): Default to the last-set general thread instead of to 'magic_null_ptid'. gdb/testsuite/ChangeLog: 2018-01-11 Pedro Alves <palves@redhat.com> PR remote/22597 * gdb.server/stop-reply-no-thread.c: New file. * gdb.server/stop-reply-no-thread.exp: New file.
2018-01-11Automatic date update in version.inGDB Administrator
2018-01-10language_get_symbol_name_matcher -> get_symbol_name_matcherPedro Alves
Rename language_get_symbol_name_matcher -> get_symbol_name_matcher, since the function is no longer a straight "language method". gdb/ChangeLog: 2018-01-10 Pedro Alves <palves@redhat.com> * language.h (language_get_symbol_name_matcher): Rename ... (get_symbol_name_matcher): ... this. * language.c (language_get_symbol_name_matcher): Ditto. * dictionary.c, linespec.c, minsyms.c, psymtab.c, symtab.c: All callers adjusted.
2018-01-10Ada: make verbatim matcher override other language matchers (PR gdb/22670)Pedro Alves
A previous patch fixed verbatim matching in the lookup at the minimal symbol level, but we should also be finding that same symbol through the partial/full symtab search. For example, this is what happens if we use "print" instead of "break": (gdb) p <MixedCaseFunc> $1 = {<text variable, no debug info>} 0x4024dc <MixedCaseFunc> Before the C++ wildmatching series, GDB knows that MixedCaseFunc is a function without parameters, and the expression above means calling it. If you try it before having started the inferior, you'd get the following (expected) error: (gdb) print <MixedCaseFunc> You can't do that without a process to debug. The main idea behind making the name matcher be determined by the symbol's language is so that C++ (etc.) wildmatching in linespecs works even if the current language is not C++, as e.g., when you step through C or assembly code. Ada's verbatim matching syntax however ("<...>") isn't quite the same. It is more a property of the current language than of a particular symbol's language. We want to support this syntax when debugging an Ada program, but it's reason of existence is to find non-Ada symbols. This suggests going back to enabling it depending on current language instead of language of the symbol being matched. I'm not entirely happy with the "current_language" reference (though I think that it's harmless). I think we could try storing the current language in the lookup_name_info object, and then convert a bunch of functions more to pass around lookup_name_info objects instead of "const char *" names. I.e., build the lookup_name_info higher up. I'm not sure about that, I'll have to think more about it. Maybe something different will be better. Meanwhile, this gets us going. I've extended the testcase to also exercise a no-debug-info function, for extra coverage of the minsyms-only paths. gdb/ChangeLog: 2018-01-10 Pedro Alves <palves@redhat.com> PR gdb/22670 * dwarf2read.c (gdb_index_symbol_name_matcher::gdb_index_symbol_name_matcher): Adjust to use language_get_symbol_name_matcher instead of language_defn::la_get_symbol_name_matcher. * language.c (language_get_symbol_name_matcher): If in Ada mode and the lookup name is a verbatim match, return Ada's matcher. * language.h (language_get_symbol_name_matcher): Adjust comment. (ada_lookup_name_info::verbatim_p):: New method. gdb/testsuite/ChangeLog: 2018-01-10 Pedro Alves <palves@redhat.com> PR gdb/22670 * gdb.ada/bp_c_mixed_case.exp: Add intro comment. Test printing C functions too. Test setting breakpoints and printing C functions with no debug info too. * gdb.ada/bp_c_mixed_case/qux.c: New file.
2018-01-10Fix gdb.ada/complete.exp's "complete break ada" test (PR gdb/22670)Pedro Alves
This patch fixes the regression covered by the test added by: commit 344420da6beac1e0b2f7964e7101f8dcdb509b0d Date: Thu Jan 4 03:30:37 2018 -0500 Subject: Add "complete break ada" test to gdb.ada/complete.exp The regression had been introduced by: commit b5ec771e60c1a0863e51eb491c85c674097e9e13 Date: Wed Nov 8 14:22:32 2017 +0000 Subject: Introduce lookup_name_info and generalize Ada's FULL/WILD name matching The gist of it is that linespec completion in Ada mode is generating additional matches that should not appear in the match list (internally generated symbols, or symbols that should be enclosed between "<...>"). These extraneous entries have uppercase characters, such as: break ada__stringsS break ada__strings__R11s [etc] These matches come from minimal symbols. The problem is that Ada minsyms end up with no language set (language_auto), and thus we end up using the generic symbol name matcher for those instead of Ada's. We already had a special case for in compare_symbol_name to handle this, but it was limited to expressions, while the case at hand is completing a linespec. Fix this by applying the special case to linespec completion as well. I.e., remove the EXPRESSION check from compare_symbol_name. That alone turns out to not be sufficient still -- GDB would still show a couple entries that shouldn't be there: ~~ break ada__exceptions__exception_data__append_info_exception_name__2Xn break ada__exceptions__exception_data__exception_name_length__2Xn ~~ The reason is that these minimal symbols end up with their language set to language_cplus / C++, because those encoded names manage to demangle successfully as C++ symbols (using an old C++ mangling scheme): $ echo ada__exceptions__exception_data__append_info_exception_name__2Xn | c++filt Xn::ada__exceptions__exception_data__append_info_exception_name(void) It's unfortunate that Ada's encoding scheme doesn't start with some unique prefix like "_Z" in the C++ Itanium ABI mangling scheme. For now, paper over that by treating C++ minsyms as Ada minsyms. gdb/ChangeLog: 2018-01-10 Pedro Alves <palves@redhat.com> PR gdb/22670 * ada-lang.c (ada_collect_symbol_completion_matches): If the minsym's language is language_auto or language_cplus, pass down language_ada instead. * symtab.c (compare_symbol_name): Don't frob symbol language here. gdb/testsuite/ChangeLog: 2018-01-10 Pedro Alves <palves@redhat.com> PR gdb/22670 * gdb.ada/complete.exp ("complete break ada"): Replace kfail with a fail.
2018-01-10Fix gdb.ada/bp_c_mixed_case.exp (PR gdb/22670)Pedro Alves
The problem here is that we are using the user-provided lookup name literally for name comparisons. I.e., "<MixedCase>" with the "<>"s included. This commit fixes the minsym lookup case. psymbol/symbol lookup will be fixed in a follow up. In the minsym case, we're using using the user-provided lookup name literally for linkage name comparisons. That obviously can't work since the "<>" are not really part of the linkage name. The original idea was that we'd use the symbol's language to select the right symbol name matching algorithm, but that doesn't work for Ada because it's not really possible to unambiguously tell from the linkage name alone whether we're dealing with Ada symbols, so Ada minsyms end up with no language set, or sometimes C++ set. So fix this by treating Ada mode specially when determining the linkage name to match against. gdb/ChangeLog: 2018-01-10 Pedro Alves <palves@redhat.com> PR gdb/22670 * minsyms.c (linkage_name_str): New function. (iterate_over_minimal_symbols): Use it. gdb/testsuite/ChangeLog: 2018-01-10 Pedro Alves <palves@redhat.com> PR gdb/22670 * gdb.ada/bp_c_mixed_case.exp: Remove setup_kfail calls.
2018-01-10Automatic date update in version.inGDB Administrator
2018-01-09Automatic date update in version.inGDB Administrator
2018-01-08hurd: Add enough auxv support for AT_ENTRY for PIE binariesSamuel Thibault
Add PIE support for hurd, by faking an AT_ENTRY auxv entry. That value is expected to be read by svr4_exec_displacement, which will propagate the executable displacement. gdb/ChangeLog: * gdb/gnu-nat.c: Include <elf.h> and <link.h>. (gnu_xfer_auxv): New function. (gnu_xfer_partial): Call gnu_xfer_auxv when `object' is TARGET_OBJECT_AUXV.
2018-01-08Fix GDBserver build failure when $development is falseYao Qi
When we set bfd/development.sh:$development to false, GDBserver failed to build, selftest.o: In function `selftests::run_tests(char const*)': binutils-gdb/gdb/gdbserver/../common/selftest.c:97:undefined reference to `selftests::reset()' collect2: error: ld returned 1 exit status selftest.o shouldn't be compiled and linked when $development is false. With this patch, in release mode, GDBserver doesn't nothing with option --selftest, $ ./gdbserver --selftest=foo Selftests are not available in a non-development build. $ ./gdbserver --selftest Selftests are not available in a non-development build. gdb/gdbserver: 2018-01-08 Yao Qi <yao.qi@linaro.org> Simon Marchi <simon.marchi@ericsson.com> * Makefile.in (OBS): Remove selftest.o. * configure.ac: Set srv_selftest_objs if $development is true. (GDBSERVER_DEPFILES): Append $srv_selftest_objs. * configure: Re-generated. * server.c (captured_main): Wrap variable selftest_filter with GDB_SELF_TEST. gdb/testsuite: 2018-01-08 Simon Marchi <simon.marchi@ericsson.com> * gdb.server/unittest.exp: Match the output in non-development mode.
2018-01-08Fix GDB build failure when $development is falseYao Qi
We don't build GDB selftests bits when $development is false. However, if we turn bfd/development.sh:$development to false, common/selftest.c is compiled which is not expected. It causes the build failure, selftest.o: In function `selftests::run_tests(char const*)': binutils-gdb/gdb/common/selftest.c:97: undefined reference to `selftests::reset()' collect2: error: ld returned 1 exit status I fix this issue by putting selftest.o selftest-arch.o into CONFIG_OBS only when $development is true. After this is fixed, there are other build failures in maint.c, this patch fixes them as well. In the release mode, the output of these commands are: (gdb) maintenance selftest Selftests are not available in a non-development build. (gdb) maintenance selftest foo Selftests are not available in a non-development build. (gdb) maintenance info selftests Selftests are not available in a non-development build. gdb: 2018-01-08 Yao Qi <yao.qi@linaro.org> Simon Marchi <simon.marchi@ericsson.com> * Makefile.in (COMMON_SFILES): Remove selftest-arch.c and common/selftest.c. (COMMON_OBS): Remove selftest.o. * configure.ac: Append selftest-arch.c and common/selftest.c to CONFIG_SRCS. Append selftest-arch.o and selftest.o to COMMON_OBS. * configure: Re-generated. * maint.c (maintenance_selftest): Wrap selftests::run_tests with GDB_SELF_TEST. (maintenance_info_selftests): Likewise. gdb/testsuite: 2018-01-08 Simon Marchi <simon.marchi@ericsson.com> * gdb.gdb/unittest.exp: Match output in non-development mode.
2018-01-08Automatic date update in version.inGDB Administrator
2018-01-07Automatic date update in version.inGDB Administrator
2018-01-06Automatic date update in version.inGDB Administrator
2018-01-05Fix regression: cannot start with LD_PRELOAD=libSegFault.so (PR gdb/18653#c7)Pedro Alves
At https://sourceware.org/bugzilla/show_bug.cgi?id=18653#c7, Andrew reports that the fix for PR gdb/18653 made GDB useless if you preload libSegFault.so, because GDB internal-errors on startup: $ LD_PRELOAD=libSegFault.so gdb src/gdb/common/signals-state-save-restore.c:64: internal-error: unexpected signal handler A problem internal to GDB has been detected, further debugging may prove unreliable. Aborted (core dumped) $ The internal error comes from the code saving the signal dispositions inherited from gdb's parent: (top-gdb) bt #0 0x000000000056b001 in internal_error(char const*, int, char const*, ...) (file=0xaf5f38 "src/gdb/common/signals-state-save-restore.c", line=64, fmt=0xaf5f18 "unexpected signal handler") at src/gdb/common/errors.c:54 #1 0x00000000005752c9 in save_original_signals_state() () at src/gdb/common/signals-state-save-restore.c:64 #2 0x00000000007425de in captured_main_1(captured_main_args*) (context=0x7fffffffd860) at src/gdb/main.c:509 #3 0x0000000000743622 in captured_main(void*) (data=0x7fffffffd860) at src/gdb/main.c:1145 During symbol reading, cannot get low and high bounds for subprogram DIE at 24065. #4 0x00000000007436f9 in gdb_main(captured_main_args*) (args=0x7fffffffd860) at src/gdb/main.c:1171 #5 0x0000000000413acd in main(int, char**) (argc=1, argv=0x7fffffffd968) at src/gdb/gdb.c:32 This commit downgrades the internal error to a warning. You'll get instead: ~~~ $ LD_PRELOAD=libSegFault.so gdb warning: Found custom handler for signal 11 (Segmentation fault) preinstalled. Some signal dispositions inherited from the environment (SIG_DFL/SIG_IGN) won't be propagated to spawned programs. GNU gdb (GDB) 8.0.50.20171213-git Copyright (C) 2017 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-pc-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... (gdb) ~~~ This also moves the location where save_original_signals_state is called a bit further below (to after option processing), so that "-q" disables the warning: ~~~ $ LD_PRELOAD=libSegFault.so gdb -q (gdb) ~~~ New testcase included. gdb/ChangeLog: 2018-01-05 Pedro Alves <palves@redhat.com> PR gdb/18653 * common/signals-state-save-restore.c (save_original_signals_state): New parameter 'quiet'. Warn if we find a custom handler preinstalled, instead of internal erroring. But only warn if !quiet. * common/signals-state-save-restore.h (save_original_signals_state): New parameter 'quiet'. * main.c (captured_main_1): Move save_original_signals_state call after option handling, and pass QUIET. gdb/gdbserver/ChangeLog: 2018-01-05 Pedro Alves <palves@redhat.com> PR gdb/18653 * server.c (captured_main): Pass quiet=false to save_original_signals_state. gdb/testsuite/ChangeLog: 2018-01-05 Pedro Alves <palves@redhat.com> PR gdb/18653 * gdb.base/libsegfault.exp: New.
2018-01-05Fix gdb/spu-tdep.c build breakagePedro Alves
Commit de63c46b549d ("Fix regresssion(internal-error) printing subprogram argument (PR gdb/22670)") missed updating spu-tdep.c for the block_lookup_symbol interface change, resulting in: ../../binutils-gdb/gdb/spu-tdep.c: In function void spu_catch_start(objfile*): ../../binutils-gdb/gdb/spu-tdep.c:1969:59: error: cannot convert domain_enum_tag to symbol_name_match_type for argument 3 to symbol* block_lookup_symbol(const block*, const char*, symbol_name_match_type, domain_enum) sym = block_lookup_symbol (block, "main", VAR_DOMAIN); ^ gdb/ChangeLog: 2018-01-05 Pedro Alves <palves@redhat.com> * spu-tdep.c (spu_catch_start): Pass symbol_name_match_type::SEARCH_NAME to block_lookup_symbol.
2018-01-05Fix regresssion(internal-error) printing subprogram argument (PR gdb/22670)Pedro Alves
At <https://sourceware.org/ml/gdb-patches/2017-12/msg00298.html>, Joel wrote: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Consider the following code which first declares a tagged type (the equivalent of a class in Ada), and then a procedure which takes a pointer (access) to this type's 'Class. package Pck is type Top_T is tagged record N : Integer := 1; end record; procedure Inspect (Obj: access Top_T'Class); end Pck; Putting a breakpoint in that procedure and then running to it triggers an internal error: (gdb) break inspect (gdb) continue Breakpoint 1, pck.inspect (obj=0x63e010 /[...]/gdb/stack.c:621: internal-error: void print_frame_args(symbol*, frame_info*, int, ui_file*): Assertion `nsym != NULL' failed. What's special about this subprogram is that it takes an access to what we call a 'Class type, and for implementation reasons, the compiler adds an extra argument named "objL". If you are curious why, it allows the compiler for perform dynamic accessibility checks that are mandated by the language. If we look at the location where we get the internal error (in stack.c), we find that we are looping over the symbol of each parameter, and for each parameter, we do: /* We have to look up the symbol because arguments can have two entries (one a parameter, one a local) and the one we want is the local, which lookup_symbol will find for us. [...] nsym = lookup_symbol (SYMBOL_LINKAGE_NAME (sym), b, VAR_DOMAIN, NULL).symbol; gdb_assert (nsym != NULL); The lookup_symbol goes through the lookup structure, which means the symbol's linkage name ("objL") gets transformed into a lookup_name_info object (in block_lookup_symbol), before it gets fed to the block symbol dictionary iterators. This, in turn, triggers the symbol matching by comparing the "lookup" name which, for Ada, means among other things, lowercasing the given name to "objl". It is this transformation that causes the lookup find no matches, and therefore trip this assertion. Going back to the "offending" call to lookup_symbol in stack.c, what we are trying to do, here, is do a lookup by linkage name. So, I think what we mean to be doing is a completely literal symbol lookup, so maybe not even strcmp_iw, but actually just plain strcmp??? In the past, in practice, you could get that effect by doing a lookup using the C language. But that doesn't work, because we still end up somehow using Ada's lookup_name routine which transforms "objL". So, ideally, as I hinted before, I think what we need is a way to perform a literal lookup so that searches by linkage names like the above can be performed. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This commit fixes the problem by implementing something similar to Joel's literal idea, but with some important differences. I considered adding a symbol_name_match_type::LINKAGE and supporting searching by linkage name for any language, but the problem with that is that the dictionaries only work with SYMBOL_SEARCH_NAME, because that's what is used for hashing. We'd need separate dictionaries for hashed linkage names. So with the current symbol tables infrastructure, it's not literal linkage names that we want to pass down, but instead literal _search_ names (SYMBOL_SEARCH_NAME, etc.). However, psymbols have no overload/function parameter info in C++, so a straight strcmp doesn't work properly for C++ name matching. So what we do is be a little less aggressive then and add a new symbol_name_match_type::SEARCH_SYMBOL instead that takes as input a non-user-input search symbol, and then we skip any decoding/demangling steps and make: - Ada treat that as a verbatim match, - other languages treat it as symbol_name_match_type::FULL. This also fixes the new '"maint check-psymtabs" for Ada' testcase for me (gdb.ada/maint_with_ada.exp). I've not removed the kfail yet because Joel still sees that testcase failing with this patch. That'll be fixed in follow up patches. gdb/ChangeLog: 2018-01-05 Pedro Alves <palves@redhat.com> PR gdb/22670 * ada-lang.c (literal_symbol_name_matcher): New function. (ada_get_symbol_name_matcher): Use it for symbol_name_match_type::SEARCH_NAME. * block.c (block_lookup_symbol): New parameter 'match_type'. Pass it down instead of assuming symbol_name_match_type::FULL. * block.h (block_lookup_symbol): New parameter 'match_type'. * c-valprint.c (print_unpacked_pointer): Use lookup_symbol_search_name instead of lookup_symbol. * compile/compile-object-load.c (get_out_value_type): Pass down symbol_name_match_type::SEARCH_NAME. * cp-namespace.c (cp_basic_lookup_symbol): Pass down symbol_name_match_type::FULL. * cp-support.c (cp_get_symbol_name_matcher): Handle symbol_name_match_type::SEARCH_NAME. * infrun.c (insert_exception_resume_breakpoint): Use lookup_symbol_search_name. * p-valprint.c (pascal_val_print): Use lookup_symbol_search_name. * psymtab.c (maintenance_check_psymtabs): Use symbol_name_match_type::SEARCH_NAME and SYMBOL_SEARCH_NAME. * stack.c (print_frame_args): Use lookup_symbol_search_name and SYMBOL_SEARCH_NAME. * symtab.c (lookup_local_symbol): Don't demangle the lookup name if symbol_name_match_type::SEARCH_NAME. (lookup_symbol_in_language): Pass down symbol_name_match_type::FULL. (lookup_symbol_search_name): New. (lookup_language_this): Pass down symbol_name_match_type::SEARCH_NAME. (lookup_symbol_aux, lookup_local_symbol): New parameter 'match_type'. Pass it down. * symtab.h (symbol_name_match_type::SEARCH_NAME): New enumerator. (lookup_symbol_search_name): New declaration. (lookup_symbol_in_block): New 'match_type' parameter. gdb/testsuite/ChangeLog: 2018-01-05 Joel Brobecker <brobecker@adacore.com> PR gdb/22670 * gdb.ada/access_tagged_param.exp: New file. * gdb.ada/access_tagged_param/foo.adb: New file.
2018-01-05Fix gdb.ada/info_addr_mixed_case.exp (PR gdb/22670)Pedro Alves
The comments about mixed case in the testcase are actually a red herring. The problem here is that we'd get to ada_lookup_encoded_symbol with "my_table", which wraps the looked up name in "<>"s to force a verbatim match, and that in turn disables wild matching. Fix this by swapping around the internals of ada_lookup_encoded_symbol and ada_lookup_symbol, thus avoiding the encoding and verbatim-wrapping in the ada_lookup_symbol case, the case that starts with a user-provided lookup name. Ada encoding is still done of course, in the ada_lookup_name_info ctor. This could be also seen as avoiding the double-encoding problem in a different way. gdb/ChangeLog: 2018-01-05 Pedro Alves <palves@redhat.com> PR gdb/22670 * ada-lang.c (ada_lookup_encoded_symbol): Reimplement in terms of ada_lookup_symbol. (ada_lookup_symbol): Reimplement in terms of ada_lookup_symbol_list, bits factored out from ada_lookup_encoded_symbol. gdb/testsuite/ChangeLog: 2018-01-05 Pedro Alves <palves@redhat.com> PR gdb/22670 * gdb.ada/info_addr_mixed_case.exp: Remove kfail. Extend test to exercise lower case too, and to exercise both full matching and wild matching.
2018-01-05Set development mode to "off" by default.Joel Brobecker
bfd/ChangeLog: * development.sh (development): Set to false.
2018-01-05Bump version to 8.0.90.DATE-git.Joel Brobecker
Now that the GDB 8.1 branch has been created, we can bump the version number. gdb/ChangeLog: GDB 8.1 branch created (5219ac6237c272b938c28517bf371429260c71e7): * version.in: Bump version to 8.0.90.DATE-git.
2018-01-05Automatic date update in version.inGDB Administrator
2018-01-04RISC-V: Add 2 missing privileged registers.Jim Wilson
gas/ * testsuite/gas/riscv/priv-reg.s: Add missing stval and mtval. * testsuite/gas/riscv/priv-reg.d: Likewise. include/ * opcode/riscv-opc.h (CSR_SBADADDR): Rename to CSR_STVAL. Rename DECLARE_CSR entry. Add alias to map sbadaddr to CSR_STVAL. (CSR_MBADADDR): Rename to CSR_MTVAL. Rename DECLARE_CSR entry. Add alias to map mbadaddr to CSR_MTVAL.
2018-01-04gdb.ada/maint_with_ada.exp: New testcaseJoel Brobecker
This commit adds a new testcase testing the "check-psymtabs" and "check-symtabs" maintenance commands. The "maintenance check-psymtabs" commands is currently known to produce some errors. While the situation was admetedly made worse by the following patch... commit b5ec771e60c1a0863e51eb491c85c674097e9e13 Date: Wed Nov 8 14:22:32 2017 +0000 Subject: Introduce lookup_name_info and generalize Ada's FULL/WILD name matching ... hence the reference to PR gdb/22670, the command was already spotting one inconsistency prior to it: (gdb) maintenance check-psymtabs Global symbol `interfaces__cS' only found in /[...]/b~var_arr_typedef.adb psymtab For now, the "check-psymtab" test is KFAIL-ed. gdb/testsuite/ChangeLog: PR gdb/22670 * gdb.ada/maint_with_ada: New testcase. Tested on x86_64-linux.
2018-01-04Add new gdb.ada/bp_c_mixed_case testcase for PR gdb/22670Joel Brobecker
This patch adds a new testcase to demonstrate a regression introduced by: commit b5ec771e60c1a0863e51eb491c85c674097e9e13 Date: Wed Nov 8 14:22:32 2017 +0000 Subject: Introduce lookup_name_info and generalize Ada's FULL/WILD name matching The purpose of the testcase is to verify that a user can insert a breakpoint on a C function while debugging Ada, even if the name of the function includes uppercase letters, requiring us to use Ada's "<...>" notation to tell the GDB that the symbol name should be looked up verbatim. As of the commit above, GDB is no longer finding the function: (gdb) break <MixedCaseFunc> Function "<MixedCaseFunc>" not defined. Make breakpoint pending on future shared library load? (y or [n]) Before the patch, the breakpoint was inserted without problem. gdb/testsuite/ChangeLog: PR gdb/22670 * gdb.ada/bp_c_mixed_case: New testcase. Tested on x86_64-linux; generates a KPASS before the regression was introduced, and now generates a KFAIL.
2018-01-04Add "complete break ada" test to gdb.ada/complete.expJoel Brobecker
This patch adds a new test to demonstrate a regression introduced by: commit b5ec771e60c1a0863e51eb491c85c674097e9e13 Date: Wed Nov 8 14:22:32 2017 +0000 Subject: Introduce lookup_name_info and generalize Ada's FULL/WILD name matching The original purpose of the new test is to exercise the "complete" command with an expression for which a large number of matches are returned and to verify that each match returned is a plausible match. In this particular case, the commit above causes GDB to generate additional matches which should in fact not appear in the list (internally generated symbols, or symbols that should be enclosed between "<...>"). These extraneous entries are easy to spot, because they have uppercase characters, such as: break ada__stringsS break ada__strings__R11s [etc] For now, the new test is KFAIL'ed, to avoid generating a new FAIL while we work on fixing that regression. gdb/testsuite/ChangeLog: PR gdb/22670 * gdb.ada/complete.exp: Add "complete break ada" test. Tested on x86_64-linux with GDB built before and after the patch that caused the regression (b5ec771e60c1a0863e51eb491c85c674097e9e13). The test passes before the regression, and generates a KFAIL after.
2018-01-04Add gdb.ada/info_addr_mixed_case new testcaseJoel Brobecker
This patch adds a new testcase to demonstrate a regression introduced by: commit b5ec771e60c1a0863e51eb491c85c674097e9e13 Date: Wed Nov 8 14:22:32 2017 +0000 Subject: Introduce lookup_name_info and generalize Ada's FULL/WILD name matching The purpose of the testcase is to verify that a user can use any casing for an Ada symbol name passed to the "info address" command. After the patch above was applied, GDB was no longer able to find the symbol: (gdb) info address My_Table No symbol "My_Table" in current context. gdb/testsuite/ChangeLog: PR gdb/22670 * gdb.ada/info_addr_mixed_case: New testcase. Tested on x86_64-linux, both before and after the patch.
2018-01-04Automatic date update in version.inGDB Administrator
2018-01-03Create pseudo sections for FreeBSD NT_PROCSTAT_(PROC|FILES|VMMAP) notes.John Baldwin
bfd/ChangeLog: * elf.c (elfcore_grok_freebsd_note): Handle NT_FREEBSD_PROCSTAT_PROC, NT_FREEBSD_PROCSTAT_FILES, and NT_FREEBSD_PROCSTAT_VMMAP.
2018-01-03Fix compile time warning introduced by previous delta.Nick Clifton
* objcopy.c (merge_gnu_build_notes): Add cast to maximum address constants.
2018-01-03Add support for v3 binary annotation notes.Nick Clifton
I am checking in the attached patch which updates the binutils support for version 3 binary annotation notes. (Version 3 adds an end address to the ranges covered by the notes, so that it is possible to detect gaps in the coverage). This patch also stops the note merging feature of objcopy from executing if the notes have relocations against them. This makes the code simpler, and prevents the problems with architectures which have unusual relocation management issues. * objcopy.c (objcopy_internal_note): New structure. (gap_exists): New function. (is_open_note): New function. (is_func_note): New function. (is_64bit): New function. (merge_gnu_build_notes): Handle v3 notes. Do not merge if there are relocations against the notes. * readelf.c (get_note_type): Use short names for build attribute notes. (print_symbol_for_build_attribute): Rename to get_symbol_for_build_attribute. Returns the found symbol rather than printing it. (print_gnu_build_attribute_description): Maintain address ranges for function notes as well as global notes. Handle v3 notes. (print_gnu_build_attribute_name): Use more space for printing the name in wide mode. * testsuite/binutils-all/note-2-32.s: Use .dc.l instead of .word. Eliminate symbol references in order to remove the need for relocations. * testsuite/binutils-all/note-2-64.s: Likewise. * testsuite/binutils-all/note-3-32.s: Add a size to the note_1 symbol. * testsuite/binutils-all/note-3-64.s: Likewise. * testsuite/binutils-all/mips/mips-note-2r-n32.d: Update expected output. * testsuite/binutils-all/mips/mips-note-2r-n64.d: Likewise. * testsuite/binutils-all/mips/mips-note-2r.d: Likewise. * testsuite/binutils-all/note-2-32.d: Likewise. * testsuite/binutils-all/note-2-64.d: Likewise. * testsuite/binutils-all/note-3-32.d: Likewise. * testsuite/binutils-all/note-3-64.d: Likewise. * testsuite/binutils-all/note-4-64.s: New test. Checks v3 notes. * testsuite/binutils-all/note-4-32.s: New test. * testsuite/binutils-all/note-4-64.d: New test result file. * testsuite/binutils-all/note-4-32.d: New test result file.
2018-01-03(Ada) New command to stop at start of exception handler.Xavier Roirand
When using gdb for debugging Ada source code, there are several catchpoint types you can define in order to stop upon certain conditions. Let's use this small example: procedure Foo is begin begin raise Constraint_Error; exception when Program_Error => null; when Constraint_Error => null; when others => null; end; end Foo; One can stop when the exception is being raised by using the exception catchpoint like below: (gdb) catch exception Catchpoint 1: all Ada exceptions (gdb) In that case, when running Foo, gdb will stop at the line where the exception was raised: begin >>> raise Constraint_Error; exception This patch introduces new type of catchpoint, when the user wants to stop at the location of the exception handling. Imagine we want to stop on any exception handled by the program, we can do: (gdb) catch handlers Catchpoint 1: all Ada exceptions handlers (gdb) r Starting program: /tmp/foo By doing so, when running Foo, gdb will stop here: Catchpoint 1, exception at 0x000000000040255a in foo () at foo.adb:25 25 when Constraint_Error => (gdb) It is also possible to stop when the Constraint_Error exception is being handled in this program. With this patch, we can use: (gdb) catch handlers Constraint_Error Catchpoint 1: `Constraint_Error' Ada exception handlers (gdb) Like for other catchpoint, you can set a condition when adding a catchpoint on exception handlers. Here the handlers catchpoint checks Global_Var: (gdb) catch handlers Constraint_Error if Global_Var /= 0 gdb/ChangeLog: * ada-lang.h (ada_exception_catchpoint_kind) <ada_catch_handlers>: Add field. * ada-lang.c (struct exception_support_info) <catch_handlers_sym>: Add field. (default_exception_support_info) <catch_handlers_sym>: Add field. (exception_support_info_fallback) <catch_handlers_sym>: Add field. (ada_exception_name_addr_1): Add "catch handlers" handling. (ada_exception_catchpoint_cond_string) <ex>: New parameter. Update all callers. (create_excep_cond_exprs) <ex>: Add parameter. (re_set_exception): Update create_excep_cond_exprs call. (print_it_exception, print_one_exception, print_mention_exception) (print_recreate_exception): Add "catch handler" handling. (allocate_location_catch_handlers, re_set_catch_handlers) (check_status_catch_handlers, print_it_catch_handlers) (print_one_catch_handlers, print_mention_catch_handlers) (print_recreate_catch_handlers): New function. (catch_handlers_breakpoint_ops): New variable. (catch_ada_exception_command_split) <is_catch_handlers_cmd>: Add parameter. Add "catch handler" handling. (ada_exception_sym_name, ada_exception_breakpoint_ops): Add "catch handler" handling. (ada_exception_catchpoint_cond_string): Add "catch handler" handling. (create_ada_exception_catchpoint): Update create_excep_cond_exprs call. (catch_ada_handlers_command): New function. (initialize_ada_catchpoint_ops): Initialize "catch handlers" operations structure. (_initialize_ada_language): Add "catch handlers" command entry. * NEWS: Document "catch handlers" feature. gdb/doc/ChangeLog: * gdb.texinfo (Set Catchpoints): Add documentation for new "catch handlers" action. gdb/testsuite/ChangeLog: * gdb.ada/excep_handle.exp: New testcase. * gdb.ada/excep_handle/foo.adb: New file. * gdb.ada/excep_handle/pck.ads: New file. Tested on x86_64-linux.
2018-01-03Update year range in copyright notice of binutils filesAlan Modra
2018-01-03ChangeLog rotationAlan Modra
2018-01-03Unbreak spurious fails in gdb.base/step-line.expJoel Brobecker
My copyright year update in the copyright headers of the step-line testcase caused it to start failing, due to shift in line numbers. FAIL: gdb.base/step-line.exp: continue to f1 FAIL: gdb.base/step-line.exp: next to dummy 2 FAIL: gdb.base/step-line.exp: next over dummy 2 FAIL: gdb.base/step-line.exp: step into f2 FAIL: gdb.base/step-line.exp: next over dummy 4 FAIL: gdb.base/step-line.exp: next to dummy 5 FAIL: gdb.base/step-line.exp: next to dummy 6 FAIL: gdb.base/step-line.exp: next over dummy 6 FAIL: gdb.base/step-line.exp: next to dummy 7 FAIL: gdb.base/step-line.exp: next to dummy 8 FAIL: gdb.base/step-line.exp: next over dummy 8 FAIL: gdb.base/step-line.exp: next to dummy 9 FAIL: gdb.base/step-line.exp: next to dummy 10 FAIL: gdb.base/step-line.exp: next over dummy 10 This was caused by the copyright.py script after I changed it to also update this testcase, which made the following transformation: - Copyright (C) 2001-2017 - Free Software Foundation, Inc. + Copyright (C) 2001-2018 Free Software Foundation, Inc. We can easily unbreak the testcase without having to go back to manual edits each year by adding an extra line in the header. gdb/testsuite/ChangeLog: * gdb.base/step-line.c: Add extra empty line in copyright header. * gdb.base/step-line.inp: Likewise. Tested on x86_64-linux.
2018-01-03Automatic date update in version.inGDB Administrator
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-11 14:14:03 +0000