* PR25882, .gnu.attributes are not checked for shared libraries
@ 2020-05-01 5:54 Alan Modra
2020-05-01 22:23 ` Joseph Myers
0 siblings, 1 reply; 6+ messages in thread
From: Alan Modra @ 2020-05-01 5:54 UTC (permalink / raw)
To: binutils
This allows backend merge_private_bfd_data to examine shared library
e_flags and/or .gnu.attributes. ARM and PowerPC have done so when
using ld.gold for a long time.
(The tic6x change below is dead code due to the earlier FIXME,
but this is probably one of the changes needed there.)
PR 25882
bfd/
* elf32-tic6x.c (elf32_tic6x_merge_attributes): Don't transfer
Tag_ABI_PIC or Tag_ABI_PID from dynamic objects to the output.
ld/
* ldlang.c (lang_check): Call bfd_merge_private_bfd_data for
shared libraries.
diff --git a/bfd/elf32-tic6x.c b/bfd/elf32-tic6x.c
index d07902fe8a..20e4324b09 100644
--- a/bfd/elf32-tic6x.c
+++ b/bfd/elf32-tic6x.c
@@ -3866,6 +3866,9 @@ elf32_tic6x_merge_attributes (bfd *ibfd, struct bfd_link_info *info)
case Tag_ABI_PIC:
case Tag_ABI_PID:
+ /* Don't transfer these tags from dynamic objects. */
+ if ((ibfd->flags & DYNAMIC) != 0)
+ continue;
if (out_attr[i].i > in_attr[i].i)
out_attr[i].i = in_attr[i].i;
break;
diff --git a/ld/ldlang.c b/ld/ldlang.c
index 2ef234f90b..b2cdb3603a 100644
--- a/ld/ldlang.c
+++ b/ld/ldlang.c
@@ -6938,11 +6938,12 @@ lang_check (void)
bfd_printable_name (input_bfd), input_bfd,
bfd_printable_name (link_info.output_bfd));
}
- else if (bfd_count_sections (input_bfd))
- {
- /* If the input bfd has no contents, it shouldn't set the
- private data of the output bfd. */
+ /* If the input bfd has no contents, it shouldn't set the
+ private data of the output bfd. */
+ else if ((input_bfd->flags & DYNAMIC) != 0
+ || bfd_count_sections (input_bfd) != 0)
+ {
bfd_error_handler_type pfn = NULL;
/* If we aren't supposed to warn about mismatched input
--
Alan Modra
Australia Development Lab, IBM
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: PR25882, .gnu.attributes are not checked for shared libraries
2020-05-01 5:54 PR25882, .gnu.attributes are not checked for shared libraries Alan Modra
@ 2020-05-01 22:23 ` Joseph Myers
2020-05-01 23:48 ` H.J. Lu
0 siblings, 1 reply; 6+ messages in thread
From: Joseph Myers @ 2020-05-01 22:23 UTC (permalink / raw)
To: Alan Modra; +Cc: binutils, murphyp, tuliom
This binutils patch breaks glibc "make check" for big-endian powerpc
(32-bit and 64-bit).
https://sourceware.org/pipermail/libc-testresults/2020q2/006097.html
Errors of the form:
/scratch/jmyers/glibc-bot/install/compilers/powerpc64-linux-gnu/lib/gcc/powerpc64-glibc-linux-gnu/11.0.0/../../../../powerpc64-glibc-linux-gnu/bin/ld: /scratch/jmyers/glibc-bot/build/glibcs/powerpc64-linux-gnu/glibc/math/test-nldbl-redirect.o uses 64-bit long double, /scratch/jmyers/glibc-bot/build/glibcs/powerpc64-linux-gnu/glibc/math/libm.so.6 uses 128-bit long double
I don't know whether this is a problem with binutils, or it indicates that
BE powerpc glibc needs to use -mno-gnu-attribute on some files like LE
does to avoid such errors.
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: PR25882, .gnu.attributes are not checked for shared libraries
2020-05-01 22:23 ` Joseph Myers
@ 2020-05-01 23:48 ` H.J. Lu
2020-05-02 3:28 ` Alan Modra
0 siblings, 1 reply; 6+ messages in thread
From: H.J. Lu @ 2020-05-01 23:48 UTC (permalink / raw)
To: Joseph Myers; +Cc: Alan Modra, Tulio Magno Quites Machado Filho, Binutils
On Fri, May 1, 2020 at 4:22 PM Joseph Myers <joseph@codesourcery.com> wrote:
>
> This binutils patch breaks glibc "make check" for big-endian powerpc
> (32-bit and 64-bit).
>
> https://sourceware.org/pipermail/libc-testresults/2020q2/006097.html
>
> Errors of the form:
>
> /scratch/jmyers/glibc-bot/install/compilers/powerpc64-linux-gnu/lib/gcc/powerpc64-glibc-linux-gnu/11.0.0/../../../../powerpc64-glibc-linux-gnu/bin/ld: /scratch/jmyers/glibc-bot/build/glibcs/powerpc64-linux-gnu/glibc/math/test-nldbl-redirect.o uses 64-bit long double, /scratch/jmyers/glibc-bot/build/glibcs/powerpc64-linux-gnu/glibc/math/libm.so.6 uses 128-bit long double
>
> I don't know whether this is a problem with binutils, or it indicates that
> BE powerpc glibc needs to use -mno-gnu-attribute on some files like LE
> does to avoid such errors.
It is odd to check .gnu.attributes on shared libraries since shared libraries
used at link-time can be very different from run-time. Checking .gnu.attributes
on shared libraries gives you very little. For PT_GNU_PROPERTY,
.note.gnu.property section is ignored on shared libraries and shared library
check is done at run-time.
--
H.J.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: PR25882, .gnu.attributes are not checked for shared libraries
2020-05-01 23:48 ` H.J. Lu
@ 2020-05-02 3:28 ` Alan Modra
2020-05-02 4:24 ` H.J. Lu
2020-05-22 4:06 ` Alan Modra
0 siblings, 2 replies; 6+ messages in thread
From: Alan Modra @ 2020-05-02 3:28 UTC (permalink / raw)
To: H.J. Lu; +Cc: Joseph Myers, Tulio Magno Quites Machado Filho, Binutils
On Fri, May 01, 2020 at 04:48:38PM -0700, H.J. Lu wrote:
> On Fri, May 1, 2020 at 4:22 PM Joseph Myers <joseph@codesourcery.com> wrote:
> >
> > This binutils patch breaks glibc "make check" for big-endian powerpc
> > (32-bit and 64-bit).
> >
> > https://sourceware.org/pipermail/libc-testresults/2020q2/006097.html
> >
> > Errors of the form:
> >
> > /scratch/jmyers/glibc-bot/install/compilers/powerpc64-linux-gnu/lib/gcc/powerpc64-glibc-linux-gnu/11.0.0/../../../../powerpc64-glibc-linux-gnu/bin/ld: /scratch/jmyers/glibc-bot/build/glibcs/powerpc64-linux-gnu/glibc/math/test-nldbl-redirect.o uses 64-bit long double, /scratch/jmyers/glibc-bot/build/glibcs/powerpc64-linux-gnu/glibc/math/libm.so.6 uses 128-bit long double
Hmm, is the Tag_GNU_Power_ABI_FP claim of ibm long double strictly
correct? Doesn't libm also support 64-bit long double too? In which
case libm ought to be silent about long double support.
That of course can be accomplished by compiling all the object files
going into libm.so that provide long double functions (or call such
functions) with -mno-gnu-attributes. Another method with slightly
more finesse is to compile all files with the default -mgnu-attributes
but link with --no-warn-mismatch. That way the linker will not give
an error and also not emit the particular Tag with a conflict. (This
method assumes that assembly files emit the correct tags.)
> > I don't know whether this is a problem with binutils, or it indicates that
> > BE powerpc glibc needs to use -mno-gnu-attribute on some files like LE
> > does to avoid such errors.
>
> It is odd to check .gnu.attributes on shared libraries since shared libraries
> used at link-time can be very different from run-time.
You can say the same about many properties of shared libraries.
ld.gold on both arm and powerpc does check these attributes for shared
libraries. And it's necessary to use ld.gold to link split-stack and
non-split-stack object files if you want to ensure the non-split-stack
functions are called with something like the normal stack allocation.
If you use ld.bfd then non-split-stack functions might be called with
very small stacks. So arm and powerpc have a history of checking
shared library .gnu.attributes.
> Checking .gnu.attributes
> on shared libraries gives you very little.
Checking .gnu.attributes protects the user from linking against a
shared library that say, provides ibm long double math function when
the user is compiling for ieee long double. That was the idea behind
the binutils patch. There are of course some negatives, chief of
which is that .gnu.attributes is nowhere near fine enough grained to
work well with libraries that provide multiple areas of support. You
may hit a link error regarding functions you do not use in your app.
--
Alan Modra
Australia Development Lab, IBM
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: PR25882, .gnu.attributes are not checked for shared libraries
2020-05-02 3:28 ` Alan Modra
@ 2020-05-02 4:24 ` H.J. Lu
2020-05-22 4:06 ` Alan Modra
1 sibling, 0 replies; 6+ messages in thread
From: H.J. Lu @ 2020-05-02 4:24 UTC (permalink / raw)
To: Alan Modra; +Cc: Joseph Myers, Tulio Magno Quites Machado Filho, Binutils
On Fri, May 1, 2020 at 8:28 PM Alan Modra <amodra@gmail.com> wrote:
>
> On Fri, May 01, 2020 at 04:48:38PM -0700, H.J. Lu wrote:
> > On Fri, May 1, 2020 at 4:22 PM Joseph Myers <joseph@codesourcery.com> wrote:
> > >
> > > This binutils patch breaks glibc "make check" for big-endian powerpc
> > > (32-bit and 64-bit).
> > >
> > > https://sourceware.org/pipermail/libc-testresults/2020q2/006097.html
> > >
> > > Errors of the form:
> > >
> > > /scratch/jmyers/glibc-bot/install/compilers/powerpc64-linux-gnu/lib/gcc/powerpc64-glibc-linux-gnu/11.0.0/../../../../powerpc64-glibc-linux-gnu/bin/ld: /scratch/jmyers/glibc-bot/build/glibcs/powerpc64-linux-gnu/glibc/math/test-nldbl-redirect.o uses 64-bit long double, /scratch/jmyers/glibc-bot/build/glibcs/powerpc64-linux-gnu/glibc/math/libm.so.6 uses 128-bit long double
>
> Hmm, is the Tag_GNU_Power_ABI_FP claim of ibm long double strictly
> correct? Doesn't libm also support 64-bit long double too? In which
> case libm ought to be silent about long double support.
>
> That of course can be accomplished by compiling all the object files
> going into libm.so that provide long double functions (or call such
> functions) with -mno-gnu-attributes. Another method with slightly
> more finesse is to compile all files with the default -mgnu-attributes
> but link with --no-warn-mismatch. That way the linker will not give
> an error and also not emit the particular Tag with a conflict. (This
> method assumes that assembly files emit the correct tags.)
>
> > > I don't know whether this is a problem with binutils, or it indicates that
> > > BE powerpc glibc needs to use -mno-gnu-attribute on some files like LE
> > > does to avoid such errors.
> >
> > It is odd to check .gnu.attributes on shared libraries since shared libraries
> > used at link-time can be very different from run-time.
>
> You can say the same about many properties of shared libraries.
> ld.gold on both arm and powerpc does check these attributes for shared
> libraries. And it's necessary to use ld.gold to link split-stack and
> non-split-stack object files if you want to ensure the non-split-stack
> functions are called with something like the normal stack allocation.
> If you use ld.bfd then non-split-stack functions might be called with
> very small stacks. So arm and powerpc have a history of checking
> shared library .gnu.attributes.
>
> > Checking .gnu.attributes
> > on shared libraries gives you very little.
>
> Checking .gnu.attributes protects the user from linking against a
> shared library that say, provides ibm long double math function when
> the user is compiling for ieee long double. That was the idea behind
> the binutils patch. There are of course some negatives, chief of
> which is that .gnu.attributes is nowhere near fine enough grained to
> work well with libraries that provide multiple areas of support. You
> may hit a link error regarding functions you do not use in your app.
>
I don't think checking .gnu.attributes in shared libraries at link-time
can protect shared libraries with different long double math functions
at run-time. That is the main reason why I introduced .note.gnu.property
section.
--
H.J.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: PR25882, .gnu.attributes are not checked for shared libraries
2020-05-02 3:28 ` Alan Modra
2020-05-02 4:24 ` H.J. Lu
@ 2020-05-22 4:06 ` Alan Modra
1 sibling, 0 replies; 6+ messages in thread
From: Alan Modra @ 2020-05-22 4:06 UTC (permalink / raw)
To: H.J. Lu; +Cc: Joseph Myers, Tulio Magno Quites Machado Filho, Binutils
On Sat, May 02, 2020 at 12:58:00PM +0930, Alan Modra wrote:
> Checking .gnu.attributes protects the user from linking against a
> shared library that say, provides ibm long double math function when
> the user is compiling for ieee long double. That was the idea behind
> the binutils patch. There are of course some negatives, chief of
> which is that .gnu.attributes is nowhere near fine enough grained to
> work well with libraries that provide multiple areas of support. You
> may hit a link error regarding functions you do not use in your app.
I've been convinced we can't make a .gnu.attributes FP tag mismatch an
error, due to the current glibc/libm advertising 128-bit IBM long
double but in practice also supporting 64-bit long double via a
compatibility archive. Linking those together should at most give a
warning.
PR 25882
bfd/
* elf32-ppc.c (_bfd_elf_ppc_merge_fp_attributes): Don't init FP
attributes from shared libraries, and do not return an error if
they don't match.
gold/
* powerpc.cc (merge_object_attributes): Replace name param with
obj param. Update callers. Don't init FP attributes from shared
libraries, and do not emit an error if they don't match.
diff --git a/bfd/elf32-ppc.c b/bfd/elf32-ppc.c
index a900abe35e..d1c5e1b224 100644
--- a/bfd/elf32-ppc.c
+++ b/bfd/elf32-ppc.c
@@ -3557,6 +3557,17 @@ _bfd_elf_ppc_merge_fp_attributes (bfd *ibfd, struct bfd_link_info *info)
obj_attribute *in_attr, *in_attrs;
obj_attribute *out_attr, *out_attrs;
bfd_boolean ret = TRUE;
+ bfd_boolean warn_only;
+
+ /* We only warn about shared library mismatches, because common
+ libraries advertise support for a particular long double variant
+ but actually support more than one variant. For example, glibc
+ typically supports 128-bit IBM long double in the shared library
+ but has a compatibility static archive for 64-bit long double.
+ The linker doesn't have the smarts to see that an app using
+ object files marked as 64-bit long double call the compatibility
+ layer objects and only from there call into the shared library. */
+ warn_only = (ibfd->flags & DYNAMIC) != 0;
in_attrs = elf_known_obj_attributes (ibfd)[OBJ_ATTR_GNU];
out_attrs = elf_known_obj_attributes (obfd)[OBJ_ATTR_GNU];
@@ -3574,9 +3585,12 @@ _bfd_elf_ppc_merge_fp_attributes (bfd *ibfd, struct bfd_link_info *info)
;
else if (out_fp == 0)
{
- out_attr->type = ATTR_TYPE_FLAG_INT_VAL;
- out_attr->i ^= in_fp;
- last_fp = ibfd;
+ if (!warn_only)
+ {
+ out_attr->type = ATTR_TYPE_FLAG_INT_VAL;
+ out_attr->i ^= in_fp;
+ last_fp = ibfd;
+ }
}
else if (out_fp != 2 && in_fp == 2)
{
@@ -3584,7 +3598,7 @@ _bfd_elf_ppc_merge_fp_attributes (bfd *ibfd, struct bfd_link_info *info)
/* xgettext:c-format */
(_("%pB uses hard float, %pB uses soft float"),
last_fp, ibfd);
- ret = FALSE;
+ ret = warn_only;
}
else if (out_fp == 2 && in_fp != 2)
{
@@ -3592,7 +3606,7 @@ _bfd_elf_ppc_merge_fp_attributes (bfd *ibfd, struct bfd_link_info *info)
/* xgettext:c-format */
(_("%pB uses hard float, %pB uses soft float"),
ibfd, last_fp);
- ret = FALSE;
+ ret = warn_only;
}
else if (out_fp == 1 && in_fp == 3)
{
@@ -3600,7 +3614,7 @@ _bfd_elf_ppc_merge_fp_attributes (bfd *ibfd, struct bfd_link_info *info)
/* xgettext:c-format */
(_("%pB uses double-precision hard float, "
"%pB uses single-precision hard float"), last_fp, ibfd);
- ret = FALSE;
+ ret = warn_only;
}
else if (out_fp == 3 && in_fp == 1)
{
@@ -3608,7 +3622,7 @@ _bfd_elf_ppc_merge_fp_attributes (bfd *ibfd, struct bfd_link_info *info)
/* xgettext:c-format */
(_("%pB uses double-precision hard float, "
"%pB uses single-precision hard float"), ibfd, last_fp);
- ret = FALSE;
+ ret = warn_only;
}
in_fp = in_attr->i & 0xc;
@@ -3617,9 +3631,12 @@ _bfd_elf_ppc_merge_fp_attributes (bfd *ibfd, struct bfd_link_info *info)
;
else if (out_fp == 0)
{
- out_attr->type = ATTR_TYPE_FLAG_INT_VAL;
- out_attr->i ^= in_fp;
- last_ld = ibfd;
+ if (!warn_only)
+ {
+ out_attr->type = ATTR_TYPE_FLAG_INT_VAL;
+ out_attr->i ^= in_fp;
+ last_ld = ibfd;
+ }
}
else if (out_fp != 2 * 4 && in_fp == 2 * 4)
{
@@ -3627,7 +3644,7 @@ _bfd_elf_ppc_merge_fp_attributes (bfd *ibfd, struct bfd_link_info *info)
/* xgettext:c-format */
(_("%pB uses 64-bit long double, "
"%pB uses 128-bit long double"), ibfd, last_ld);
- ret = FALSE;
+ ret = warn_only;
}
else if (in_fp != 2 * 4 && out_fp == 2 * 4)
{
@@ -3635,7 +3652,7 @@ _bfd_elf_ppc_merge_fp_attributes (bfd *ibfd, struct bfd_link_info *info)
/* xgettext:c-format */
(_("%pB uses 64-bit long double, "
"%pB uses 128-bit long double"), last_ld, ibfd);
- ret = FALSE;
+ ret = warn_only;
}
else if (out_fp == 1 * 4 && in_fp == 3 * 4)
{
@@ -3643,7 +3660,7 @@ _bfd_elf_ppc_merge_fp_attributes (bfd *ibfd, struct bfd_link_info *info)
/* xgettext:c-format */
(_("%pB uses IBM long double, "
"%pB uses IEEE long double"), last_ld, ibfd);
- ret = FALSE;
+ ret = warn_only;
}
else if (out_fp == 3 * 4 && in_fp == 1 * 4)
{
@@ -3651,7 +3668,7 @@ _bfd_elf_ppc_merge_fp_attributes (bfd *ibfd, struct bfd_link_info *info)
/* xgettext:c-format */
(_("%pB uses IBM long double, "
"%pB uses IEEE long double"), ibfd, last_ld);
- ret = FALSE;
+ ret = warn_only;
}
}
diff --git a/gold/powerpc.cc b/gold/powerpc.cc
index 2010c1e3d2..318c41744b 100644
--- a/gold/powerpc.cc
+++ b/gold/powerpc.cc
@@ -1204,7 +1204,7 @@ class Target_powerpc : public Sized_target<size, big_endian>
// Merge object attributes from input object with those in the output.
void
- merge_object_attributes(const char*, const Attributes_section_data*);
+ merge_object_attributes(const Object*, const Attributes_section_data*);
private:
@@ -9481,7 +9481,7 @@ Target_powerpc<size, big_endian>::do_finalize_sections(
Powerpc_relobj<size, big_endian>* ppc_relobj
= static_cast<Powerpc_relobj<size, big_endian>*>(*p);
if (ppc_relobj->attributes_section_data())
- this->merge_object_attributes(ppc_relobj->name().c_str(),
+ this->merge_object_attributes(ppc_relobj,
ppc_relobj->attributes_section_data());
}
for (Input_objects::Dynobj_iterator p = input_objects->dynobj_begin();
@@ -9491,7 +9491,7 @@ Target_powerpc<size, big_endian>::do_finalize_sections(
Powerpc_dynobj<size, big_endian>* ppc_dynobj
= static_cast<Powerpc_dynobj<size, big_endian>*>(*p);
if (ppc_dynobj->attributes_section_data())
- this->merge_object_attributes(ppc_dynobj->name().c_str(),
+ this->merge_object_attributes(ppc_dynobj,
ppc_dynobj->attributes_section_data());
}
@@ -9514,7 +9514,7 @@ Target_powerpc<size, big_endian>::do_finalize_sections(
template<int size, bool big_endian>
void
Target_powerpc<size, big_endian>::merge_object_attributes(
- const char* name,
+ const Object* obj,
const Attributes_section_data* pasd)
{
// Return if there is no attributes section data.
@@ -9530,12 +9530,14 @@ Target_powerpc<size, big_endian>::merge_object_attributes(
Object_attribute* out_attr
= this->attributes_section_data_->known_attributes(vendor);
+ const char* name = obj->name().c_str();
const char* err;
const char* first;
const char* second;
int tag = elfcpp::Tag_GNU_Power_ABI_FP;
int in_fp = in_attr[tag].int_value() & 0xf;
int out_fp = out_attr[tag].int_value() & 0xf;
+ bool warn_only = obj->is_dynamic();
if (in_fp != out_fp)
{
err = NULL;
@@ -9543,10 +9545,13 @@ Target_powerpc<size, big_endian>::merge_object_attributes(
;
else if ((out_fp & 3) == 0)
{
- out_fp |= in_fp & 3;
- out_attr[tag].set_int_value(out_fp);
- out_attr[tag].set_type(Object_attribute::ATTR_TYPE_FLAG_INT_VAL);
- this->last_fp_ = name;
+ if (!warn_only)
+ {
+ out_fp |= in_fp & 3;
+ out_attr[tag].set_int_value(out_fp);
+ out_attr[tag].set_type(Object_attribute::ATTR_TYPE_FLAG_INT_VAL);
+ this->last_fp_ = name;
+ }
}
else if ((out_fp & 3) != 2 && (in_fp & 3) == 2)
{
@@ -9579,10 +9584,13 @@ Target_powerpc<size, big_endian>::merge_object_attributes(
;
else if ((out_fp & 0xc) == 0)
{
- out_fp |= in_fp & 0xc;
- out_attr[tag].set_int_value(out_fp);
- out_attr[tag].set_type(Object_attribute::ATTR_TYPE_FLAG_INT_VAL);
- this->last_ld_ = name;
+ if (!warn_only)
+ {
+ out_fp |= in_fp & 0xc;
+ out_attr[tag].set_int_value(out_fp);
+ out_attr[tag].set_type(Object_attribute::ATTR_TYPE_FLAG_INT_VAL);
+ this->last_ld_ = name;
+ }
}
else if ((out_fp & 0xc) != 2 * 4 && (in_fp & 0xc) == 2 * 4)
{
@@ -9612,10 +9620,16 @@ Target_powerpc<size, big_endian>::merge_object_attributes(
if (err)
{
if (parameters->options().warn_mismatch())
- gold_error(_(err), first, second);
+ {
+ if (warn_only)
+ gold_warning(_(err), first, second);
+ else
+ gold_error(_(err), first, second);
+ }
// Arrange for this attribute to be deleted. It's better to
// say "don't know" about a file than to wrongly claim compliance.
- out_attr[tag].set_type(0);
+ if (!warn_only)
+ out_attr[tag].set_type(0);
}
}
--
Alan Modra
Australia Development Lab, IBM
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2020-05-22 4:06 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-05-01 5:54 PR25882, .gnu.attributes are not checked for shared libraries Alan Modra
2020-05-01 22:23 ` Joseph Myers
2020-05-01 23:48 ` H.J. Lu
2020-05-02 3:28 ` Alan Modra
2020-05-02 4:24 ` H.J. Lu
2020-05-22 4:06 ` Alan Modra
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).