This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: Release 2.26 - Next week ?
- From: "H.J. Lu" <hjl dot tools at gmail dot com>
- To: Alan Modra <amodra at gmail dot com>
- Cc: Tristan Gingold <gingold at adacore dot com>, Matthias Klose <doko at ubuntu dot com>, binutils <binutils at sourceware dot org>
- Date: Tue, 12 Jan 2016 21:08:33 -0800
- Subject: Re: Release 2.26 - Next week ?
- Authentication-results: sourceware.org; auth=none
- References: <C25FDD18-CD84-4630-9BCD-4B5E5CB057D6 at adacore dot com> <568FF162 dot 5000801 at ubuntu dot com> <828FEF00-284A-48C3-9395-2295167002EA at adacore dot com> <20160113010412 dot GB1270 at bubble dot grove dot modra dot org> <CAMe9rOpPPFuAwR-vif32KvDnjHRy5p4ushrvhrVso43681E+3Q at mail dot gmail dot com> <20160113015844 dot GC1270 at bubble dot grove dot modra dot org> <CAMe9rOqyLdTz5FiiMVTukDnQwby+Kx_wzmHtWtNu6n3ZOXfEDA at mail dot gmail dot com> <20160113034534 dot GD1270 at bubble dot grove dot modra dot org>
On Tue, Jan 12, 2016 at 7:45 PM, Alan Modra <amodra@gmail.com> wrote:
> On Tue, Jan 12, 2016 at 07:09:27PM -0800, H.J. Lu wrote:
>> On Tue, Jan 12, 2016 at 5:58 PM, Alan Modra <amodra@gmail.com> wrote:
>> > On Tue, Jan 12, 2016 at 05:11:53PM -0800, H.J. Lu wrote:
>> >> On Tue, Jan 12, 2016 at 5:04 PM, Alan Modra <amodra@gmail.com> wrote:
>> >> > On Mon, Jan 11, 2016 at 10:21:08AM +0100, Tristan Gingold wrote:
>> >> >>
>> >> >> > On 08 Jan 2016, at 18:26, Matthias Klose <doko@ubuntu.com> wrote:
>> >> >> > - PR 19421, but currently only a bug report
>> >> >
>> >> > Now analysed. The ppc64le kernel problem is due to needing to keep
>> >> > undefined symbols. I'd say it is also a kernel bug that the symbol in
>> >> > question isn't defined, but that's really another issue. The point is
>> >> > that we have a GNU ld use case where removing undefined symbols breaks
>> >> > an existing program.
>>
>> Is this problem specific to ppc64le? Do we have a small testcase?
>
> No, this is not ppc64le specific, but happens to tickle a ppc64le
> kernel problem.
>
> cat > undef.s <<EOF
> .text
> .globl _start
> .weak foo
> _start:
> .dc.a foo
> EOF
> as -o undef.o undef.s
> ld -o undef undef.o
> nm undef
>
> Current master on x86_64 gives
> 0000000000601000 T __bss_start
> 0000000000601000 T _edata
> 0000000000601000 T _end
> 0000000000400078 T _start
>
> 2.25
> 0000000000601000 T __bss_start
> 0000000000601000 T _edata
> 0000000000601000 T _end
> w foo
> 0000000000400078 T _start
It shouldn't make a difference for x86.
>> >> >> Letâs exclude it.
>> >> >
>> >> > I'm of two minds about this. PR3417 wants undefined symbols to be
>> >> > removed: "When the reference to __tls_get_addr is removed, it leaves
>> >> > undefined symbol in symtab. It is confusing." H.J. what exactly was
>> >> > confusing? When I made the PR3417 patch, I thought PR3417 was mostly
>> >> > about cosmetics and figured that removing undefined symbols was
>> >> > reasonably safe. If it is true that PR3417 was only cosmetic, I think
>> >> > my patch ought to be reverted.
>> >> >
>> >>
>> >> Is PR3417 the right PR?
>> >
>> > No, sorry. https://sourceware.org/bugzilla/show_bug.cgi?id=4317
>> >
>>
>> My PR is with executable. But
>>
>> https://sourceware.org/bugzilla/show_bug.cgi?id=19421
>>
>> is for relocatable objects. I am OK to keep undefined symbols
>> in .o files.
>
> No, pr19421 is about executables too. The first stage executable
> .tmp_vmlinux1 loses an undefined symbol, "__crc_TOC.", which
> eventually results in kernel modules not loading. The problem is not
> with the relocatable kernel modules but with the executable.
>
Is __crc_TOC exported? If not, should it be exported? Is it referenced
by kernel modules? If not, why does it matter?
--
H.J.