* [PATCH v3 1/3] btrace: control memory access during replay
@ 2014-05-21 7:01 Markus Metzger
2014-05-21 7:01 ` [PATCH v3 3/3] btrace, vdso: add vdso target sections Markus Metzger
` (2 more replies)
0 siblings, 3 replies; 12+ messages in thread
From: Markus Metzger @ 2014-05-21 7:01 UTC (permalink / raw)
To: palves; +Cc: gdb-patches, Eli Zaretskii
The btrace record target does not trace data. We therefore do not allow
accessing read-write memory during replay.
In some cases, this might be useful to advanced users, though, who we assume
to know what they are doing.
Add a set|show command pair to turn this memory access restriction off.
CC: Eli Zaretskii <eliz@gnu.org>
2014-05-21 Markus Metzger <markus.t.metzger@intel.com>
* record-btrace.c (record_btrace_allow_memory_access): Remove.
(replay_memory_access_read_only, replay_memory_access_read_write)
(replay_memory_access_types, replay_memory_access)
(set_record_btrace_cmdlist, show_record_btrace_cmdlist)
(cmd_set_record_btrace, cmd_show_record_btrace)
(cmd_show_replay_memory_access): New.
(record_btrace_xfer_partial, record_btrace_insert_breakpoint)
(record_btrace_remove_breakpoint): Replace
record_btrace_allow_memory_access with replay_memory_access.
(_initialize_record_btrace): Add commands.
* NEWS: Announce it.
testsuite/
* gdb.btrace/data.exp: Test it.
doc/
* gdb.texinfo (Process Record and Replay): Document it.
---
gdb/NEWS | 4 ++
gdb/doc/gdb.texinfo | 22 ++++++++++
gdb/record-btrace.c | 88 ++++++++++++++++++++++++++++++++++-----
gdb/testsuite/gdb.btrace/data.exp | 10 ++++-
4 files changed, 112 insertions(+), 12 deletions(-)
diff --git a/gdb/NEWS b/gdb/NEWS
index b23c8a0..62e0adc 100644
--- a/gdb/NEWS
+++ b/gdb/NEWS
@@ -61,6 +61,10 @@ maint ada show ignore-descriptive-types
the user manual for more details on descriptive types and the intended
usage of this option.
+set record btrace replay-memory-access (read-only|read-write)
+show record btrace replay-memory-access
+ Control what memory accesses are allowed during replay.
+
* New features in the GDB remote stub, GDBserver
** New option --debug-format=option1[,option2,...] allows one to add
diff --git a/gdb/doc/gdb.texinfo b/gdb/doc/gdb.texinfo
index 6092ff4..b9e7964 100644
--- a/gdb/doc/gdb.texinfo
+++ b/gdb/doc/gdb.texinfo
@@ -6400,6 +6400,28 @@ results.
@item show record full memory-query
Show the current setting of @code{memory-query}.
+@kindex set record btrace
+The @code{btrace} record target does not trace data. As a
+convenience, when replaying, @value{GDBN} reads read-only memory off
+the live program directly, assuming that the addresses of the
+read-only areas don't change. This for example makes it possible to
+disassemble code while replaying, but not to print variables.
+In some cases, being able to inspect variables might be useful.
+You can use the following command for that:
+
+@item set record btrace replay-memory-access
+Control the behavior of the @code{btrace} recording method when
+accessing memory during replay. If @code{read-only} (the default),
+@value{GDBN} will only allow accesses to read-only memory.
+If @code{read-write}, @value{GDBN} will allow accesses to read-only
+and to read-write memory. Beware that the accessed memory corresponds
+to the live target and not necessarily to the current replay
+position.
+
+@kindex show record btrace
+@item show record btrace replay-memory-access
+Show the current setting of @code{replay-memory-access}.
+
@kindex info record
@item info record
Show various statistics about the recording depending on the recording
diff --git a/gdb/record-btrace.c b/gdb/record-btrace.c
index d768225..f43436d 100644
--- a/gdb/record-btrace.c
+++ b/gdb/record-btrace.c
@@ -42,8 +42,22 @@ static struct target_ops record_btrace_ops;
/* A new thread observer enabling branch tracing for the new thread. */
static struct observer *record_btrace_thread_observer;
-/* Temporarily allow memory accesses. */
-static int record_btrace_allow_memory_access;
+/* Memory access types used in set/show record btrace replay-memory-access. */
+static const char replay_memory_access_read_only[] = "read-only";
+static const char replay_memory_access_read_write[] = "read-write";
+static const char *const replay_memory_access_types[] =
+{
+ replay_memory_access_read_only,
+ replay_memory_access_read_write,
+ NULL
+};
+
+/* The currently allowed replay memory access type. */
+static const char *replay_memory_access = replay_memory_access_read_only;
+
+/* Command lists for "set/show record btrace". */
+static struct cmd_list_element *set_record_btrace_cmdlist;
+static struct cmd_list_element *show_record_btrace_cmdlist;
/* Print a record-btrace debug message. Use do ... while (0) to avoid
ambiguities when used in if statements. */
@@ -815,7 +829,8 @@ record_btrace_xfer_partial (struct target_ops *ops, enum target_object object,
struct target_ops *t;
/* Filter out requests that don't make sense during replay. */
- if (!record_btrace_allow_memory_access && record_btrace_is_replaying (ops))
+ if (replay_memory_access == replay_memory_access_read_only
+ && record_btrace_is_replaying (ops))
{
switch (object)
{
@@ -869,18 +884,19 @@ record_btrace_insert_breakpoint (struct target_ops *ops,
struct bp_target_info *bp_tgt)
{
volatile struct gdb_exception except;
- int old, ret;
+ const char *old;
+ int ret;
/* Inserting breakpoints requires accessing memory. Allow it for the
duration of this function. */
- old = record_btrace_allow_memory_access;
- record_btrace_allow_memory_access = 1;
+ old = replay_memory_access;
+ replay_memory_access = replay_memory_access_read_write;
ret = 0;
TRY_CATCH (except, RETURN_MASK_ALL)
ret = ops->beneath->to_insert_breakpoint (ops->beneath, gdbarch, bp_tgt);
- record_btrace_allow_memory_access = old;
+ replay_memory_access = old;
if (except.reason < 0)
throw_exception (except);
@@ -896,18 +912,19 @@ record_btrace_remove_breakpoint (struct target_ops *ops,
struct bp_target_info *bp_tgt)
{
volatile struct gdb_exception except;
- int old, ret;
+ const char *old;
+ int ret;
/* Removing breakpoints requires accessing memory. Allow it for the
duration of this function. */
- old = record_btrace_allow_memory_access;
- record_btrace_allow_memory_access = 1;
+ old = replay_memory_access;
+ replay_memory_access = replay_memory_access_read_write;
ret = 0;
TRY_CATCH (except, RETURN_MASK_ALL)
ret = ops->beneath->to_remove_breakpoint (ops->beneath, gdbarch, bp_tgt);
- record_btrace_allow_memory_access = old;
+ replay_memory_access = old;
if (except.reason < 0)
throw_exception (except);
@@ -1938,6 +1955,32 @@ cmd_record_btrace_start (char *args, int from_tty)
execute_command ("target record-btrace", from_tty);
}
+/* The "set record btrace" command. */
+
+static void
+cmd_set_record_btrace (char *args, int from_tty)
+{
+ cmd_show_list (set_record_btrace_cmdlist, from_tty, "");
+}
+
+/* The "show record btrace" command. */
+
+static void
+cmd_show_record_btrace (char *args, int from_tty)
+{
+ cmd_show_list (show_record_btrace_cmdlist, from_tty, "");
+}
+
+/* The "show record btrace replay-memory-access" command. */
+
+static void
+cmd_show_replay_memory_access (struct ui_file *file, int from_tty,
+ struct cmd_list_element *c, const char *value)
+{
+ fprintf_filtered (gdb_stdout, _("Replay memory access is %s.\n"),
+ replay_memory_access);
+}
+
void _initialize_record_btrace (void);
/* Initialize btrace commands. */
@@ -1950,6 +1993,29 @@ _initialize_record_btrace (void)
&record_cmdlist);
add_alias_cmd ("b", "btrace", class_obscure, 1, &record_cmdlist);
+ add_prefix_cmd ("btrace", class_support, cmd_set_record_btrace,
+ _("Set record options"), &set_record_btrace_cmdlist,
+ "set record btrace ", 0, &set_record_cmdlist);
+
+ add_prefix_cmd ("btrace", class_support, cmd_show_record_btrace,
+ _("Show record options"), &show_record_btrace_cmdlist,
+ "show record btrace ", 0, &show_record_cmdlist);
+
+ add_setshow_enum_cmd ("replay-memory-access", no_class,
+ replay_memory_access_types, &replay_memory_access, _("\
+Set what memory accesses are allowed during replay."), _("\
+Show what memory accesses are allowed during replay."),
+ _("Default is READ-ONLY.\n\n\
+The btrace record target does not trace data.\n\
+The memory therefore corresponds to the live target and not \
+to the current replay position.\n\n\
+When READ-ONLY, allow accesses to read-only memory during replay.\n\
+When READ-WRITE, allow accesses to read-only and read-write memory during \
+replay."),
+ NULL, cmd_show_replay_memory_access,
+ &set_record_btrace_cmdlist,
+ &show_record_btrace_cmdlist);
+
init_record_btrace_ops ();
add_target (&record_btrace_ops);
diff --git a/gdb/testsuite/gdb.btrace/data.exp b/gdb/testsuite/gdb.btrace/data.exp
index 64c5443..91d8d8b 100644
--- a/gdb/testsuite/gdb.btrace/data.exp
+++ b/gdb/testsuite/gdb.btrace/data.exp
@@ -40,6 +40,14 @@ gdb_test "reverse-step" ".*test\.4.*"
gdb_test "print glob" "unavailable\[^\\\r\\\n\]*"
gdb_test "print loc" "unavailable\[^\\\r\\\n\]*"
+# we can read memory if we explicitly allow it.
+gdb_test_no_output "set record btrace replay-memory-access read-write"
+gdb_test "print glob" "1"
+
+# we can't if we don't explicitly allow it.
+gdb_test_no_output "set record btrace replay-memory-access read-only"
+gdb_test "print glob" "unavailable\[^\\\r\\\n\]*"
+
# stop replaying and try again
-gdb_test "record goto end"
+gdb_test "record goto end" ".*main\.3.*"
gdb_test "print glob" "1"
--
1.8.3.1
^ permalink raw reply [flat|nested] 12+ messages in thread
* [PATCH v3 3/3] btrace, vdso: add vdso target sections
2014-05-21 7:01 [PATCH v3 1/3] btrace: control memory access during replay Markus Metzger
@ 2014-05-21 7:01 ` Markus Metzger
2014-05-21 9:55 ` Pedro Alves
2014-05-29 16:54 ` Pedro Alves
2014-05-21 7:02 ` [PATCH v3 2/3] test, gcore: move capture_command_output into lib/gdb.exp Markus Metzger
2014-05-21 9:55 ` [PATCH v3 1/3] btrace: control memory access during replay Pedro Alves
2 siblings, 2 replies; 12+ messages in thread
From: Markus Metzger @ 2014-05-21 7:01 UTC (permalink / raw)
To: palves; +Cc: gdb-patches
When loading symbols for the vdso, also add its sections to target_sections.
This fixes an issue with record btrace where vdso instructions could not be
disassembled during replay.
2014-05-21 Markus Metzger <markus.t.metzger@intel.com>
* symfile-mem.c (symbol_file_add_from_memory): Add BFD sections.
testsuite/
* gdb.btrace/vdso.c: New.
* gdb.btrace/vdso.exp: New.
---
gdb/symfile-mem.c | 18 +++++++++++++
gdb/testsuite/gdb.btrace/vdso.c | 30 ++++++++++++++++++++++
gdb/testsuite/gdb.btrace/vdso.exp | 53 +++++++++++++++++++++++++++++++++++++++
3 files changed, 101 insertions(+)
create mode 100644 gdb/testsuite/gdb.btrace/vdso.c
create mode 100644 gdb/testsuite/gdb.btrace/vdso.exp
diff --git a/gdb/symfile-mem.c b/gdb/symfile-mem.c
index 3f09c4d..b29421e 100644
--- a/gdb/symfile-mem.c
+++ b/gdb/symfile-mem.c
@@ -92,6 +92,7 @@ symbol_file_add_from_memory (struct bfd *templ, CORE_ADDR addr,
struct section_addr_info *sai;
unsigned int i;
struct cleanup *cleanup;
+ struct target_section *sections, *sections_end, *tsec;
if (bfd_get_flavour (templ) != bfd_target_elf_flavour)
error (_("add-symbol-file-from-memory not supported for this target"));
@@ -131,6 +132,23 @@ symbol_file_add_from_memory (struct bfd *templ, CORE_ADDR addr,
from_tty ? SYMFILE_VERBOSE : 0,
sai, OBJF_SHARED, NULL);
+ sections = NULL;
+ sections_end = NULL;
+
+ if (build_section_table (nbfd, §ions, §ions_end) == 0)
+ {
+ make_cleanup (xfree, sections);
+
+ /* Adjust the target section addresses by the load address. */
+ for (tsec = sections; tsec != sections_end; ++tsec)
+ {
+ tsec->addr += loadbase;
+ tsec->endaddr += loadbase;
+ }
+
+ add_target_sections (&nbfd, sections, sections_end);
+ }
+
/* This might change our ideas about frames already looked at. */
reinit_frame_cache ();
diff --git a/gdb/testsuite/gdb.btrace/vdso.c b/gdb/testsuite/gdb.btrace/vdso.c
new file mode 100644
index 0000000..e16a3c6
--- /dev/null
+++ b/gdb/testsuite/gdb.btrace/vdso.c
@@ -0,0 +1,30 @@
+/* This testcase is part of GDB, the GNU debugger.
+
+ Copyright 2014 Free Software Foundation, Inc.
+
+ Contributed by Intel Corp. <markus.t.metzger@intel.com>
+
+ This program is free software; you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation; either version 3 of the License, or
+ (at your option) any later version.
+
+ This program is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ GNU General Public License for more details.
+
+ You should have received a copy of the GNU General Public License
+ along with this program. If not, see <http://www.gnu.org/licenses/>. */
+
+#include <sys/time.h>
+
+int
+main (void)
+{
+ struct timeval tv;
+
+ gettimeofday (&tv, 0); /* main.1. */
+
+ return 0; /* main.2. */
+}
diff --git a/gdb/testsuite/gdb.btrace/vdso.exp b/gdb/testsuite/gdb.btrace/vdso.exp
new file mode 100644
index 0000000..34a5bf0
--- /dev/null
+++ b/gdb/testsuite/gdb.btrace/vdso.exp
@@ -0,0 +1,53 @@
+# This testcase is part of GDB, the GNU debugger.
+#
+# Copyright 2014 Free Software Foundation, Inc.
+#
+# Contributed by Intel Corp. <markus.t.metzger@intel.com>
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 3 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program. If not, see <http://www.gnu.org/licenses/>.
+#
+#
+# Test that we can access the vdso memory during replay for stepping.
+
+# check for btrace support
+if { [skip_btrace_tests] } { return -1 }
+
+# start inferior
+standard_testfile
+if [prepare_for_testing $testfile.exp $testfile $srcfile] {
+ return -1
+}
+if ![runto_main] {
+ return -1
+}
+
+# capture the disassembly of gettimeofday while live debugging
+set live_gettimeofday [capture_command_output "disassemble gettimeofday" ""]
+
+# trace the test code
+gdb_test_no_output "record btrace"
+gdb_test "next" "main\.2.*"
+
+with_test_prefix "replay" {
+ # capture the disassembly of gettimeofday while replaying
+ gdb_test "record goto begin" "main\.1.*"
+ set replay_gettimeofday [capture_command_output "disassemble gettimeofday" ""]
+
+ # the two disassemblys must be identical
+ if ![string compare $live_gettimeofday $replay_gettimeofday] {
+ pass "disassemble gettimeofday"
+ } else {
+ fail "disassemble gettimeofday"
+ }
+}
--
1.8.3.1
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH v3 3/3] btrace, vdso: add vdso target sections
2014-05-21 7:01 ` [PATCH v3 3/3] btrace, vdso: add vdso target sections Markus Metzger
@ 2014-05-21 9:55 ` Pedro Alves
2014-05-29 16:54 ` Pedro Alves
1 sibling, 0 replies; 12+ messages in thread
From: Pedro Alves @ 2014-05-21 9:55 UTC (permalink / raw)
To: Markus Metzger; +Cc: gdb-patches
On 05/21/2014 08:01 AM, Markus Metzger wrote:
> 2014-05-21 Markus Metzger <markus.t.metzger@intel.com>
>
> * symfile-mem.c (symbol_file_add_from_memory): Add BFD sections.
>
> testsuite/
> * gdb.btrace/vdso.c: New.
> * gdb.btrace/vdso.exp: New.
OK.
> + # the two disassemblys must be identical
"disassemblies", I think.
--
Pedro Alves
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH v3 3/3] btrace, vdso: add vdso target sections
2014-05-21 7:01 ` [PATCH v3 3/3] btrace, vdso: add vdso target sections Markus Metzger
2014-05-21 9:55 ` Pedro Alves
@ 2014-05-29 16:54 ` Pedro Alves
2014-05-29 17:03 ` Pedro Alves
1 sibling, 1 reply; 12+ messages in thread
From: Pedro Alves @ 2014-05-29 16:54 UTC (permalink / raw)
To: Markus Metzger; +Cc: gdb-patches
Hi Markus,
On 05/21/2014 08:01 AM, Markus Metzger wrote:
> When loading symbols for the vdso, also add its sections to target_sections.
>
> This fixes an issue with record btrace where vdso instructions could not be
> disassembled during replay.
>
> 2014-05-21 Markus Metzger <markus.t.metzger@intel.com>
>
> * symfile-mem.c (symbol_file_add_from_memory): Add BFD sections.
Unfortunately this caused regressions in break-interp.exp:
Running ../../../src/gdb/testsuite/gdb.base/break-interp.exp ...
ERROR: Process no longer exists
That is GDB crashing.
589fdceb99db9868e34bc976b7e234dbfaf327e2 is the first bad commit
commit 589fdceb99db9868e34bc976b7e234dbfaf327e2
Author: Markus Metzger <markus.t.metzger@intel.com>
Date: Wed Apr 2 09:54:11 2014 +0200
btrace, vdso: add vdso target sections
When loading symbols for the vdso, also add its sections to target_sections.
This fixes an issue with record btrace where vdso instructions could not be
disassembled during replay.
* symfile-mem.c (symbol_file_add_from_memory): Add BFD sections.
testsuite/
* gdb.btrace/vdso.c: New.
* gdb.btrace/vdso.exp: New.
Core was generated by `/home/pedro/gdb/mygit/build/gdb/testsuite/../../gdb/gdb -nw -nx -data-directory'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x0000000000647bce in exec_set_section_address (filename=0x27bb1f0 "/home/pedro/gdb/mygit/build/gdb/testsuite/gdb.base/break-interp-LDprelinkNOdebugNO", index=0,
address=139930618982856) at ../../src/gdb/exec.c:919
919 if (filename_cmp (filename, p->the_bfd_section->owner->filename) == 0
Setting up the environment for debugging gdb.
Breakpoint 1 at 0x7127ee: file ../../src/gdb/utils.c, line 806.
Breakpoint 2 at 0x4fca7c: file ../../src/gdb/cli/cli-cmds.c, line 219.
(top-gdb) bt
#0 0x0000000000647bce in exec_set_section_address (filename=0x27bb1f0 "/home/pedro/gdb/mygit/build/gdb/testsuite/gdb.base/break-interp-LDprelinkNOdebugNO", index=0,
address=139930618982856) at ../../src/gdb/exec.c:919
#1 0x000000000064b61d in objfile_relocate1 (objfile=0x27baf70, new_offsets=0x7fff536105a0) at ../../src/gdb/objfiles.c:819
#2 0x000000000064b673 in objfile_relocate (objfile=0x27baf70, new_offsets=0x7fff536105a0) at ../../src/gdb/objfiles.c:843
#3 0x000000000049eeb2 in svr4_relocate_main_executable () at ../../src/gdb/solib-svr4.c:2883
#4 0x000000000049ef55 in svr4_solib_create_inferior_hook (from_tty=0) at ../../src/gdb/solib-svr4.c:2927
#5 0x0000000000730b0e in solib_create_inferior_hook (from_tty=0) at ../../src/gdb/solib.c:1211
#6 0x00000000005e5345 in post_create_inferior (target=0xd02c00 <current_target>, from_tty=0) at ../../src/gdb/infcmd.c:443
#7 0x00000000005e5744 in run_command_1 (args=0x0, from_tty=1, tbreak_at_main=0) at ../../src/gdb/infcmd.c:628
#8 0x00000000005e57a0 in run_command (args=0x0, from_tty=1) at ../../src/gdb/infcmd.c:642
#9 0x00000000004f68b6 in do_cfunc (c=0x261b9e0, args=0x0, from_tty=1) at ../../src/gdb/cli/cli-decode.c:107
#10 0x00000000004f99aa in cmd_func (cmd=0x261b9e0, args=0x0, from_tty=1) at ../../src/gdb/cli/cli-decode.c:1886
#11 0x000000000070f7f2 in execute_command (p=0x250f393 "", from_tty=1) at ../../src/gdb/top.c:461
#12 0x0000000000610f0f in command_handler (command=0x250f390 "") at ../../src/gdb/event-top.c:438
#13 0x00000000006114c8 in command_line_handler (rl=0x2801b70 "run") at ../../src/gdb/event-top.c:635
#14 0x000000000077177a in rl_callback_read_char () at ../../src/readline/callback.c:220
#15 0x0000000000610a3d in rl_callback_read_char_wrapper (client_data=0x0) at ../../src/gdb/event-top.c:167
#16 0x0000000000610e21 in stdin_event_handler (error=0, client_data=0x0) at ../../src/gdb/event-top.c:378
#17 0x000000000060fa07 in handle_file_event (data=...) at ../../src/gdb/event-loop.c:768
#18 0x000000000060eee9 in process_event () at ../../src/gdb/event-loop.c:342
#19 0x000000000060ef8b in gdb_do_one_event () at ../../src/gdb/event-loop.c:394
#20 0x000000000060f000 in start_event_loop () at ../../src/gdb/event-loop.c:431
#21 0x0000000000610a6f in cli_command_loop (data=0x0) at ../../src/gdb/event-top.c:182
#22 0x0000000000606f09 in current_interp_command_loop () at ../../src/gdb/interps.c:350
#23 0x00000000006080ad in captured_command_loop (data=0x0) at ../../src/gdb/main.c:301
#24 0x0000000000604223 in catch_errors (func=0x608092 <captured_command_loop>, func_args=0x0, errstring=0x8e7001 "", mask=RETURN_MASK_ALL)
at ../../src/gdb/exceptions.c:524
#25 0x00000000006094b3 in captured_main (data=0x7fff53610d50) at ../../src/gdb/main.c:1097
#26 0x0000000000604223 in catch_errors (func=0x608345 <captured_main>, func_args=0x7fff53610d50, errstring=0x8e7001 "", mask=RETURN_MASK_ALL)
at ../../src/gdb/exceptions.c:524
#27 0x00000000006094dc in gdb_main (args=0x7fff53610d50) at ../../src/gdb/main.c:1105
#28 0x000000000045dbd7 in main (argc=5, argv=0x7fff53610e58) at ../../src/gdb/gdb.c:33
--
Pedro Alves
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH v3 3/3] btrace, vdso: add vdso target sections
2014-05-29 16:54 ` Pedro Alves
@ 2014-05-29 17:03 ` Pedro Alves
2014-06-02 8:20 ` Metzger, Markus T
2014-06-02 12:41 ` Metzger, Markus T
0 siblings, 2 replies; 12+ messages in thread
From: Pedro Alves @ 2014-05-29 17:03 UTC (permalink / raw)
To: Markus Metzger; +Cc: gdb-patches
On 05/29/2014 05:54 PM, Pedro Alves wrote:
> Hi Markus,
>
> On 05/21/2014 08:01 AM, Markus Metzger wrote:
>> When loading symbols for the vdso, also add its sections to target_sections.
>>
>> This fixes an issue with record btrace where vdso instructions could not be
>> disassembled during replay.
>>
>> 2014-05-21 Markus Metzger <markus.t.metzger@intel.com>
>>
>> * symfile-mem.c (symbol_file_add_from_memory): Add BFD sections.
>
> Unfortunately this caused regressions in break-interp.exp:
>
> Running ../../../src/gdb/testsuite/gdb.base/break-interp.exp ...
> ERROR: Process no longer exists
>
> That is GDB crashing.
>
> 589fdceb99db9868e34bc976b7e234dbfaf327e2 is the first bad commit
> commit 589fdceb99db9868e34bc976b7e234dbfaf327e2
> Author: Markus Metzger <markus.t.metzger@intel.com>
> Date: Wed Apr 2 09:54:11 2014 +0200
>
> btrace, vdso: add vdso target sections
>
> When loading symbols for the vdso, also add its sections to target_sections.
>
> This fixes an issue with record btrace where vdso instructions could not be
> disassembled during replay.
>
> * symfile-mem.c (symbol_file_add_from_memory): Add BFD sections.
>
> testsuite/
> * gdb.btrace/vdso.c: New.
> * gdb.btrace/vdso.exp: New.
>
>
> Core was generated by `/home/pedro/gdb/mygit/build/gdb/testsuite/../../gdb/gdb -nw -nx -data-directory'.
> Program terminated with signal SIGSEGV, Segmentation fault.
> #0 0x0000000000647bce in exec_set_section_address (filename=0x27bb1f0 "/home/pedro/gdb/mygit/build/gdb/testsuite/gdb.base/break-interp-LDprelinkNOdebugNO", index=0,
> address=139930618982856) at ../../src/gdb/exec.c:919
> 919 if (filename_cmp (filename, p->the_bfd_section->owner->filename) == 0
'p', a target section, points at garbage.
Hmm, wait, nothing is removing the vdso symbols target sections, like ever,
not even when the process dies, isn't it? I guess that's it.
--
Pedro Alves
^ permalink raw reply [flat|nested] 12+ messages in thread
* RE: [PATCH v3 3/3] btrace, vdso: add vdso target sections
2014-05-29 17:03 ` Pedro Alves
@ 2014-06-02 8:20 ` Metzger, Markus T
2014-06-02 9:43 ` Metzger, Markus T
2014-06-02 12:41 ` Metzger, Markus T
1 sibling, 1 reply; 12+ messages in thread
From: Metzger, Markus T @ 2014-06-02 8:20 UTC (permalink / raw)
To: Pedro Alves; +Cc: gdb-patches
Thanks for reporting this crash. I'll look into it. I thought I ran all tests
for each patch in the vdso series.
It seems btrace got broken, as well. I now get an assertion: "
to_execution_direction must be implemented ...". The trivial solution
of providing a to_execution_direction method that just returns
execution_direction does not seem to work - or there's another
bug underneath.
Regards,
Markus.
> -----Original Message-----
> From: Pedro Alves [mailto:palves@redhat.com]
> Sent: Thursday, May 29, 2014 7:04 PM
> To: Metzger, Markus T
> Cc: gdb-patches@sourceware.org
> Subject: Re: [PATCH v3 3/3] btrace, vdso: add vdso target sections
>
> On 05/29/2014 05:54 PM, Pedro Alves wrote:
> > Hi Markus,
> >
> > On 05/21/2014 08:01 AM, Markus Metzger wrote:
> >> When loading symbols for the vdso, also add its sections to
> target_sections.
> >>
> >> This fixes an issue with record btrace where vdso instructions could not be
> >> disassembled during replay.
> >>
> >> 2014-05-21 Markus Metzger <markus.t.metzger@intel.com>
> >>
> >> * symfile-mem.c (symbol_file_add_from_memory): Add BFD
> sections.
> >
> > Unfortunately this caused regressions in break-interp.exp:
> >
> > Running ../../../src/gdb/testsuite/gdb.base/break-interp.exp ...
> > ERROR: Process no longer exists
> >
> > That is GDB crashing.
> >
> > 589fdceb99db9868e34bc976b7e234dbfaf327e2 is the first bad commit
> > commit 589fdceb99db9868e34bc976b7e234dbfaf327e2
> > Author: Markus Metzger <markus.t.metzger@intel.com>
> > Date: Wed Apr 2 09:54:11 2014 +0200
> >
> > btrace, vdso: add vdso target sections
> >
> > When loading symbols for the vdso, also add its sections to
> target_sections.
> >
> > This fixes an issue with record btrace where vdso instructions could not
> be
> > disassembled during replay.
> >
> > * symfile-mem.c (symbol_file_add_from_memory): Add BFD sections.
> >
> > testsuite/
> > * gdb.btrace/vdso.c: New.
> > * gdb.btrace/vdso.exp: New.
> >
> >
> > Core was generated by
> `/home/pedro/gdb/mygit/build/gdb/testsuite/../../gdb/gdb -nw -nx -data-
> directory'.
> > Program terminated with signal SIGSEGV, Segmentation fault.
> > #0 0x0000000000647bce in exec_set_section_address
> (filename=0x27bb1f0
> "/home/pedro/gdb/mygit/build/gdb/testsuite/gdb.base/break-interp-
> LDprelinkNOdebugNO", index=0,
> > address=139930618982856) at ../../src/gdb/exec.c:919
> > 919 if (filename_cmp (filename, p->the_bfd_section->owner-
> >filename) == 0
>
> 'p', a target section, points at garbage.
>
> Hmm, wait, nothing is removing the vdso symbols target sections, like ever,
> not even when the process dies, isn't it? I guess that's it.
>
> --
> Pedro Alves
Intel GmbH
Dornacher Strasse 1
85622 Feldkirchen/Muenchen, Deutschland
Sitz der Gesellschaft: Feldkirchen bei Muenchen
Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk
Registergericht: Muenchen HRB 47456
Ust.-IdNr./VAT Registration No.: DE129385895
Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052
^ permalink raw reply [flat|nested] 12+ messages in thread
* RE: [PATCH v3 3/3] btrace, vdso: add vdso target sections
2014-06-02 8:20 ` Metzger, Markus T
@ 2014-06-02 9:43 ` Metzger, Markus T
0 siblings, 0 replies; 12+ messages in thread
From: Metzger, Markus T @ 2014-06-02 9:43 UTC (permalink / raw)
To: Pedro Alves; +Cc: gdb-patches
> -----Original Message-----
> From: Metzger, Markus T
> Sent: Monday, June 2, 2014 10:21 AM
> To: Pedro Alves
> Cc: gdb-patches@sourceware.org
> Subject: RE: [PATCH v3 3/3] btrace, vdso: add vdso target sections
>
> Thanks for reporting this crash. I'll look into it. I thought I ran all tests
> for each patch in the vdso series.
>
> It seems btrace got broken, as well. I now get an assertion: "
> to_execution_direction must be implemented ...". The trivial solution
> of providing a to_execution_direction method that just returns
> execution_direction does not seem to work - or there's another
> bug underneath.
Looks like btrace got broken when async was made default and btrace
did not support it. I took the async bits from record-full and now at
least the btrace tests are running again. I'll send the patch in a separate
email.
Regards,
Markus.
>
> Regards,
> Markus.
>
> > -----Original Message-----
> > From: Pedro Alves [mailto:palves@redhat.com]
> > Sent: Thursday, May 29, 2014 7:04 PM
> > To: Metzger, Markus T
> > Cc: gdb-patches@sourceware.org
> > Subject: Re: [PATCH v3 3/3] btrace, vdso: add vdso target sections
> >
> > On 05/29/2014 05:54 PM, Pedro Alves wrote:
> > > Hi Markus,
> > >
> > > On 05/21/2014 08:01 AM, Markus Metzger wrote:
> > >> When loading symbols for the vdso, also add its sections to
> > target_sections.
> > >>
> > >> This fixes an issue with record btrace where vdso instructions could not
> be
> > >> disassembled during replay.
> > >>
> > >> 2014-05-21 Markus Metzger <markus.t.metzger@intel.com>
> > >>
> > >> * symfile-mem.c (symbol_file_add_from_memory): Add BFD
> > sections.
> > >
> > > Unfortunately this caused regressions in break-interp.exp:
> > >
> > > Running ../../../src/gdb/testsuite/gdb.base/break-interp.exp ...
> > > ERROR: Process no longer exists
> > >
> > > That is GDB crashing.
> > >
> > > 589fdceb99db9868e34bc976b7e234dbfaf327e2 is the first bad commit
> > > commit 589fdceb99db9868e34bc976b7e234dbfaf327e2
> > > Author: Markus Metzger <markus.t.metzger@intel.com>
> > > Date: Wed Apr 2 09:54:11 2014 +0200
> > >
> > > btrace, vdso: add vdso target sections
> > >
> > > When loading symbols for the vdso, also add its sections to
> > target_sections.
> > >
> > > This fixes an issue with record btrace where vdso instructions could not
> > be
> > > disassembled during replay.
> > >
> > > * symfile-mem.c (symbol_file_add_from_memory): Add BFD
> sections.
> > >
> > > testsuite/
> > > * gdb.btrace/vdso.c: New.
> > > * gdb.btrace/vdso.exp: New.
> > >
> > >
> > > Core was generated by
> > `/home/pedro/gdb/mygit/build/gdb/testsuite/../../gdb/gdb -nw -nx -data-
> > directory'.
> > > Program terminated with signal SIGSEGV, Segmentation fault.
> > > #0 0x0000000000647bce in exec_set_section_address
> > (filename=0x27bb1f0
> > "/home/pedro/gdb/mygit/build/gdb/testsuite/gdb.base/break-interp-
> > LDprelinkNOdebugNO", index=0,
> > > address=139930618982856) at ../../src/gdb/exec.c:919
> > > 919 if (filename_cmp (filename, p->the_bfd_section->owner-
> > >filename) == 0
> >
> > 'p', a target section, points at garbage.
> >
> > Hmm, wait, nothing is removing the vdso symbols target sections, like ever,
> > not even when the process dies, isn't it? I guess that's it.
> >
> > --
> > Pedro Alves
Intel GmbH
Dornacher Strasse 1
85622 Feldkirchen/Muenchen, Deutschland
Sitz der Gesellschaft: Feldkirchen bei Muenchen
Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk
Registergericht: Muenchen HRB 47456
Ust.-IdNr./VAT Registration No.: DE129385895
Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052
^ permalink raw reply [flat|nested] 12+ messages in thread
* RE: [PATCH v3 3/3] btrace, vdso: add vdso target sections
2014-05-29 17:03 ` Pedro Alves
2014-06-02 8:20 ` Metzger, Markus T
@ 2014-06-02 12:41 ` Metzger, Markus T
2014-06-04 12:37 ` Metzger, Markus T
1 sibling, 1 reply; 12+ messages in thread
From: Metzger, Markus T @ 2014-06-02 12:41 UTC (permalink / raw)
To: Pedro Alves; +Cc: gdb-patches
> -----Original Message-----
> From: Pedro Alves [mailto:palves@redhat.com]
> Sent: Thursday, May 29, 2014 7:04 PM
> Hmm, wait, nothing is removing the vdso symbols target sections, like ever,
> not even when the process dies, isn't it? I guess that's it.
Yes, that seems to be it.
Target sections are typically owned by an so_list object and are removed
when the so_list object is removed.
Symfile target sections are owned by an objfile object and are removed
in a free_objfile observer in symfile.c. That observer only removes target
sections for OBJF_USERLOADED objfiles, though.
The vdso target sections are owned by the vdso BFD and are never removed.
When I change symfile_add_from_memory to create target sections like this:
add_target_sections_of_objfile (objf);
and further drop the restriction to only remove OBJF_USERLOADED objfiles in
symfile_free_objfile, the test passes.
diff --git a/gdb/symfile-mem.c b/gdb/symfile-mem.c
index b29421e..ef48f7d 100644
--- a/gdb/symfile-mem.c
+++ b/gdb/symfile-mem.c
@@ -92,7 +92,6 @@ symbol_file_add_from_memory (struct bfd *templ, CORE_ADDR addr,
struct section_addr_info *sai;
unsigned int i;
struct cleanup *cleanup;
- struct target_section *sections, *sections_end, *tsec;
if (bfd_get_flavour (templ) != bfd_target_elf_flavour)
error (_("add-symbol-file-from-memory not supported for this target"));
@@ -132,22 +131,7 @@ symbol_file_add_from_memory (struct bfd *templ, CORE_ADDR addr,
from_tty ? SYMFILE_VERBOSE : 0,
sai, OBJF_SHARED, NULL);
- sections = NULL;
- sections_end = NULL;
-
- if (build_section_table (nbfd, §ions, §ions_end) == 0)
- {
- make_cleanup (xfree, sections);
-
- /* Adjust the target section addresses by the load address. */
- for (tsec = sections; tsec != sections_end; ++tsec)
- {
- tsec->addr += loadbase;
- tsec->endaddr += loadbase;
- }
-
- add_target_sections (&nbfd, sections, sections_end);
- }
+ add_target_sections_of_objfile (objf);
/* This might change our ideas about frames already looked at. */
reinit_frame_cache ();
diff --git a/gdb/symfile.c b/gdb/symfile.c
index 64a83c6..caa0722 100644
--- a/gdb/symfile.c
+++ b/gdb/symfile.c
@@ -3893,7 +3893,7 @@ static void
symfile_free_objfile (struct objfile *objfile)
{
/* Remove the target sections of user-added objfiles. */
- if (objfile != 0 && objfile->flags & OBJF_USERLOADED)
+ if (objfile != NULL)
remove_target_sections ((void *) objfile);
}
Alternatively, I could add another OBJF_ flag and another free_objfile observer
to also remove the symfile-from-memory target sections.
Regards,
Markus.
Intel GmbH
Dornacher Strasse 1
85622 Feldkirchen/Muenchen, Deutschland
Sitz der Gesellschaft: Feldkirchen bei Muenchen
Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk
Registergericht: Muenchen HRB 47456
Ust.-IdNr./VAT Registration No.: DE129385895
Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052
^ permalink raw reply [flat|nested] 12+ messages in thread
* RE: [PATCH v3 3/3] btrace, vdso: add vdso target sections
2014-06-02 12:41 ` Metzger, Markus T
@ 2014-06-04 12:37 ` Metzger, Markus T
0 siblings, 0 replies; 12+ messages in thread
From: Metzger, Markus T @ 2014-06-04 12:37 UTC (permalink / raw)
To: Pedro Alves; +Cc: gdb-patches
Hi Pedro,
I sent this as a patch:
https://sourceware.org/ml/gdb-patches/2014-06/msg00148.html
There's also another patch series open that fixes an assertion when
generating a core file while replaying:
https://sourceware.org/ml/gdb-patches/2014-05/msg00537.html
https://sourceware.org/ml/gdb-patches/2014-05/msg00539.html
https://sourceware.org/ml/gdb-patches/2014-05/msg00538.html
regards,
markus.
> -----Original Message-----
> From: Metzger, Markus T
> Sent: Monday, June 2, 2014 2:41 PM
> To: Pedro Alves
> Cc: gdb-patches@sourceware.org
> Subject: RE: [PATCH v3 3/3] btrace, vdso: add vdso target sections
>
> > -----Original Message-----
> > From: Pedro Alves [mailto:palves@redhat.com]
> > Sent: Thursday, May 29, 2014 7:04 PM
>
>
> > Hmm, wait, nothing is removing the vdso symbols target sections, like ever,
> > not even when the process dies, isn't it? I guess that's it.
>
> Yes, that seems to be it.
>
> Target sections are typically owned by an so_list object and are removed
> when the so_list object is removed.
>
> Symfile target sections are owned by an objfile object and are removed
> in a free_objfile observer in symfile.c. That observer only removes target
> sections for OBJF_USERLOADED objfiles, though.
>
> The vdso target sections are owned by the vdso BFD and are never removed.
>
> When I change symfile_add_from_memory to create target sections like
> this:
>
> add_target_sections_of_objfile (objf);
>
> and further drop the restriction to only remove OBJF_USERLOADED objfiles
> in
> symfile_free_objfile, the test passes.
>
> diff --git a/gdb/symfile-mem.c b/gdb/symfile-mem.c
> index b29421e..ef48f7d 100644
> --- a/gdb/symfile-mem.c
> +++ b/gdb/symfile-mem.c
> @@ -92,7 +92,6 @@ symbol_file_add_from_memory (struct bfd *templ,
> CORE_ADDR addr,
> struct section_addr_info *sai;
> unsigned int i;
> struct cleanup *cleanup;
> - struct target_section *sections, *sections_end, *tsec;
>
> if (bfd_get_flavour (templ) != bfd_target_elf_flavour)
> error (_("add-symbol-file-from-memory not supported for this target"));
> @@ -132,22 +131,7 @@ symbol_file_add_from_memory (struct bfd *templ,
> CORE_ADDR addr,
> from_tty ? SYMFILE_VERBOSE : 0,
> sai, OBJF_SHARED, NULL);
>
> - sections = NULL;
> - sections_end = NULL;
> -
> - if (build_section_table (nbfd, §ions, §ions_end) == 0)
> - {
> - make_cleanup (xfree, sections);
> -
> - /* Adjust the target section addresses by the load address. */
> - for (tsec = sections; tsec != sections_end; ++tsec)
> - {
> - tsec->addr += loadbase;
> - tsec->endaddr += loadbase;
> - }
> -
> - add_target_sections (&nbfd, sections, sections_end);
> - }
> + add_target_sections_of_objfile (objf);
>
> /* This might change our ideas about frames already looked at. */
> reinit_frame_cache ();
> diff --git a/gdb/symfile.c b/gdb/symfile.c
> index 64a83c6..caa0722 100644
> --- a/gdb/symfile.c
> +++ b/gdb/symfile.c
> @@ -3893,7 +3893,7 @@ static void
> symfile_free_objfile (struct objfile *objfile)
> {
> /* Remove the target sections of user-added objfiles. */
> - if (objfile != 0 && objfile->flags & OBJF_USERLOADED)
> + if (objfile != NULL)
> remove_target_sections ((void *) objfile);
> }
>
> Alternatively, I could add another OBJF_ flag and another free_objfile
> observer
> to also remove the symfile-from-memory target sections.
>
> Regards,
> Markus.
Intel GmbH
Dornacher Strasse 1
85622 Feldkirchen/Muenchen, Deutschland
Sitz der Gesellschaft: Feldkirchen bei Muenchen
Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk
Registergericht: Muenchen HRB 47456
Ust.-IdNr./VAT Registration No.: DE129385895
Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052
^ permalink raw reply [flat|nested] 12+ messages in thread
* [PATCH v3 2/3] test, gcore: move capture_command_output into lib/gdb.exp
2014-05-21 7:01 [PATCH v3 1/3] btrace: control memory access during replay Markus Metzger
2014-05-21 7:01 ` [PATCH v3 3/3] btrace, vdso: add vdso target sections Markus Metzger
@ 2014-05-21 7:02 ` Markus Metzger
2014-05-21 9:55 ` Pedro Alves
2014-05-21 9:55 ` [PATCH v3 1/3] btrace: control memory access during replay Pedro Alves
2 siblings, 1 reply; 12+ messages in thread
From: Markus Metzger @ 2014-05-21 7:02 UTC (permalink / raw)
To: palves; +Cc: gdb-patches
Allow gcore's capture_command_output function to be used by other tests.
2014-05-21 Markus Metzger <markus.t.metzger@intel.com>
testsuite/
* gdb.base/gcore.exp (capture_command_output): Move ...
* lib/gdb.exp (capture_command_output): ... here.
---
gdb/testsuite/gdb.base/gcore.exp | 13 -------------
gdb/testsuite/lib/gdb.exp | 14 ++++++++++++++
2 files changed, 14 insertions(+), 13 deletions(-)
diff --git a/gdb/testsuite/gdb.base/gcore.exp b/gdb/testsuite/gdb.base/gcore.exp
index 99743a0..c28a9b3 100644
--- a/gdb/testsuite/gdb.base/gcore.exp
+++ b/gdb/testsuite/gdb.base/gcore.exp
@@ -41,19 +41,6 @@ if { ! [ runto_main ] } then {
return -1
}
-proc capture_command_output { command prefix } {
- global gdb_prompt
- global expect_out
-
- set output_string ""
- gdb_test_multiple "$command" "capture_command_output for $command" {
- -re "${command}\[\r\n\]+${prefix}(.*)\[\r\n\]+$gdb_prompt $" {
- set output_string $expect_out(1,string)
- }
- }
- return $output_string
-}
-
gdb_test "break terminal_func" "Breakpoint .* at .*${srcfile}, line .*" \
"set breakpoint at terminal_func"
diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp
index 0fe6c31..22a43b6 100644
--- a/gdb/testsuite/lib/gdb.exp
+++ b/gdb/testsuite/lib/gdb.exp
@@ -4772,5 +4772,19 @@ proc parse_args { argset } {
# number of items expected to be passed into the procedure...
}
+# Capture the output of COMMAND in a string ignoring PREFIX; return that string.
+proc capture_command_output { command prefix } {
+ global gdb_prompt
+ global expect_out
+
+ set output_string ""
+ gdb_test_multiple "$command" "capture_command_output for $command" {
+ -re "${command}\[\r\n\]+${prefix}(.*)\[\r\n\]+$gdb_prompt $" {
+ set output_string $expect_out(1,string)
+ }
+ }
+ return $output_string
+}
+
# Always load compatibility stuff.
load_lib future.exp
--
1.8.3.1
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH v3 1/3] btrace: control memory access during replay
2014-05-21 7:01 [PATCH v3 1/3] btrace: control memory access during replay Markus Metzger
2014-05-21 7:01 ` [PATCH v3 3/3] btrace, vdso: add vdso target sections Markus Metzger
2014-05-21 7:02 ` [PATCH v3 2/3] test, gcore: move capture_command_output into lib/gdb.exp Markus Metzger
@ 2014-05-21 9:55 ` Pedro Alves
2 siblings, 0 replies; 12+ messages in thread
From: Pedro Alves @ 2014-05-21 9:55 UTC (permalink / raw)
To: Markus Metzger; +Cc: gdb-patches, Eli Zaretskii
On 05/21/2014 08:01 AM, Markus Metzger wrote:
> The btrace record target does not trace data. We therefore do not allow
> accessing read-write memory during replay.
>
> In some cases, this might be useful to advanced users, though, who we assume
> to know what they are doing.
>
> Add a set|show command pair to turn this memory access restriction off.
>
Code bits are OK.
--
Pedro Alves
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2014-06-04 12:37 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-05-21 7:01 [PATCH v3 1/3] btrace: control memory access during replay Markus Metzger
2014-05-21 7:01 ` [PATCH v3 3/3] btrace, vdso: add vdso target sections Markus Metzger
2014-05-21 9:55 ` Pedro Alves
2014-05-29 16:54 ` Pedro Alves
2014-05-29 17:03 ` Pedro Alves
2014-06-02 8:20 ` Metzger, Markus T
2014-06-02 9:43 ` Metzger, Markus T
2014-06-02 12:41 ` Metzger, Markus T
2014-06-04 12:37 ` Metzger, Markus T
2014-05-21 7:02 ` [PATCH v3 2/3] test, gcore: move capture_command_output into lib/gdb.exp Markus Metzger
2014-05-21 9:55 ` Pedro Alves
2014-05-21 9:55 ` [PATCH v3 1/3] btrace: control memory access during replay Pedro Alves
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).