This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Release 2.26 - Next week ?


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]