This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH][BZ 18960] setlocale.c: Mark *_used symbols as unaligned.
- From: Rich Felker <dalias at libc dot org>
- To: Carlos O'Donell <carlos at redhat dot com>
- Cc: Florian Weimer <fweimer at redhat dot com>, Marcin KoÅcielnicki <koriakin at 0x04 dot net>, libc-alpha at sourceware dot org
- Date: Mon, 28 Sep 2015 14:22:17 -0400
- Subject: Re: [PATCH][BZ 18960] setlocale.c: Mark *_used symbols as unaligned.
- Authentication-results: sourceware.org; auth=none
- References: <1443360385-20079-1-git-send-email-koriakin at 0x04 dot net> <20150928141824 dot GX17773 at brightrain dot aerifal dot cx> <5609541A dot 5070500 at redhat dot com> <20150928151749 dot GK5140 at vapier dot lan> <56095B35 dot 8020709 at redhat dot com> <56095C87 dot 9060100 at redhat dot com>
On Mon, Sep 28, 2015 at 11:28:07AM -0400, Carlos O'Donell wrote:
> On 09/28/2015 11:22 AM, Florian Weimer wrote:
> > On 09/28/2015 05:17 PM, Mike Frysinger wrote:
> >> On 28 Sep 2015 16:52, Florian Weimer wrote:
> >>> On 09/28/2015 04:18 PM, Rich Felker wrote:
> >>>> Can you explain how/why you think this is needed? char has no
> >>>> alignment requirements (inherently) so as far as I can tell, the
> >>>> compiler may not make any alignment assumptions about an extern object
> >>>> of type char.
> >>>
> >>> s390(x) expects all top-level objects in the data segment to be aligned
> >>> to at least 2. As far as I can tell, this is not explicitly mentioned
> >>> in the psABI supplement, but it is heavily implied by .align directives
> >>> and use of the lalr instruction.
> >>
> >> how does that bubble in here though ?
> >
> > The value of a weak symbol is used as flag, to determine that a
> > particular piece of code has been linked in. If the object file is
> > pulled in by other code, the symbol is defined with an absolute address.
> >
> >> does locale/localeinfo.h need to update
> >> _NL_CURRENT_DEFINE to use helpers from libc-symbols.h ? this seems to be
> >> patching a single symptom point rather than addressing the source.
> >
> > I'm not sure if this occurs in other places.
>
> As I said earlier I did a quick review and this is likely the only case
> I could find. I encourage others to look though.
>
> In some sense I agree with Mike, that there could be some kind of macro
> to prevent this from ever happening again. That all weak-ref-check idioms
> for data addresses should go through a macro that prevents s390 from
> failing and enforces a sane symbol-like value (if such a macro doesn't
> already exist).
>
> It seems a bit like overkill right now though. I think just making the
> value 16 with a comment will work.
Is there a reason this hack with absolute definitions is being used
rather than just defining actual objects for the symbols to resolve to
(or aliasing them to objects that already exist)? This approach would
not require any ABI-specific knowledge.
Rich