[libvirt] [RFC] libvirt-admin: Mark symbols as local
Otherwise we're leaking some 30+ symbols like virAdmConnectClass virAdmConnectNew virConnectClass virConnectCloseCallbackDataClass virDomainClass ... I marked the one symbol needed by the deamon as LIBVIRT_ADMIN_PRIVATE_<VERSION> for now. --- There's likely a better solution for xdr_admin_connect_open_args. Cheers, -- Guido src/libvirt_admin.syms | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/src/libvirt_admin.syms b/src/libvirt_admin.syms index d9e3c0b..de4f1b8 100644 --- a/src/libvirt_admin.syms +++ b/src/libvirt_admin.syms @@ -16,3 +16,12 @@ LIBVIRT_ADMIN_1.3.0 { virAdmConnectClose; virAdmConnectRef; }; + + +LIBVIRT_ADMIN_PRIVATE_1.2.19 { + global: + xdr_admin_connect_open_args; + + local: + *; +}; -- 2.1.4
On Tue, Aug 11, 2015 at 09:24:59PM +0200, Guido Günther wrote:
Otherwise we're leaking some 30+ symbols like
virAdmConnectClass virAdmConnectNew
==========
virConnectClass virConnectCloseCallbackDataClass virDomainClass
These three are not related to libvirt-admin, they are leaked from datatypes, I guess. We need libvirt_admin_private.syms that will act for admin the same way as libvirt_private.syms acts fr the libvirt library.
...
I marked the one symbol needed by the deamon as LIBVIRT_ADMIN_PRIVATE_<VERSION> for now. ---
There's likely a better solution for xdr_admin_connect_open_args.
What I don't understand is how come there's a problem with xdr structures. Thanks for noticing, though, I'll look into it.
Cheers, -- Guido
src/libvirt_admin.syms | 9 +++++++++ 1 file changed, 9 insertions(+)
diff --git a/src/libvirt_admin.syms b/src/libvirt_admin.syms index d9e3c0b..de4f1b8 100644 --- a/src/libvirt_admin.syms +++ b/src/libvirt_admin.syms @@ -16,3 +16,12 @@ LIBVIRT_ADMIN_1.3.0 { virAdmConnectClose; virAdmConnectRef; }; + + +LIBVIRT_ADMIN_PRIVATE_1.2.19 { + global: + xdr_admin_connect_open_args; + + local: + *; +}; -- 2.1.4
-- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On Wed, Aug 12, 2015 at 10:37:30AM +0200, Martin Kletzander wrote:
On Tue, Aug 11, 2015 at 09:24:59PM +0200, Guido Günther wrote:
Otherwise we're leaking some 30+ symbols like
virAdmConnectClass virAdmConnectNew
==========
virConnectClass virConnectCloseCallbackDataClass virDomainClass
These three are not related to libvirt-admin, they are leaked from datatypes, I guess. We need libvirt_admin_private.syms that will act for admin the same way as libvirt_private.syms acts fr the libvirt library.
These will simply be catched by the: local: *; so we don't need a _private.syms for these...
...
I marked the one symbol needed by the deamon as LIBVIRT_ADMIN_PRIVATE_<VERSION> for now. ---
There's likely a better solution for xdr_admin_connect_open_args.
What I don't understand is how come there's a problem with xdr structures. Thanks for noticing, though, I'll look into it.
...and if we get rid of xdr_admin_connect_open_args we don't need to intruce any LIBVIRT_ADMIN_PRIVATE_* at all. Cheers, -- Guido
On Tue, Aug 11, 2015 at 09:24:59PM +0200, Guido Günther wrote:
Otherwise we're leaking some 30+ symbols like
virAdmConnectClass virAdmConnectNew virConnectClass virConnectCloseCallbackDataClass virDomainClass ...
I marked the one symbol needed by the deamon as LIBVIRT_ADMIN_PRIVATE_<VERSION> for now.
How are you identifying those as leaked ? IIRC, exports are those symbols marked with 'T' in the nm output: [man nm] · The symbol type. At least the following types are used; others are, as well, depending on the object file format. If lowercase, the symbol is usually local; if uppercase, the symbol is global (external). There are however a few lowercase symbols that are shown for special global symbols ("u", "v" and "w"). "T" "t" The symbol is in the text (code) section. [/man] # nm -a .libs/libvirt-admin.so | grep ' T ' 0000000000001c80 T virAdmConnectClose 00000000000017d0 T virAdmConnectOpen 0000000000001d30 T virAdmConnectRef # nm -a .libs/libvirt-admin.so | grep virAdmConnectNew 00000000000037c0 t virAdmConnectNew So, IIUC, that lowercase 't' means the symol is local, and exported. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
On Wed, Aug 12, 2015 at 11:15:58AM +0100, Daniel P. Berrange wrote:
On Tue, Aug 11, 2015 at 09:24:59PM +0200, Guido Günther wrote:
Otherwise we're leaking some 30+ symbols like
virAdmConnectClass virAdmConnectNew virConnectClass virConnectCloseCallbackDataClass virDomainClass ...
I marked the one symbol needed by the deamon as LIBVIRT_ADMIN_PRIVATE_<VERSION> for now.
How are you identifying those as leaked ?
I tripped on this by dpkg-gensymbols[1] which uses objdump. objdump -w --dynamic-syms src/.libs/libvirt-admin.so | grep " g " The g meaning global visibility. A similar result can be achieved with "nm -D".
IIRC, exports are those symbols marked with 'T' in the nm output:
[man nm] · The symbol type. At least the following types are used; others are, as well, depending on the object file format. If lowercase, the symbol is usually local; if uppercase, the symbol is global (external). There are however a few lowercase symbols that are shown for special global symbols ("u", "v" and "w").
"T" "t" The symbol is in the text (code) section. [/man]
# nm -a .libs/libvirt-admin.so | grep ' T ' 0000000000001c80 T virAdmConnectClose 00000000000017d0 T virAdmConnectOpen 0000000000001d30 T virAdmConnectRef
# nm -a .libs/libvirt-admin.so | grep virAdmConnectNew 00000000000037c0 t virAdmConnectNew
So, IIUC, that lowercase 't' means the symol is local, and exported.
I'm seeing 0000000000003f00 T virAdmConnectNew so this is consistent with the above but different from what you're seeing. This binutils 2.25 in case this matters. I think having a local: *; Is a good think to have in any case. Cheers, -- Guido
On Wed, Aug 12, 2015 at 01:49:46PM +0200, Guido Günther wrote:
On Wed, Aug 12, 2015 at 11:15:58AM +0100, Daniel P. Berrange wrote:
On Tue, Aug 11, 2015 at 09:24:59PM +0200, Guido Günther wrote:
Otherwise we're leaking some 30+ symbols like
virAdmConnectClass virAdmConnectNew virConnectClass virConnectCloseCallbackDataClass virDomainClass ...
I marked the one symbol needed by the deamon as LIBVIRT_ADMIN_PRIVATE_<VERSION> for now.
How are you identifying those as leaked ?
I tripped on this by dpkg-gensymbols[1] which uses objdump.
objdump -w --dynamic-syms src/.libs/libvirt-admin.so | grep " g "
The g meaning global visibility. A similar result can be achieved with "nm -D".
IIRC, exports are those symbols marked with 'T' in the nm output:
[man nm] · The symbol type. At least the following types are used; others are, as well, depending on the object file format. If lowercase, the symbol is usually local; if uppercase, the symbol is global (external). There are however a few lowercase symbols that are shown for special global symbols ("u", "v" and "w").
"T" "t" The symbol is in the text (code) section. [/man]
# nm -a .libs/libvirt-admin.so | grep ' T ' 0000000000001c80 T virAdmConnectClose 00000000000017d0 T virAdmConnectOpen 0000000000001d30 T virAdmConnectRef
# nm -a .libs/libvirt-admin.so | grep virAdmConnectNew 00000000000037c0 t virAdmConnectNew
So, IIUC, that lowercase 't' means the symol is local, and exported.
I'm seeing
0000000000003f00 T virAdmConnectNew
so this is consistent with the above but different from what you're seeing. This binutils 2.25 in case this matters. I think having a
local: *;
Is a good think to have in any case.
Yeah, that's probably right. BTW, can you check libvirt-lxc.so and libvirt-qemu.so too as they don't have the 'local: *' bit in their syms files either AFAICT. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
On Wed, Aug 12, 2015 at 01:07:46PM +0100, Daniel P. Berrange wrote:
On Wed, Aug 12, 2015 at 01:49:46PM +0200, Guido Günther wrote:
On Wed, Aug 12, 2015 at 11:15:58AM +0100, Daniel P. Berrange wrote:
On Tue, Aug 11, 2015 at 09:24:59PM +0200, Guido Günther wrote:
Otherwise we're leaking some 30+ symbols like
virAdmConnectClass virAdmConnectNew virConnectClass virConnectCloseCallbackDataClass virDomainClass ...
I marked the one symbol needed by the deamon as LIBVIRT_ADMIN_PRIVATE_<VERSION> for now.
How are you identifying those as leaked ?
I tripped on this by dpkg-gensymbols[1] which uses objdump.
objdump -w --dynamic-syms src/.libs/libvirt-admin.so | grep " g "
The g meaning global visibility. A similar result can be achieved with "nm -D".
IIRC, exports are those symbols marked with 'T' in the nm output:
[man nm] · The symbol type. At least the following types are used; others are, as well, depending on the object file format. If lowercase, the symbol is usually local; if uppercase, the symbol is global (external). There are however a few lowercase symbols that are shown for special global symbols ("u", "v" and "w").
"T" "t" The symbol is in the text (code) section. [/man]
# nm -a .libs/libvirt-admin.so | grep ' T ' 0000000000001c80 T virAdmConnectClose 00000000000017d0 T virAdmConnectOpen 0000000000001d30 T virAdmConnectRef
# nm -a .libs/libvirt-admin.so | grep virAdmConnectNew 00000000000037c0 t virAdmConnectNew
So, IIUC, that lowercase 't' means the symol is local, and exported.
I'm seeing
0000000000003f00 T virAdmConnectNew
so this is consistent with the above but different from what you're seeing. This binutils 2.25 in case this matters. I think having a
local: *;
Is a good think to have in any case.
Yeah, that's probably right. BTW, can you check libvirt-lxc.so and libvirt-qemu.so too as they don't have the 'local: *' bit in their syms files either AFAICT.
They look good: $ objdump -w --dynamic-syms src/.libs/libvirt-lxc.so | grep " g " 0000000000000000 g DO *ABS* 0000000000000000 LIBVIRT_LXC_1.0.4 LIBVIRT_LXC_1.0.4 0000000000001360 g DF .text 0000000000000226 LIBVIRT_LXC_1.0.2 virDomainLxcEnterNamespace 0000000000001590 g DF .text 000000000000044d LIBVIRT_LXC_1.0.4 virDomainLxcEnterSecurityLabel 00000000000010e0 g DF .text 000000000000027b LIBVIRT_LXC_1.0.2 virDomainLxcOpenNamespace 0000000000203030 g D .bss 0000000000000000 Base _end 0000000000203028 g D .data 0000000000000000 Base _edata 0000000000203028 g D .bss 0000000000000000 Base __bss_start 0000000000000000 g DO *ABS* 0000000000000000 LIBVIRT_LXC_1.0.2 LIBVIRT_LXC_1.0.2 0000000000000e20 g DF .init 0000000000000000 Base _init 00000000000019e0 g DF .fini 0000000000000000 Base _fini $ objdump -w --dynamic-syms src/.libs/libvirt-qemu.so | grep " g " 0000000000000000 g DO *ABS* 0000000000000000 LIBVIRT_QEMU_0.9.4 LIBVIRT_QEMU_0.9.4 0000000000001410 g DF .text 00000000000003a9 LIBVIRT_QEMU_1.2.3 virConnectDomainQemuMonitorEventRegister 0000000000203030 g D .bss 0000000000000000 Base _end 0000000000203028 g D .data 0000000000000000 Base _edata 00000000000011e0 g DF .text 0000000000000226 LIBVIRT_QEMU_0.10.0 virDomainQemuAgentCommand 0000000000000d80 g DF .text 000000000000028b LIBVIRT_QEMU_0.8.3 virDomainQemuMonitorCommand 0000000000000000 g DO *ABS* 0000000000000000 LIBVIRT_QEMU_0.10.0 LIBVIRT_QEMU_0.10.0 0000000000203028 g D .bss 0000000000000000 Base __bss_start 0000000000000b98 g DF .init 0000000000000000 Base _init 0000000000001010 g DF .text 00000000000001ca LIBVIRT_QEMU_0.9.4 virDomainQemuAttach 0000000000001984 g DF .fini 0000000000000000 Base _fini 00000000000017c0 g DF .text 00000000000001c1 LIBVIRT_QEMU_1.2.3 virConnectDomainQemuMonitorEventDeregister 0000000000000000 g DO *ABS* 0000000000000000 LIBVIRT_QEMU_0.8.3 LIBVIRT_QEMU_0.8.3 0000000000000000 g DO *ABS* 0000000000000000 LIBVIRT_QEMU_1.2.3 LIBVIRT_QEMU_1.2.3 Cheers, -- Guido
participants (3)
-
Daniel P. Berrange -
Guido Günther -
Martin Kletzander