Re: A symbol version patch for glibc 2.x compatibility

["H . J . Lu" <hjl at valinux dot com>]

On Tue, Nov 07, 2000 at 11:01:59AM -0800, Nick Clifton wrote:
> Hi H.J.
> 
>   I am not familiar with this versioning stuff, so please could you
>   help me understand your patch by answering a few questions:
> 
> : I modified as so that it will
> : 
> : 1. Allow duplicated version name like
> : 
> : 	.symver bar,bar@GLIBC_2.1
> : 	.symver bar,bar@GLIBC_2.1
> 
> Why do you need this ability ?  (I have no objections to it, I am just
> wondering whether there ought to be a warning generated if a second,
> duplicate, definition is encountered).

I am working on a glibc patch. With my patch, 2 identical symbol
version definitions may wind up in the asm code. I don't think it
should cause any harm, like

	.globl foo
	.globl foo

> 
> : ----
> : 	.file	"x.c"
> : 	.version	"01.01"
> : 	.symver bar,bar@GLIBC_2.1
> : 	.symver bar,bar@GLIBC_2.1
> : 	.globl foobar
> : foobar:
> : 	.long foo
> : 	.symver foobar,foobar@GLIBC_2.1
> : dummy:
> : 	.long foo
> : 	.symver foo,foo@GLIBC_2.1
> : -----
> 
> Does this really work ?  I thought that the symbol defined in a
> .symver op had to be defined in the same file.  Quoting from the as
> info file:
> 
>    For ELF targets, the `.symver' directive is used like this:
> 
>      .symver NAME, NAME2@NODENAME
> 
>    In this case, the symbol NAME must exist and be defined within the
>    file being assembled.  The `.versym' directive effectively creates
>    [snip]

It should be updated to something like

	If NAME is not defined in the file, all references to NAME will
	be changed to NAME2@NODENAME.

> 
> Or is this your point about removing unneeded version symbols ?  (In
> which case maybe the documentation ought to be updated as well).
> 

I will update the documentation.


-- 
H.J. Lu (hjl@gnu.org)