Weak symbol for printf/scanf family

Weak symbol for printf/scanf family

[Jojo R]

Hi,
	Dose anyone know why libc dose not use WEAK attribution for
	some symbols like printf/scanf family ?

	Some developers want to reimplement sub sets of them maybe :)

	Thanks.

— Jojo

Re: Weak symbol for printf/scanf family

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 1110 bytes --]

On 11 Apr 2022 10:50, Jojo R wrote:
> 	Dose anyone know why libc dose not use WEAK attribution for
> 	some symbols like printf/scanf family ?
> 
> 	Some developers want to reimplement sub sets of them maybe :)

weak symbols in static libs is generally a recipe for doom.  the linker won't
pull in objects from an archive unless there's a strong symbol pulling it in
which means weak refs effectively never get satisfied.  this is mitigated by
using --whole-archive, but that defeats the point of using a static lib with
newlib in the first place.

backing up a bit, newlib uses static linking, which means if your program
provided the printf symbol, either directly or in an object listed before
the -lc linkage, your printf symbol would be used first, and newlib's own
printf would not be pulled in.  if you're still seeing newlib's printf
being pulled in (and presumably causing duplicate symbol linker errors),
then something else is going on, and weak symbols wouldn't help.

but it's hard to say without a concrete example of what you're trying to
do and how it isn't working.
-mike

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Weak symbol for printf/scanf family

[Jojo R]

Hi,

	Thanks for your explanation.

	I check the root cause of the 'multiple definition’ issue again,
	the user’s printf symbol would be used first exactly.

	my issue is that there are two printf family symbols in one object,
	and user rewrite the one(vfprintf) of them, and other user function call some
	other Newlib’s function like vprintf, this will create a error of 'multiple definition’.

	I think linker will check this error by whole .o object, so Newlib should write every
	printf/scanf family function in individual object ?

	my test case is following :

a.s
-----------
.section .text.bar
.global bar
bar:
 ret
 .size bar, . - bar

.global foo
.text
.type foo, function
foo:
 call bar
 ret
 .size foo, . - foo
----------
build: ./gas/as -o a.o a.s
AR: ./binutils/as -r liba.a a.o

And the 'main' in b.s will call 'foo', and I want to rewrite function 'bar'
b.s
---------
.global foo
.global bar
.text
bar:
 nop
 nop
 ret
 .size bar, . - bar

.global main
.text
main:
 call foo
 .size main, . - main
----------
build: ./gas/as -o b.o b.s
Link: ./ld/ld-new -o a b.o -L. -la
it will report 'multi define'.

— Jojo
在 2022年4月13日 +0800 PM1:27，Mike Frysinger <vapier@gentoo.org>，写道：
> On 11 Apr 2022 10:50, Jojo R wrote:
> > Dose anyone know why libc dose not use WEAK attribution for
> > some symbols like printf/scanf family ?
> >
> > Some developers want to reimplement sub sets of them maybe :)
>
> weak symbols in static libs is generally a recipe for doom. the linker won't
> pull in objects from an archive unless there's a strong symbol pulling it in
> which means weak refs effectively never get satisfied. this is mitigated by
> using --whole-archive, but that defeats the point of using a static lib with
> newlib in the first place.
>
> backing up a bit, newlib uses static linking, which means if your program
> provided the printf symbol, either directly or in an object listed before
> the -lc linkage, your printf symbol would be used first, and newlib's own
> printf would not be pulled in. if you're still seeing newlib's printf
> being pulled in (and presumably causing duplicate symbol linker errors),
> then something else is going on, and weak symbols wouldn't help.
>
> but it's hard to say without a concrete example of what you're trying to
> do and how it isn't working.
> -mike