aboutsummaryrefslogtreecommitdiff
path: root/gdb/testsuite/lib
AgeCommit message (Collapse)AuthorFilesLines
2021-06-08[gdb/testsuite] Fix gdb.base/info-macros.exp with check-read1Tom de Vries1-0/+82
With check-read1 we run into: ... FAIL: gdb.base/info-macros.exp: info macros info-macros.c:42 (timeout) ... Fix this by using gdb_test_lines from gdb.base/info-types.exp.tcl. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2021-06-08 Tom de Vries <tdevries@suse.de> * gdb.base/info-types.exp.tcl (match_line, gdb_test_lines): Move ... * lib/gdb.exp: ... here. * gdb.base/info-macros.exp: Use gdb_test_lines.
2021-06-02gdb/testsuite: only add -J option when compiling with gfortranAndrew Burgess1-1/+3
We currently make use of the -J option to gfortran in order that compiled modules should be placed in the correct output directory. Obviously different compilers, e.g. flang, will have different options to achieve the same result. This commit makes it so we only add the -J flag when using a gcc based (i.e. gfortran) compiler. I had a look through the flang help page and tried a few likely looking options, but couldn't find anything that seemed to do the same thing, so, for now, I'm only adding an extra option when compiling with gfortran. This does mean that any compiler other than gfortran might run into problems if running the testsuite in parallel due to modules of the same name all being written to the same directory, and so possibly overwriting each other. gdb/testsuite/ChangeLog: * lib/gdb.exp (gdb_compile): Only add the -J option when using a gcc based Fortran compiler, for example, flang does not support this option.
2021-06-02gdb/testsuite: escape '*' character in pattern used by flangAndrew Burgess1-1/+1
One of the integer type patterns used by flang included a '*' character which was not escaped. gdb/testsuite/ChangeLog: * lib/fortran.exp (fortran_int8): Escape '*' in pattern.
2021-05-13gdb/testsuite: remove some duplicate test names from guile testsAndrew Burgess1-3/+12
The guile support library has some "tests" that are actually being used to setup GDB ready for the real guile tests, e.g. we load some support modules, and define some helper functions. As this setup is done every time we call gdb_guile_runto_main, which could be called multiple times in a single test script, this can lead to duplicate PASS lines. As this setup is all pretty basic, and isn't the actual focus of the real tests, then in this commit I pass an empty test name through to the gdb_test_no_output calls, the result of this is that the PASS lines are no longer printed. This removes some duplicate tests from the gdb.guile/*.exp set of tests. gdb/testsuite/ChangeLog: * lib/guile.exp (gdb_scm_load_file): Use empty test name to silence PASS lines. (gdb_install_guile_module): Likewise.
2021-04-29[gdb/testsuite] Fix timeout in gdb.base/valgrind-infcall-2.expTom de Vries1-1/+1
Since commit 6d5702a5eb3 "Fix test case gdb.base/valgrind-bt.exp" I run into: ... FAIL: gdb.base/valgrind-infcall-2.exp: target remote for vgdb (timeout) FAIL: gdb.base/valgrind-infcall-2.exp: monitor v.set gdb_output (timeout) ... The commit adds this line in proc vgdb_start: ... set vgdbcmd "set remotetimeout 3" ... which has no effect given that the value of var vgdbcmd is not used before it's overwritten. We can fix this by doing instead: ... set_remotetimeout 3 ... The FAIL I'm observing is fixed by increasing the remotetimeout value to 4. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2021-04-29 Tom de Vries <tdevries@suse.de> PR testsuite/27786 * lib/valgrind.exp (vgdb_start): Use set_remotetimeout. Increase remotetimeout to 4.
2021-04-27Fix timeout with maint print objfilesLuis Machado1-5/+12
I'm seeing timeouts from gdb.rust/traits.exp when we attempt to print things with "maint print objfiles". This happens for two reasons: 1 - GDB does not explicitly split each entry into its own line, but rather relies on the terminal's width to insert line breaks. 2 - When running the GDB testsuite, such width may be unlimited, which will prevent GDB from inserting any line breaks. As a result, the output may be too lengthy and will come in big lines. Tweak the support library to match the patterns line-by-line, which gives us more time to match things. Also fix GDB's output to print one entry per line, regardless of the terminal width. A similar approach was used in another testcase using the same command (commit eaeaf44cfdc9a4096a0dd52fa0606f29d4bfd48e). With the new line breaks, we don't need a particular pattern, so clean up that test as well. gdb/ChangeLog: 2021-04-27 Luis Machado <luis.machado@linaro.org> * psymtab.c (psymbol_functions::dump): Output newline. * symmisc.c (dump_objfile): Likewise. gdb/testsuite/ChangeLog: 2021-04-27 Luis Machado <luis.machado@linaro.org> * gdb.base/maint.exp: Drop a pattern that is not needed. * lib/gdb.exp (readnow): Match line-by-line.
2021-04-21Fix test case gdb.base/valgrind-bt.exp.Carl Love1-1/+4
gdb/testsuite/ChangeLog: * gdb.base/valgrind-bt.exp: Add gdb_test "break main". Update expected string for gdb_test "bt". * lib/valgrind.exp: Add set remotetimeout 3. Increase vgdb wait from 1 to 2. Add max-invoke-ms option to vgdb command line.
2021-04-15gdb: process early initialization files and command line optionsAndrew Burgess1-0/+1
Adds the ability to process commands at a new phase during GDB's startup. This phase is earlier than the current initialisation file processing, before GDB has produced any output. The number of commands that can be processed at this early stage will be limited, and it is expected that the only commands that would be processed at this stage will relate to some of the fundamentals of how GDB starts up. Currently the only commands that it makes sense to add to this early initialization file are those like 'set style version ....' as the version string is displayed during startup before the standard initialization files are parsed. As such this commit fully resolved bug cli/25956. This commit adds a mechanism to execute these early initialization files from a users HOME directory, as well as some corresponding command line flags for GDB. The early initialization files that GDB will currently check for are ~/.config/gdb/gdbearlyinit (on Linux like systems) or ~/.gdbearlyinit if the former is not found. The output of 'gdb --help' has been extended to include a list of the early initialization files being processed. gdb/ChangeLog: PR cli/25956 * NEWS: Mention new early init files and command line options. * config.in: Regenerate. * configure: Regenerate. * configure.ac: Define GDBEARLYINIT. * main.c (get_earlyinit_files): New function. (enum cmdarg_kind): Add CMDARG_EARLYINIT_FILE and CMDARG_EARLYINIT_COMMAND. (captured_main_1): Add support for new command line flags, and for processing startup files. (print_gdb_help): Include startup files in the output. gdb/doc/ChangeLog: PR cli/25956 * gdb.texinfo (File Options): Mention new command line options. (Startup): Discuss when early init files are processed. (Initialization Files): Add description of early init files. (Output Styling): Update description of 'version' style. (gdb man): Mention early init files. gdb/testsuite/ChangeLog: PR cli/25956 * gdb.base/early-init-file.c: New file. * gdb.base/early-init-file.exp: New file. * lib/gdb-utils.exp (style): Handle style 'none'.
2021-04-14testsuite, gdb: recognize DW_OP_fbreg in lib/dwarf.expTankut Baris Aktemur1-0/+5
gdb/testsuite/ChangeLog: 2021-04-14 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com> * lib/dwarf.exp (_location): Recognize DW_OP_fbreg as an op.
2021-04-07gdb/testsuite: fix fission support in the Dwarf assemblerAndrew Burgess1-44/+217
This commit fixes fission support in the Dwarf assembler. I added the new test gdb.dwarf2/fission-absolute-dwo.exp which is a simple example of using the fission support. I also rewrote the existing test gdb.dwarf2/fission-multi-cu.exp to use the new functionality (instead of using an x86-64 only assembler file). To better support compiling the assembler files produced by the Dwarf assembler I have added the new proc build_executable_and_dwo_files in lib/dwarf.exp, this replaces build_executable_from_fission_assembler, all the tests that used the old proc have been updated. Where the old proc assumed a single .S source file which contained the entire test, the new proc allows for multiple source files. The Dwarf assembler already had some fission support, however, this was not actually used in any tests, and when I tried using it there were a few issues. The biggest change is that we now generate DW_FORM_GNU_addr_index instead of DW_FORM_addr for the low and high pc in _handle_macro_at_range, support for the DW_FORM_GNU_addr_index is new in this commit. gdb/testsuite/ChangeLog: * gdb.dwarf2/fission-absolute-dwo.c: New file. * gdb.dwarf2/fission-absolute-dwo.exp: New file. * gdb.dwarf2/fission-base.exp: Use build_executable_and_dwo_files instead of build_executable_from_fission_assembler. * gdb.dwarf2/fission-loclists-pie.exp: Likewise. * gdb.dwarf2/fission-loclists.exp: Likewise.
2021-04-01Fix obvious typo in gdb/testsuite/lib/pdtrace.inEgeyar Bagcioglu1-1/+1
2021-04-01[gdb/testsuite] Fix unset of DEBUGINFOD_URLS in default_gdb_initTom de Vries1-3/+1
In commit cfcbd506fb0 "[gdb/testsuite] Ignore DEBUGINFOD_URLS" I added unsetting of env(DEBUGINFOD_URLS), but it doesn't work because I forgot to add :: in front. Fix this, and rewrite using "unset -nocomplain" instead of unsetenv, which allows us to drop the "info exists" test. 2021-04-01 Tom de Vries <tdevries@suse.de> * lib/gdb.exp (default_gdb_init): Use ::env. Use unset -nocomplain ::env(V) instead of unsetenv V.
2021-03-31Add some error checking to DWARF assemblerTom Tromey1-33/+52
I had written a DWARF location expression like DW_OP_const1u DW_OP_stack_value ... and was surprised to see that the DW_OP_stack_value didn't appear in the "readelf" output. The problem here is that DW_OP_const1u requires an operand, but neither the DWARF assembler nor gas diagnosed this problem. This patch adds some checking to Dwarf::_location to try to avoid this in the future. The checking is done via a helper proc that also dissects the argument list and sets an array in the caller's frame. gdb/testsuite/ChangeLog 2021-03-31 Tom Tromey <tromey@adacore.com> * lib/dwarf.exp (Dwarf::_get_args): New proc. (Dwarf::_location): Use it.
2021-03-31[gdb/testsuite] Ignore DEBUGINFOD_URLSTom de Vries1-0/+6
On openSUSE Tumbleweed, DEBUGINFOD_URLS is now defined by default: ... $ echo $DEBUGINFOD_URLS https://debuginfod.opensuse.org/ ... With DEBUGINFOD_URLS defined we run into: ... FAIL: gdb.mi/mi-sym-info.exp: List all functions from debug information only \ (timeout) ... as reported in PR27667. There's a latency of ~0.5s per request, which is ok-ish for interactive usage. But the symbol-info-functions command ends up issuing 21 source requests, which means we easily run into the 10s timeout. Fix this by unsetting DEBUGINFOD_URLS in default_gdb_init. gdb/testsuite/ChangeLog: 2021-03-31 Tom de Vries <tdevries@suse.de> PR testsuite/27667 * lib/gdb.exp (default_gdb_init): Unset DEBUGINFOD_URLS.
2021-03-25gdb/testsuite: use -wrap with gdb_test_multiple in lib/ada.expAndrew Burgess1-2/+2
I ran into a new failure in gdb.base/gdb-caching-proc.exp: FAIL: gdb.base/gdb-caching-proc.exp: supports_memtag: initial: memory-tag check This is a failure from the `supports_memtag` proc added recently (this new proc is in lib/gdb.exp). The problem here is that `supports_memtag` is hitting one of the default error cases in gdb_test_multiple, specifically it is finding a $gdb_prompt left unmatched from an earlier call to gdb_test_multiple. Looking back through the test output I found that the problem is the proc `gnat_runtime_has_debug_info` in lib/ada.exp. This proc is not matching the trailing $gdb_prompt. This leaves the prompt in the expect buffer, then when we run `supports_memtag` it sees the prompt and thinks that the test completed with no output. Fixed by making use of `-wrap` in `gnat_runtime_has_debug_info` to ensure the trailing prompt gets matched. gdb/testsuite/ChangeLog: * lib/ada.exp (gnat_runtime_has_debug_info): Use -wrap with gdb_test_multiple.
2021-03-24Add memory tagging testcasesLuis Machado1-0/+16
Add an AArch64-specific test and a more generic memory tagging test that other architectures can run. Even though architectures not supporting memory tagging can run the memory tagging tests, the runtime check will make the tests bail out early, as it would make no sense to proceed without proper support. It is also tricky to do any further runtime tests for memory tagging, given we'd need to deal with tags, and those are arch-specific. Therefore the test in gdb.base is more of a smoke test. If an architecture wants to implement memory tagging, then it makes sense to have tests within gdb.arch instead. gdb/testsuite/ChangeLog: 2021-03-24 Luis Machado <luis.machado@linaro.org> * gdb.arch/aarch64-mte.c: New file. * gdb.arch/aarch64-mte.exp: New test. * gdb.base/memtag.c: New file. * gdb.base/memtag.exp: New test. * lib/gdb.exp (supports_memtag): New function.
2021-03-22gdb/testsuite: use the correct .debug_str section name for DW_FORM_strpAndrew Burgess1-1/+1
When handling DWARF attributes of the form DW_FORM_strp the strings should be placed in the .debug_str section, not .debug_string as they currently are by the DWARF assembler (in lib/dwarf.exp). I've added a test. This is as much to test the DWARF generator as it is to test GDB as GCC makes frequent use of DW_FORM_strp so we can be pretty sure this part of GDB is already well tested. gdb/testsuite/ChangeLog: * gdb.dwarf2/dw2-using-debug-str.c: New file. * gdb.dwarf2/dw2-using-debug-str.exp: New file. * lib/dwarf.exp (Dwarf::DW_FORM_strp): Create .debug_str section, not .debug_string.
2021-03-19Fix potential hang during gdbserver testingKevin Buettner1-1/+6
We're currently seeing testing of native-extended-gdbserver hang while testing the x86_64 architecture on both Fedora 34 and Fedora Rawhide. The test responsible for the hang is gdb.threads/fork-plus-threads.exp. While there is clearly a problem/bug with this test on F34 and Rawhide, it's also the case that testing should not hang. This commit prevents the hang by waiting with the "-nowait" flag in close_gdbserver. The -nowait flag is also used in the kill_wait_spawned_process proc in gdb/testsuite/lib/gdb.exp, so there is precedent for doing this. There are also 15 other uses of "wait -i" scattered throughout the test suite. While it's tempting to change these to also use the -nowait flag, I think it might be safer to defer doing so until we actually see a problem. I've tested this patch on Fedora 32, 33, 34, and Rawhide. Results are comparable on Fedora 32 and 33. On Fedora 34 and Rawhide, with this commit in place, testing completes when the target_board is native-extended-gdbserver. On those OSes, when not using this commit, testing usually hangs due to a problem with gdb.threads/fork-plus-threads.exp. I've also tested on all of the mentioned OSes with target_board=native-gdbserver; for that testing, I achieved comparable results over a number of runs. (Unfortunately results are rarely identical due to racy tests.) gdb/testsuite/ChangeLog: * lib/gdbserver-support.exp (gdbserver_exit): Use the "-nowait" flag when waiting for gdbserver to exit.
2021-03-16gdb/testsuite: squash duplicate test names in gdb.threads/*.expAndrew Burgess2-5/+9
Resolve all of the duplicate test names in the gdb.threads/*.exp set of tests (that I see). Nothing very exciting here, mostly either giving tests explicit testnames, or adding with_test_prefix. The only interesting one is gdb.threads/execl.exp, I believe the duplicate test name was caused by an actual duplicate test. I've remove the simpler form of the test. I don't believe we've lost any test coverage with this change. gdb/testsuite/ChangeLog: * gdb.threads/execl.exp: Remove duplicate 'info threads' test. Make use of $gdb_test_name instead of creating a separate $test variable. * gdb.threads/print-threads.exp: Add a with_test_prefix instead of adding a '($name)' at the end of each test. This also catches the one place where '($name)' was missing, and so caused a duplicate test name. * gdb.threads/queue-signal.exp: Give tests unique names to avoid duplicate test names based on the command being tested. * gdb.threads/signal-command-multiple-signals-pending.exp: Likewise. * lib/gdb.exp (gdb_compile_shlib_pthreads): Tweak test name to avoid duplicate testnames when a test script uses this proc and also gdb_compile_pthreads. * lib/prelink-support.exp (build_executable_own_libs): Use with_test_prefix to avoid duplicate test names when we call build_executable twice.
2021-03-06Avoid crash on missing dwz fileTom Tromey1-2/+2
If DWARF contains a reference to a "dwz" file, but there is no .gnu_debugaltlink section, then gdb will crash. This happens because dwarf2_get_dwz_file will return NULL, but some callers do not expect this. This patch changes dwarf2_get_dwz_file so that callers can require a dwz file. Then, it updates the callers that are attempting to process references to the dwz file to require one. This includes a new testcase. The dwarf.exp changes don't handle the new forms exactly correctly -- they are only handled well enough to let this test case complete. gdb/ChangeLog 2021-03-06 Tom Tromey <tom@tromey.com> * dwarf2/read.h (dwarf2_get_dwz_file): Add 'require' parameter. * dwarf2/read.c (dwarf2_get_dwz_file): Add 'require' parameter. (get_abbrev_section_for_cu, read_attribute_value) (get_debug_line_section): Update. * dwarf2/macro.c (dwarf_decode_macro_bytes): Update. gdb/testsuite/ChangeLog 2021-03-06 Tom Tromey <tom@tromey.com> * lib/dwarf.exp (_handle_DW_FORM): Treat DW_FORM_GNU_ref_alt and DW_FORM_GNU_strp_alt like DW_FORM_sec_offset. * gdb.dwarf2/dwznolink.exp: New file.
2021-03-06Make valgrind tests more robust by adding --wait=1 to vgdb invocationMark Wielaard1-1/+1
On my setup some valgrind tests failed somewhat reliably because the target remote | vgdb command couldn't find the vgdb-pipe files because valgrind startup hadn't finished yet. I tried to fix this by replacing the "Memcheck, a memory error detector" match to "TO DEBUG THIS PROCESS USING GDB: start GDB like this" which is right before valgrind creates the vgdb-pipe files. But even that didn't guarantee that the vgdb-pipe files were there (maybe valgrind should print that text after it has created them?). But also not all tests use --vgdb-error=0, so the text isn't always printed. To make the tests reliable I added --wait=1 to the vgdb invocation. That tells vgdb to try to find the vgdb-pipe files, and if they aren't there yet, to wait 1 second and try again. gdb/testsuite/ChangeLog: * lib/valgrind.exp (vgdb_start): Add --wait=1 to vgdbcmd.
2021-03-03testsuite: extend nopie handling to add -fno-pie to compiler flagsMarkus Metzger1-4/+11
Some older GCC, e.g. 7.5.0 on Ubuntu 18.04 need -fno-pie to be passed to the compiler in addition to -no-pie to be passed to the linker for non-pie code generation. The gdb,nopie_flag is already documented as getting passed to the compiler, not the linker. Use that for the new -fno-pie compiler flag and add a new gdb,nopie_ldflag for the existing -no-pie linker flag. CAUTION: this might break existing board files that specify gdb,nopie_flag. Affected board files need to rename gdb,nopie_flag into gdb,nopie_ldflag.
2021-02-26Minor fix in skip_ctf_testsTom Tromey1-1/+3
I noticed an oddity in skip_ctf_tests -- for me it ends up caching the string "!0", because it ends with 'return ![...]'. In Tcl, this is just string concatenation. The result works because the users of this function have unbraced if conditions, like: if [skip_ctf_tests] { ... which works because "if" re-parses the returned string as an expression, and evaluates that. There's only a latent bug here, but this is also un-idiomatic, so I am checking in this patch to fix it. This way, if someone in the future uses a braced condition (which is what I normally recommend), it will continue to work. gdb/testsuite/ChangeLog 2021-02-26 Tom Tromey <tom@tromey.com> * lib/gdb.exp (skip_ctf_tests): Use expr on result.
2021-02-26testsuite: note on use_gdb_stub usageMarkus Metzger1-0/+3
Add a note to the comment on use_gdb_stub explaining the use of this check for skipping tests that spawn new inferiors as discussed here: https://sourceware.org/pipermail/gdb-patches/2020-December/174186.html
2021-02-11gdb: Remove arm-symbianelf supportAlan Modra2-13/+0
Since it has gone from bfd/. * arm-symbian-tdep.c: Delete. * NEWS: Mention arm-symbian removal. * Makefile.in: Remove arm-symbian-tdep entries. * configure.tgt: Remove arm*-*-symbianelf*. * doc/gdb.texinfo: Remove mention of SymbianOS. * osabi.c (gdb_osabi_names): Remove "Symbian". * osabi.h (enum gdb_osabi): Remove GDB_OSABI_SYMBIAN. * testsuite/gdb.base/ending-run.exp: Remove E32Main handling. * testsuite/gdb.ada/catch_ex_std.exp: Remove arm*-*-symbianelf* handling. * testsuite/gdb.base/dup-sect.exp: Likewise. * testsuite/gdb.base/long_long.exp: Likewise. * testsuite/gdb.base/solib-weak.exp: Likewise. * testsuite/gdb.guile/scm-section-script.exp: Likewise. * testsuite/gdb.python/py-section-script.exp: Likewise. * testsuite/lib/dwarf.exp: Likewise. * testsuite/lib/gdb.exp: Likewise.
2021-02-10[gdb/testsuite] Fix tcl ERROR in gdb_load_no_complaintsTom de Vries1-3/+0
In commit cf2b2075299 "[gdb/symtab] Fix element type modification in read_array_type" I factored out new proc with_complaints out of proc gdb_load_no_complaints, but when fixing a rebase conflict pre-commit I made a mistake in gdb_load_no_complaints that is now causing: ... ERROR: tcl error sourcing dw2-ranges-psym.exp. ERROR: can't read "save": no such variable while executing "gdb_test_no_output "set complaints $save" """ (procedure "gdb_load_no_complaints" line 14) invoked from within "gdb_load_no_complaints $binfile" ... Fix this by removing the offending line. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2021-02-10 Tom de Vries <tdevries@suse.de> * lib/gdb.exp (gdb_load_no_complaints): Remove unnecessary "Restore saved setting of complaints".
2021-02-09[gdb/symtab] Fix element type modification in read_array_typeTom de Vries1-10/+33
When running test-case gdb.fortran/function-calls.exp with target board unix/gdb:debug_flags=-gdwarf-5, I run into: ... (gdb) PASS: gdb.fortran/function-calls.exp: \ p derived_types_and_module_calls::pass_cart(c) p derived_types_and_module_calls::pass_cart_nd(c_nd)^M ^M Program received signal SIGSEGV, Segmentation fault.^M 0x0000000000400f73 in derived_types_and_module_calls::pass_cart_nd \ (c=<error reading variable: Cannot access memory at address 0xc>) at \ function-calls.f90:130^M 130 pass_cart_nd = ubound(c%d,1,4)^M The program being debugged was signaled while in a function called from GDB.^M GDB has restored the context to what it was before the call.^M To change this behavior use "set unwindonsignal off".^M Evaluation of the expression containing the function^M (derived_types_and_module_calls::pass_cart_nd) will be abandoned.^M (gdb) FAIL: gdb.fortran/function-calls.exp: p ... The problem originates in read_array_type, when reading a DW_TAG_array_type with a dwarf-5 DW_TAG_generic_subrange child. This is not supported, and the fallout of this is that rather than constructing a new array type, the code proceeds to modify the element type. Fix this conservatively by issuing a complaint and bailing out in read_array_type when not being able to construct an array type, such that we have: ... (gdb) maint expand-symtabs function-calls.f90^M During symbol reading: unable to find array range \ - DIE at 0xe1e [in module function-calls]^M During symbol reading: unable to find array range \ - DIE at 0xe1e [in module function-calls]^M (gdb) KFAIL: gdb.fortran/function-calls.exp: no complaints in srcfile \ (PRMS: symtab/27388) ... Tested on x86_64-linux. gdb/ChangeLog: 2021-02-09 Tom de Vries <tdevries@suse.de> PR symtab/27341 * dwarf2/read.c (read_array_type): Return NULL when not being able to construct an array type. Add assert to ensure that element_type is not being modified. gdb/testsuite/ChangeLog: 2021-02-09 Tom de Vries <tdevries@suse.de> PR symtab/27341 * lib/gdb.exp (with_complaints): New proc, factored out of ... (gdb_load_no_complaints): ... here. * gdb.fortran/function-calls.exp: Add test-case.
2021-02-08gdb/testsuite: fix implementation of delete line in tuiterm.expAndrew Burgess1-17/+32
The implementation of the delete line escape sequence in tuiterm.exp was wrong. Delete should take a count and then delete COUNT lines at the current cursor location, all remaining lines in the scroll region are moved up to replace the deleted lines, with blank lines being added at the end of the scroll region. It's not clear to me what "scroll region" means here (or at least how that is defined), but for now I'm just treating the whole screen as the scroll region, which seems to work fine. In contrast the current broken implementation deletes COUNT lines at the cursor location moving the next COUNT lines up to fill the gap. The rest of the screen is then cleared. gdb/testsuite/ChangeLog: * gdb.tui/scroll.exp: New file. * gdb.tui/tui-layout-asm-short-prog.exp: Update expected results. * lib/tuiterm.exp (Term::_csi_M): Delete count lines, scroll remaining lines up. (Term::check_region_contents): New proc. (Term::check_box_contents): Use check_region_contents.
2021-02-02gdb/testsuite: add test for .debug_{rng,loc}lists section without offset arraySimon Marchi1-10/+38
It is possible for the tables in the .debug_{rng,loc}lists sections to not have an array of offsets. In that case, the offset_entry_count field of the header is 0. The forms DW_FORM_{rng,loc}listx (reference by index) can't be used with that table. Instead, the DW_FORM_sec_offset form, which references a {rng,loc}list by direct offset in the section, must be used. From what I saw, this is what GCC currently produces. Add tests for this case. I didn't see any bug related to this, I just think that it would be nice to have coverage for this. A new `-with-offset-array` option is added to the `table` procs, used when generating {rng,loc}lists, to decide whether to generate the offset array. gdb/testsuite/ChangeLog: * lib/dwarf.exp (rnglists): Add -no-offset-array option to table proc. * gdb.dwarf2/rnglists-sec-offset.exp: Add test for .debug_rnglists table without offset array. * gdb.dwarf2/loclists-sec-offset.exp: Add test for .debug_loclists table without offset array. Change-Id: I8e34a7bf68c9682215ffbbf66600da5b7db91ef7
2021-02-02gdb/testsuite: add .debug_loclists testsSimon Marchi1-0/+196
Add tests for the various issues fixed in the previous patches. Add a new "loclists" procedure to the DWARF assembler, to allow generating .debug_loclists sections. gdb/testsuite/ChangeLog: PR gdb/26813 * lib/dwarf.exp (_handle_DW_FORM): Handle DW_FORM_loclistx. (loclists): New proc. * gdb.dwarf2/loclists-multiple-cus.c: New. * gdb.dwarf2/loclists-multiple-cus.exp: New. * gdb.dwarf2/loclists-sec-offset.c: New. * gdb.dwarf2/loclists-sec-offset.exp: New. Change-Id: I209bcb2a9482762ae943e518998d1f7761f76928
2021-02-02gdb/testsuite: DWARF assembler: add context parameters to _locationSimon Marchi1-13/+27
The _location proc is used to assemble a location description. It needs to know some contextual information: - size of an address - size of an offset (into another DWARF section) - DWARF version It currently get all this directly from global variables holding the compilation unit information. This is fine because as of now, all location descriptions are generated in the context of creating a compilation unit. However, a subsequent patch will generate location descriptions while generating a .debug_loclists section. _location should therefore no longer rely on the current compilation unit's properties. Change it to accept these values as parameters instead of accessing the values for the CU. No functional changes intended. gdb/testsuite/ChangeLog: * lib/dwarf.exp (_location): Add parameters. (_handle_DW_FORM): Adjust. Change-Id: Ib94981979c83ffbebac838081d645ad71c221637
2021-02-02gdb/testsuite: add .debug_rnglists testsSimon Marchi1-3/+184
Add tests for the various issues fixed in the previous patches. Add a new "rnglists" procedure to the DWARF assembler, to allow generating .debug_rnglists sections. A trivial change is required to support the DWARF 5 CU header layout. gdb/testsuite/ChangeLog: PR gdb/26813 * lib/dwarf.exp (_handle_DW_FORM): Handle DW_FORM_rnglistx. (cu): Generate header for DWARF 5. (rnglists): New proc. * gdb.dwarf2/rnglists-multiple-cus.exp: New. * gdb.dwarf2/rnglists-sec-offset.exp: New. Change-Id: I5b297e59c370c60cf671dec19796a6c3b9a9f632
2021-01-28gdb/testsuite: unset XDG_CONFIG_HOMEAndrew Burgess1-0/+7
Since this commit: commit 64aaad6349d2b2c45063a5383f877ce9a3a0c354 Date: Fri Sep 25 14:50:56 2020 +0100 gdb: use get_standard_config_dir when looking for .gdbinit GDB has been checking for ${XDG_CONFIG_HOME}/gdb/gdbinit on startup. Most tests pass -nx to GDB to block loading of gdbinit files, but there are a few tests (e.g. gdb.base/gdbinit-history.exp) that don't use -nx and instead setup a fake HOME directory containing a gdbinit file. However, since the above commit, if XDG_CONFIG_HOME is set then once -nx is no longer being passed GDB will load any gdbinit file it finds in that directory, which could cause the test to fail. As a concrete example: $ mkdir -p fake_xdg_config_home/gdb/ $ cat <<EOF >fake_xdg_config_home/gdb/gdbinit echo goodbye\n quit EOF $ export XDG_CONFIG_HOME=$PWD/fake_xdg_config_home $ make check-gdb TESTS="gdb.base/gdbinit-history.exp" Should result in the test failing. The solution I propose is to unset XDG_CONFIG_HOME in default_gdb_init, we already unset a bunch of environment variables in this proc. gdb/testsuite/ChangeLog: * lib/gdb.exp (default_gdb_init): Unset XDG_CONFIG_HOME.
2021-01-25[gdb/symtab] Handle DW_AT_ranges with DW_FORM_sec_off in partial DIETom de Vries1-0/+36
While looking into a failure in gdb.go/package.exp with gcc-11, I noticed that gdb shows some complaints when loading the executable (also with gcc-10, where the test-case passes): ... $ gdb -batch -iex "set complaints 100" package.10 -ex start During symbol reading: Attribute value is not a constant (DW_FORM_sec_offset) Temporary breakpoint 1 at 0x402ae6: file gdb.go/package1.go, line 8. During symbol reading: Attribute value is not a constant (DW_FORM_sec_offset) During symbol reading: Invalid .debug_rnglists data (no base address) ... Fix this by using as_unsigned () to read DW_AT_ranges in the partial DIE reader, similar to how that is done in dwarf2_get_pc_bounds. Tested on x86_64-linux. gdb/ChangeLog: 2021-01-25 Bernd Edlinger <bernd.edlinger@hotmail.de> Simon Marchi <simon.marchi@polymtl.ca> Tom de Vries <tdevries@suse.de> * dwarf2/read.c (partial_die_info::read): Use as_unsigned () for DW_AT_ranges. gdb/testsuite/ChangeLog: 2021-01-25 Tom de Vries <tdevries@suse.de> * gdb.dwarf2/dw2-ranges-psym.exp (gdb_load_no_complaints): New proc. * lib/gdb.exp: Use gdb_load_no_complaints.
2021-01-23Disable bracketed paste mode in GDB testsTom Tromey1-7/+8
I have a patch to import GNU readline 8.1 into GDB. However, when running the tests, there were a number of failures due to "bracketed paste mode". This is a terminal feature that readline 8.1 enables by default. The simplest way to work around this was to always make a ".inputrc" for GDB tests that will tell readline to disable brackted paste mode. gdb/testsuite/ChangeLog 2021-01-23 Tom Tromey <tom@tromey.com> * lib/gdb.exp (default_gdb_init): Set INPUTRC to a cached file.
2021-01-22gdb/testsuite: eliminate gdb_suppress_tests mechanismSimon Marchi3-139/+6
There is a lot of support code for the test suppression mechanism. But as far as I know, it is not useful. The gdb_suppress_tests proc is in fact disabled with this comment that has been there since forever: return; # fnf - disable pending review of results where # testsuite ran better without this I suggest to just remove everything related to test suppression, that removes some unnecessary complexity from the support code and the tests. gdb/testsuite/ChangeLog: * lib/gdb.exp (gdb_test_multiple): Remove things related to test suppression. (default_gdb_exit): Likewise. (default_gdb_spawn): Likewise. (send_gdb): Likewise. (gdb_expect): Likewise. (gdb_expect_list): Likewise. (default_gdb_init): Likewise. (gdb_suppress_entire_file): Remove. (gdb_suppress_tests): Remove. (gdb_stop_suppressing_tests): Remove. (gdb_clear_suppressed): Remove. * lib/mi-support.exp (mi_uncatched_gdb_exit): Remove things related to test suppression. (default_mi_gdb_start): Likewise. (mi_gdb_reinitialize_dir): Likewise. (mi_gdb_test): Likewise. (mi_run_cmd_full): Likewise. (mi_runto_helper): Likewise. (mi_execute_to): Likewise. * lib/prompt.exp (default_prompt_gdb_start): Likewise. * gdb.base/bitfields.exp: Likewise. * gdb.base/bitfields2.exp: Likewise. * gdb.base/break.exp: Likewise. * gdb.base/call-sc.exp: Likewise. * gdb.base/callfuncs.exp: Likewise. * gdb.base/dfp-test.exp: Likewise. * gdb.base/endian.exp: Likewise. * gdb.base/exprs.exp: Likewise. * gdb.base/funcargs.exp: Likewise. * gdb.base/hbreak2.exp: Likewise. * gdb.base/recurse.exp: Likewise. * gdb.base/scope.exp: Likewise. * gdb.base/sepdebug.exp: Likewise. * gdb.base/structs.exp: Likewise. * gdb.base/until.exp: Likewise. * gdb.cp/misc.exp: Likewise. Change-Id: Ie6d3025091691ba72010faa28b85ebd417b738f7
2021-01-22gdb: add new version styleAndrew Burgess1-0/+1
This commit adds a new 'version' style, which replaces the hard coded styling currently used for GDB's version string. GDB's version number is displayed: 1. In the output of 'show version', and 2. When GDB starts up (without the --quiet option). This new style can only ever affect the first of these two cases as the second case is printed before GDB has processed any initialization files, or processed any GDB commands passed on the command line. However, because the first case exists I think this commit makes sense, it means the style is no longer hard coded into GDB, and we can add some tests that the style can be enabled/disabled correctly. This commit is an alternative to a patch Tom posted here: https://sourceware.org/pipermail/gdb-patches/2020-June/169820.html I've used the style name 'version' instead of 'startup' to reflect what the style is actually used for. If other parts of the startup text end up being highlighted I imagine they would get their own styles based on what is being highlighted. I feel this is more inline with the other style names that are already in use within GDB. I also decoupled adding this style from the idea of startup options, and the possibility of auto-saving startup options. Those ideas can be explored in later patches. This commit should probably be considered only a partial solution to issue PR cli/25956. The colours of the style are no longer hard coded, however, it is still impossible to change the styling of the version string displayed during startup, so in one sense, the styling of that string is still "hard coded". A later patch will hopefully extend GDB to allow it to adjust the version styling before the initial version string is printed. gdb/ChangeLog: PR cli/25956 * cli/cli-style.c: Add 'cli/cli-setshow.h' include. (version_style): Define. (cli_style_option::cli_style_option): Add intensity parameter, and use as appropriate. (_initialize_cli_style): Register version style set/show commands. * cli/cli-style.h (cli_style_option): Add intensity parameter. (version_style): Declare. * top.c (print_gdb_version): Use version_stype, and styled_string to print the GDB version string. gdb/doc/ChangeLog: PR cli/25956 * gdb.texinfo (Output Styling): Document version style. gdb/testsuite/ChangeLog: PR cli/25956 * gdb.base/style.exp (run_style_tests): Add version string test. (test_startup_version_string): Use version style name. * lib/gdb-utils.exp (style): Handle version style name.
2021-01-22gdb: add remote_debug_printfSimon Marchi1-5/+3
This is the next in the new-style debug macro series. For this one, I decided to omit the function name from the "Sending packet" / "Packet received" kind of prints, just because it's not very useful in that context and hinders readability more than anything else. This is completely arbitrary. This is with: [remote] putpkt_binary: Sending packet: $qTStatus#49... [remote] getpkt_or_notif_sane_1: Packet received: T0;tnotrun:0;tframes:0;tcreated:0;tfree:500000;tsize:500000;circular:0;disconn:0;starttime:0;stoptime:0;username:;notes:: and without: [remote] Sending packet: $qTStatus#49... [remote] Packet received: T0;tnotrun:0;tframes:0;tcreated:0;tfree:500000;tsize:500000;circular:0;disconn:0;starttime:0;stoptime:0;username:;notes:: A difference is that previously, the query packet and its reply would be printed on the same line, like this: Sending packet: $qTStatus#49...Packet received: T0;tnotrun:0;tframes:0;tcreated:0;tfree:500000;tsize:500000;circular:0;disconn:0;starttime:0;stoptime:0;username:;notes:: Now, they are printed on two lines, since each remote_debug_printf{,_nofunc} prints its own complete message including an end of line. It's probably a matter of taste, but I prefer the two-line version, it's easier to follow, especially when the query packet is long. As a result, lib/range-stepping-support.exp needs to be updated, as it currently expects the vCont packet and the reply to be on the same line. I think it's sufficient in that context to just expect the vCont packet and not the reply, since the goal is just to count how many vCont;r GDB sends. gdb/ChangeLog: * remote.h (remote_debug_printf): New. (remote_debug_printf_nofunc): New. (REMOTE_SCOPED_DEBUG_ENTER_EXIT): New. * remote.c: Use above macros throughout file. gdbsupport/ChangeLog: * common-debug.h (debug_prefixed_printf_cond_nofunc): New. * common-debug.c (debug_prefixed_vprintf): Handle a nullptr func. gdb/testsuite/ChangeLog: * lib/range-stepping-support.exp (exec_cmd_expect_vCont_count): Adjust to "set debug remote" changes. Change-Id: Ica6dead50d3f82e855c7d763f707cef74bed9fee
2021-01-21Handle additional connection errorLuis Machado1-0/+3
On Ubuntu 18.04/20.04 I was running into annoying timeouts for gdb.server/server-connect.exp. Those were caused by the ipv6 tests, because they were running into the "Cannot assign requested address" error, originated from the connect syscall. Improve this by handling this additional error in the testsuite library. It still fails for me, but at least it fails pretty quickly and doesn't make the testsuite run take longer. gdb/testsuite/ChangeLog: 2021-01-21 Luis Machado <luis.machado@linaro.org> * lib/gdbserver-support.exp (gdb_target_cmd_ext): Handle a new error message.
2021-01-21gdb/testsuite: improve logging in lib/tuiterm.expSimon Marchi1-171/+277
Here's a bonus patch that applies on top of the other two. While debugging TUI test cases, it's hard to know what exactly is happening in the little mind of the terminal emulator. Add some logging for all input processing. Right now I'm interested in seeing what happens to the cursor position, so made it so all operations log the "before" and "after" cursor position. It should help see if any operation is not behaving as expected, w.r.t. the cursor position. Here are some examples of the logging found in gdb.log with this patch applied: +++ Inserting string '+|' +++ Inserted char '+', cursor: (0, 79) -> (1, 0) +++ Inserted char '|', cursor: (1, 0) -> (1, 1) +++ Inserted string '+|', cursor: (0, 79) -> (1, 1) +++ Cursor Horizontal Absolute (80), cursor: (1, 1) -> (1, 79) In the last line, note that the argument is 80 and we move to 79, that's because the position in the argument to the control sequence is 1-based, while our indexing is 0-based. gdb/testsuite/ChangeLog: * lib/tuiterm.exp (_log, _log_cur): New, use throughout. Change-Id: Ibf570d4b2867729ce65bea8c193343a8a846170d
2021-01-20gdb/testsuite: rename _cur_x/_cur_y to _cur_col/_cur_row in lib/tuiterm.expSimon Marchi1-86/+90
I am having trouble remembering which of _cur_x/_cur_y is columns and which is rows, so renaming them helps. We already have _rows and _cols to represent the terminal size, so I think that makes sense to name the "_cur" variables accordingly. gdb/testsuite/ChangeLog: * lib/tuiterm.exp: Rename _cur_x/_cur_y to _cur_col/_cur_row. Change-Id: I6abd3cdfdb295d8abde12dcd5f0ae09f18f07967
2021-01-20gdb/testsuite: add links for handled control sequences in lib/tuiterm.expSimon Marchi1-9/+45
This code can be a bit cryptic for those who don't know terminal control sequences very well. This patch adds links for all the handled sequences, so it's easy to get some doc to follow the code. I linked to a VT510 manual, because I think it's well formatted and easy to read. There's only the repeat sequence (_csi_b) which I haven't found in it, it looks to be xterm-specific or something. I also tried to use the sequence names as they are in the manual. gdb/testsuite/ChangeLog: * lib/tuiterm.exp: Add links in comments. Change-Id: I670b947a238e5e9bcab7c476a20eb3c31cf2909d
2021-01-20[gdb/testsuite] Skip gdb.rust/*.exp for target board unix/-m32Tom de Vries1-1/+16
When running gdb.rust/*.exp with target board unix/-m32, we see: ... Running src/gdb/testsuite/gdb.rust/union.exp ... gdb compile failed, error: Unrecognized option: 'm' Running src/gdb/testsuite/gdb.rust/modules.exp ... gdb compile failed, error: Unrecognized option: 'm' Running src/gdb/testsuite/gdb.rust/unsized.exp ... gdb compile failed, error: Unrecognized option: 'm' Running src/gdb/testsuite/gdb.rust/simple.exp ... gdb compile failed, error: Unrecognized option: 'm' Running src/gdb/testsuite/gdb.rust/watch.exp ... gdb compile failed, error: Unrecognized option: 'm' Running src/gdb/testsuite/gdb.rust/traits.exp ... gdb compile failed, error: Unrecognized option: 'm' Running src/gdb/testsuite/gdb.rust/expr.exp ... Running src/gdb/testsuite/gdb.rust/rust-style.exp ... gdb compile failed, error: Unrecognized option: 'm' Running src/gdb/testsuite/gdb.rust/methods.exp ... gdb compile failed, error: Unrecognized option: 'm' Running src/gdb/testsuite/gdb.rust/generics.exp ... gdb compile failed, error: Unrecognized option: 'm' === gdb Summary === nr of expected passes 95 nr of untested testcases 9 ... Fix this by testing for -m32 in the target board multilib_flags in skip_rust_tests. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2021-01-20 Tom de Vries <tdevries@suse.de> * lib/gdb.exp (skip_rust_tests): Skip if multilib_flags contains -m32.
2021-01-12[gdb/testsuite] Add have_mpx in lib/gdb.expTom de Vries1-0/+52
The sources for the test-cases gdb.arch/i386-mpx*.exp contain have_mpx functions that test whether the processor supports mpx instructions. OTOH, the test-cases are compiled using -mmpx -fcheck-pointer-bounds, which instrument all functions with mpx instructions. So, the function that is supposed to test whether mpx instruction are supported contains mpx instructions, which is a bit odd. We could fix this by: - factoring out the have_mpx function into a single source file, and - compiling it without "-mmpx -fcheck-pointer-bounds". But having the mpx support test as part of the test-cases seems like an unnecessary complication that makes the test-cases more difficult to analyze, reason about and modify. So we go one step further and factor out the mpx support test in into a gdb_caching_proc. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2021-01-12 Tom de Vries <tdevries@suse.de> * gdb.arch/i386-mpx-call.c (have_mpx): Remove. (main): Remove call to have_mpx. * gdb.arch/i386-mpx-call.exp: Use have_mpx. * gdb.arch/i386-mpx-map.c (have_mpx): Remove. (main): Remote call to have_mpx. * gdb.arch/i386-mpx-map.exp: Use have_mpx. * gdb.arch/i386-mpx-sigsegv.c (have_mpx): Remove. (main): Remove call to have_mpx. * gdb.arch/i386-mpx-sigsegv.exp: Use have_mpx. * gdb.arch/i386-mpx-simple_segv.c (have_mpx): Remove. (main): Remove call to have_mpx. * gdb.arch/i386-mpx-simple_segv.exp: Use have_mpx. * gdb.arch/i386-mpx.c (have_mpx): Remove. (main): Remote call to have_mpx. * gdb.arch/i386-mpx.exp: Use have_mpx. * lib/gdb.exp (have_mpx): New proc.
2021-01-06gdb/testsuite: fix race in ↵Simon Marchi1-2/+21
gdb.threads/signal-while-stepping-over-bp-other-thread.exp Commit 3ec3145c5dd6 ("gdb: introduce scoped debug prints") updated some tests using "set debug infrun" to handle the fact that a debug print is now shown after the prompt, after an inferior stop. The same issue happens in gdb.threads/signal-while-stepping-over-bp-other-thread.exp. If I run it in a loop, it eventually fails like these other tests. The problem is that the testsuite expects to see $gdb_prompt followed by the end of the buffer. It happens that expect reads $gdb_prompt and the debug print at the same time, in which case the regexp never matches and we get a timeout. The fix is the same as was done in 3ec3145c5dd6, make the testsuite believe that the prompt is the standard GDB prompt followed by that debug print. Since that test uses gdb_test_sequence, and the expected prompt is in gdb_test_sequence, add a -prompt switch to gdb_test_sequence to override the prompt used for that call. gdb/testsuite/ChangeLog: * lib/gdb.exp (gdb_test_sequence): Accept -prompt switch. * gdb.threads/signal-while-stepping-over-bp-other-thread.exp: Pass prompt containing debug print to gdb_test_sequence. Change-Id: I33161c53ddab45cdfeadfd50b964f8dc3caa9729
2021-01-01Update copyright year range in all GDB filesJoel Brobecker49-49/+49
This commits the result of running gdb/copyright.py as per our Start of New Year procedure... gdb/ChangeLog Update copyright year range in copyright header of all GDB files.
2020-12-20[gdb/testsuite] Add save_target_board_infoTom de Vries1-19/+56
Add a proc save_target_board_info, similar to save_vars, such that we can do: ... save_target_board_info { multilib_flags } { global board set board [target_info name] unset_board_info multilib_flags set_board_info multilib_flags "$override_multilib_flags" ... } ... and use it in gdb_compile_shlib. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-12-20 Tom de Vries <tdevries@suse.de> * lib/gdb.exp (save_target_board_info): New proc. (gdb_compile_shlib): Use save_target_board_info.
2020-12-19[gdb/testsuite] Introduce supports_scalar_storage_order_attributeTom de Vries1-0/+46
Introduce support test procs: - supports_scalar_storage_order_attribute, and - supports_gnuc and use them in test-case gdb.base/endianity.exp. Tested on x86_64-linux with gcc-7.5.0, gcc-4.8.5, and clang 10.0.1. gdb/testsuite/ChangeLog: 2020-12-19 Tom de Vries <tdevries@suse.de> * lib/gdb.exp (supports_scalar_storage_order_attribute) (supports_gnuc): New proc. * gdb.base/endianity.exp: Define TEST_SSO. Eliminate test_compiler_info calls. Add unsupported message. * gdb.base/endianity.c: Use TEST_SSO.
2020-12-16[gdb/testsuite] Fix shlib compilation with target board unix/-pie/-fPIETom de Vries1-1/+38
When running test-case gdb.base/info-shared.exp with target board unix/-pie/-fPIE, we run into: ... spawn -ignore SIGHUP gcc -fno-stack-protector \ outputs/gdb.base/info-shared/info-shared-solib1.c.o \ -fdiagnostics-color=never -fPIC -shared -Wl,-soname,info-shared-solib1.so \ -lm -fPIE -pie -o outputs/gdb.base/info-shared/info-shared-solib1.so^M ld: Scrt1.o: in function `_start':^M start.S:104: undefined reference to `main'^M collect2: error: ld returned 1 exit status^M compiler exited with status 1 ... The intention of the -pie/-fPIE flags is to build and test PIE executables on platforms where that is not the default. However, the flags clash with the flags required to build shared libraries. Fix this by filtering out PIE-related flags out of the multilib_flags settings in compile_shared_lib. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-12-16 Tom de Vries <tdevries@suse.de> * lib/gdb.exp (gdb_compile_shlib_1): Factor out of ... (gdb_compile_shlib): ... here. Filter out PIE-related flags.
2020-12-14gdb/testsuite: fix typo in gdb_test_multiple docSimon Marchi1-1/+1
gdb/testsuite/ChangeLog: * lib/gdb.exp (gdb_test_multiple): Fix typo in doc. Change-Id: Ieb188b3382395ce951bfba5a5f25aaea0f89ebf9
generated by cgit v1.1 at 2025-09-22 03:43:03 +0000