9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
* [9fans] Linker and duplicate symbols
@ 2016-09-02  2:34 Chris McGee
  2016-09-02 10:20 ` Richard Miller
  0 siblings, 1 reply; 12+ messages in thread
From: Chris McGee @ 2016-09-02  2:34 UTC (permalink / raw)


Hi All,

I have recently run into a problem when compiling the kernel where the linker complains about duplicate symbols and fails. The symbol is sleep(), which is exported in libc.a but is also exported in another file in port, but with different parameters (both number and type).

It's my understanding that C doesn't support overloading. So, why is it that the kernel links when there are two different sleep functions?

Thanks,
Chris



^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [9fans] Linker and duplicate symbols
  2016-09-02  2:34 [9fans] Linker and duplicate symbols Chris McGee
@ 2016-09-02 10:20 ` Richard Miller
  2016-09-02 15:56   ` Chris McGee
  0 siblings, 1 reply; 12+ messages in thread
From: Richard Miller @ 2016-09-02 10:20 UTC (permalink / raw)
  To: 9fans

> I have recently run into a problem when compiling the kernel where the linker complains about duplicate symbols and fails. The symbol is sleep(), which is exported in libc.a but is also exported in another file in port, but with different parameters (both number and type).

Shouldn't happen (TM).  The duplicate sleep may be a side effect of
some other error (undefined symbol?) which is getting ld confused.
I suggest finding the invocation of ld (or $LD) in the mkfile and
inserting a copy of the command with "echo" prepended, to see exactly
what's being linked; then have a good look at all the error messages
and see if there's anything obvious you can clear up which could make
the duplicate sleep go away too.

Otherwise you could post the ld line and error messages to get more
eyes looking at the problem ...




^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [9fans] Linker and duplicate symbols
  2016-09-02 10:20 ` Richard Miller
@ 2016-09-02 15:56   ` Chris McGee
  2016-09-02 16:11     ` Richard Miller
  2016-09-02 16:12     ` cinap_lenrek
  0 siblings, 2 replies; 12+ messages in thread
From: Chris McGee @ 2016-09-02 15:56 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

Thanks Richard,

I tried outputting the echo of the ld command and it's linking all of the .5 files together along with the few archive files to produce the raw kernel file. I'll go hunting to see if there is some other unbound symbol.

I think the reason why I'm confused is that I don't understand how the linker can possibly pick the "right" symbol here given that C doesn't allow overloading. There are two sleep symbols. Why does the linker generally know to pick the one from the .5 file and not the one from the libc.a. Is it that the linker prefers a symbol from a .5 file over the .a file?

Chris

On Sep 2, 2016, at 6:20 AM, Richard Miller <9fans@hamnavoe.com> wrote:

>> I have recently run into a problem when compiling the kernel where the linker complains about duplicate symbols and fails. The symbol is sleep(), which is exported in libc.a but is also exported in another file in port, but with different parameters (both number and type).
> 
> Shouldn't happen (TM).  The duplicate sleep may be a side effect of
> some other error (undefined symbol?) which is getting ld confused.
> I suggest finding the invocation of ld (or $LD) in the mkfile and
> inserting a copy of the command with "echo" prepended, to see exactly
> what's being linked; then have a good look at all the error messages
> and see if there's anything obvious you can clear up which could make
> the duplicate sleep go away too.
> 
> Otherwise you could post the ld line and error messages to get more
> eyes looking at the problem ...
> 
> 




^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [9fans] Linker and duplicate symbols
  2016-09-02 15:56   ` Chris McGee
@ 2016-09-02 16:11     ` Richard Miller
  2016-09-09  0:48       ` Chris McGee
  2016-09-02 16:12     ` cinap_lenrek
  1 sibling, 1 reply; 12+ messages in thread
From: Richard Miller @ 2016-09-02 16:11 UTC (permalink / raw)
  To: 9fans

> Is it that the linker prefers a symbol from a .5 file over the .a file?

I believe it's supposed to pick the first one it finds.  Object files and
libraries are processed in the order in which they appear on the command line.
On my system proc.5 appears before libc.a in the ld command, and libc.a(sleep.5)
doesn't contain any symbols other than sleep, so there should be no reason
for ld to pull it in from the library.




^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [9fans] Linker and duplicate symbols
  2016-09-02 15:56   ` Chris McGee
  2016-09-02 16:11     ` Richard Miller
@ 2016-09-02 16:12     ` cinap_lenrek
  2016-09-02 20:00       ` Chris McGee
  1 sibling, 1 reply; 12+ messages in thread
From: cinap_lenrek @ 2016-09-02 16:12 UTC (permalink / raw)
  To: 9fans

uses the first one it finds, so the order matters. its not unusual
for programs to override certain library function by providing ther
own version and putting them first in the object file list. this
works only when the function you want to replace sits alone in his
own object file (the smallest unit of linkage).

the kernel does link in some standard libc functions, but obviously
not the ones attempting syscalls :)

--
cinap



^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [9fans] Linker and duplicate symbols
  2016-09-02 16:12     ` cinap_lenrek
@ 2016-09-02 20:00       ` Chris McGee
  2016-09-02 22:34         ` Steve Simon
  0 siblings, 1 reply; 12+ messages in thread
From: Chris McGee @ 2016-09-02 20:00 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

Thanks Cinap, Richard,

That makes sense and was probably obvious or in a man page somewhere.

Chris

> On Sep 2, 2016, at 12:12 PM, cinap_lenrek@felloff.net wrote:
>
> uses the first one it finds, so the order matters. its not unusual
> for programs to override certain library function by providing ther
> own version and putting them first in the object file list. this
> works only when the function you want to replace sits alone in his
> own object file (the smallest unit of linkage).
>
> the kernel does link in some standard libc functions, but obviously
> not the ones attempting syscalls :)
>
> --
> cinap
>



^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [9fans] Linker and duplicate symbols
  2016-09-02 20:00       ` Chris McGee
@ 2016-09-02 22:34         ` Steve Simon
  2016-09-03 16:58           ` Chris McGee
  0 siblings, 1 reply; 12+ messages in thread
From: Steve Simon @ 2016-09-02 22:34 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

the linker rejects later instances of symbols if it had already found an instance. the important point however is that this is done on a per file basis if the symbol is in a library.

the case where I have seen this is your code (the kernel code in this case) references another symbol which only exists in the file that contains the second instance of clock on the command line.

this means both copies of clock are forced into the linkage, one directly through a call to clock, the other through the other reference.

what I have done to find these in the past (crude but effective) is to delete both files which contain the clock call (for libc use "ar d") then run mk again and see what complains.

 my bet is there will be unresolved calls to clock, and something else that shouldn't be there...

good luck,

-Steve

> On 2 Sep 2016, at 21:00, Chris McGee <sirnewton_01@yahoo.ca> wrote:
> 
> Thanks Cinap, Richard,
> 
> That makes sense and was probably obvious or in a man page somewhere.
> 
> Chris
> 
>> On Sep 2, 2016, at 12:12 PM, cinap_lenrek@felloff.net wrote:
>> 
>> uses the first one it finds, so the order matters. its not unusual
>> for programs to override certain library function by providing ther
>> own version and putting them first in the object file list. this
>> works only when the function you want to replace sits alone in his
>> own object file (the smallest unit of linkage).
>> 
>> the kernel does link in some standard libc functions, but obviously
>> not the ones attempting syscalls :)
>> 
>> --
>> cinap
>> 




^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [9fans] Linker and duplicate symbols
  2016-09-02 22:34         ` Steve Simon
@ 2016-09-03 16:58           ` Chris McGee
  0 siblings, 0 replies; 12+ messages in thread
From: Chris McGee @ 2016-09-03 16:58 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

Thanks Steve,

I will give these strategies a try.

Chris

> On Sep 2, 2016, at 6:34 PM, Steve Simon <steve@quintile.net> wrote:
> 
> the linker rejects later instances of symbols if it had already found an instance. the important point however is that this is done on a per file basis if the symbol is in a library.
> 
> the case where I have seen this is your code (the kernel code in this case) references another symbol which only exists in the file that contains the second instance of clock on the command line.
> 
> this means both copies of clock are forced into the linkage, one directly through a call to clock, the other through the other reference.
> 
> what I have done to find these in the past (crude but effective) is to delete both files which contain the clock call (for libc use "ar d") then run mk again and see what complains.
> 
> my bet is there will be unresolved calls to clock, and something else that shouldn't be there...
> 
> good luck,
> 
> -Steve
> 
>> On 2 Sep 2016, at 21:00, Chris McGee <sirnewton_01@yahoo.ca> wrote:
>> 
>> Thanks Cinap, Richard,
>> 
>> That makes sense and was probably obvious or in a man page somewhere.
>> 
>> Chris
>> 
>>> On Sep 2, 2016, at 12:12 PM, cinap_lenrek@felloff.net wrote:
>>> 
>>> uses the first one it finds, so the order matters. its not unusual
>>> for programs to override certain library function by providing ther
>>> own version and putting them first in the object file list. this
>>> works only when the function you want to replace sits alone in his
>>> own object file (the smallest unit of linkage).
>>> 
>>> the kernel does link in some standard libc functions, but obviously
>>> not the ones attempting syscalls :)
>>> 
>>> --
>>> cinap
> 
> 




^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [9fans] Linker and duplicate symbols
  2016-09-02 16:11     ` Richard Miller
@ 2016-09-09  0:48       ` Chris McGee
  2016-09-09  8:31         ` Richard Miller
  0 siblings, 1 reply; 12+ messages in thread
From: Chris McGee @ 2016-09-09  0:48 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

Thanks Richard,

I traced it down to a symbol being brought in from libc that brought in other symbols that collided with ones on the kernel.

Btw, with your latest changes I have merged them in with the latest 9front and its running on my Pi 1 and Pi 2.

Only weird problem is when I do fshalt -r. My pi2 goes unstable with panics on reboot. Cold reset brings it back to normal.

Does your latest code work on Pi zero? I don't yet have one to test it.

Chris

On Sep 2, 2016, at 12:11 PM, Richard Miller <9fans@hamnavoe.com> wrote:

>> Is it that the linker prefers a symbol from a .5 file over the .a file?
> 
> I believe it's supposed to pick the first one it finds.  Object files and
> libraries are processed in the order in which they appear on the command line.
> On my system proc.5 appears before libc.a in the ld command, and libc.a(sleep.5)
> doesn't contain any symbols other than sleep, so there should be no reason
> for ld to pull it in from the library.
> 
> 




^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [9fans] Linker and duplicate symbols
  2016-09-09  0:48       ` Chris McGee
@ 2016-09-09  8:31         ` Richard Miller
  2016-09-09 14:55           ` Chris McGee
  0 siblings, 1 reply; 12+ messages in thread
From: Richard Miller @ 2016-09-09  8:31 UTC (permalink / raw)
  To: 9fans

> Only weird problem is when I do fshalt -r. My pi2 goes unstable with panics on reboot. Cold reset brings it back to normal.

Sorry, I have seen this failure too, but only on pi3.  If you run with
*ncpu=1 the soft reboot seems to work reliably.  But my scheme for
rebooting from multicore state is clearly not right.  Unfortunately I
don't know of any way of forcing an arm reset after loading the new
kernel without also resetting the gpu back to the load-from-sdcard
point.  I'll welcome any suggestions for a way to do this.  I think
linux on the pi supports kexec, so it might be possible to reverse
engineer from that and find a way that works.  On the other hand, if
you search the web for "raspbian kexec" most of the hits seem to be of
the "doesn't work" variety, so maybe not.

> Does your latest code work on Pi zero? I don't yet have one to test it.

Yes it does.  If you boot different kernels from the same sdcard you need
to use [pi0] as a section header for the zero. (Discovered by trial and
error because this doesn't seem to be documented anywhere.)




^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [9fans] Linker and duplicate symbols
  2016-09-09  8:31         ` Richard Miller
@ 2016-09-09 14:55           ` Chris McGee
  2016-09-09 16:37             ` Richard Miller
  0 siblings, 1 reply; 12+ messages in thread
From: Chris McGee @ 2016-09-09 14:55 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

I wanted to check if the problem was pre existing or a result of a potentially bad merge on my part. It sounds like reboot wasn't a big concern for the raspberry Pi engineers. Wow, weird.

Thanks for the suggestion. I'll try it out when/if they ever have the zero available in Canada for a comparable price. Do you use the pi or pi2 kernel for zero?

Chris

On Sep 9, 2016, at 4:31 AM, Richard Miller <9fans@hamnavoe.com> wrote:

>> Only weird problem is when I do fshalt -r. My pi2 goes unstable with panics on reboot. Cold reset brings it back to normal.
> 
> Sorry, I have seen this failure too, but only on pi3.  If you run with
> *ncpu=1 the soft reboot seems to work reliably.  But my scheme for
> rebooting from multicore state is clearly not right.  Unfortunately I
> don't know of any way of forcing an arm reset after loading the new
> kernel without also resetting the gpu back to the load-from-sdcard
> point.  I'll welcome any suggestions for a way to do this.  I think
> linux on the pi supports kexec, so it might be possible to reverse
> engineer from that and find a way that works.  On the other hand, if
> you search the web for "raspbian kexec" most of the hits seem to be of
> the "doesn't work" variety, so maybe not.
> 
>> Does your latest code work on Pi zero? I don't yet have one to test it.
> 
> Yes it does.  If you boot different kernels from the same sdcard you need
> to use [pi0] as a section header for the zero. (Discovered by trial and
> error because this doesn't seem to be documented anywhere.)
> 
> 




^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [9fans] Linker and duplicate symbols
  2016-09-09 14:55           ` Chris McGee
@ 2016-09-09 16:37             ` Richard Miller
  0 siblings, 0 replies; 12+ messages in thread
From: Richard Miller @ 2016-09-09 16:37 UTC (permalink / raw)
  To: 9fans

> It sounds like reboot wasn't a big concern for the raspberry Pi engineers. Wow, weird.

The normal case considered by the engineers is rebooting from the
default kernel binary on the sd card (ie hard reset), which works
fine both for linux and plan 9.

The problem with 'fshalt -r' is that the default without a kernel
file argument is to guess at a file and soft-reboot that, which
isn't reliable on multi-core.  But if you say 'fshalt -r /dev/null',
that will halt the fs and hard-reset, giving you a reliable boot
of the sd card kernel.  Arguably that might have been a better
default when a kernel file isn't specified.

> ... Do you use the pi or pi2 kernel for zero?

It's the 9pi or 9picpu kernel - pizero has the old armv6 SoC.




^ permalink raw reply	[flat|nested] 12+ messages in thread

end of thread, other threads:[~2016-09-09 16:37 UTC | newest]

Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-09-02  2:34 [9fans] Linker and duplicate symbols Chris McGee
2016-09-02 10:20 ` Richard Miller
2016-09-02 15:56   ` Chris McGee
2016-09-02 16:11     ` Richard Miller
2016-09-09  0:48       ` Chris McGee
2016-09-09  8:31         ` Richard Miller
2016-09-09 14:55           ` Chris McGee
2016-09-09 16:37             ` Richard Miller
2016-09-02 16:12     ` cinap_lenrek
2016-09-02 20:00       ` Chris McGee
2016-09-02 22:34         ` Steve Simon
2016-09-03 16:58           ` Chris McGee

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 NNTP newsgroup(s).