Date: Sat, 21 Mar 2020 00:45:41 +0100 From: Willem Jan Withagen <wjw@digiware.nl> To: cem@freebsd.org Cc: "freebsd-virtualization@freebsd.org" <virtualization@freebsd.org> Subject: Re: [RFC] Adding a Rados block driver to bhyve Message-ID: <2d86d513-efe0-d25f-ae20-0fae74afa1bc@digiware.nl> In-Reply-To: <CAG6CVpXDunwwg-oXHFaZrpuiFWxPY5XJ5Xvf3%2BB=wJ7n3Ao2BA@mail.gmail.com> References: <9c7a8dea-ac8a-4d17-ed33-b6c4e882add8@digiware.nl> <CAOtMX2iyhS230oCysYx3YC72B8TwFrrkcXtCoMCYK85KbFORaQ@mail.gmail.com> <c2090191-920b-3d2f-f797-75a448b18ad6@digiware.nl> <CAOtMX2iwJ1_VVDXOnSP6nui-JcYMwndXMex8fxtyi6qEikUX8A@mail.gmail.com> <936ed7c2-99d2-5df8-de3f-f64f28d2ba6f@digiware.nl> <CAOtMX2gKkh=Fik9wjHoAx9Gt9zwePMjmRaGP63eE2quNTmyDGw@mail.gmail.com> <ba937caf-ce4b-eeb9-8915-f9b9910aa711@digiware.nl> <CAG6CVpXDunwwg-oXHFaZrpuiFWxPY5XJ5Xvf3%2BB=wJ7n3Ao2BA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 10-3-2020 19:08, Conrad Meyer wrote: > On Tue, Mar 10, 2020 at 9:28 AM Willem Jan Withagen <wjw@digiware.nl> > wrote: >>>> problem that libblock_rbd.so is stripped in such a way that the >>>> symbol I need is removed. >>> So either I'm doing it the wrong way, like special options on the >>> symbols oid. >>> However, I think there's something wrong with your library, too. The >>> library should be usable even if it's stripped. > Yes, strip only removes local symbols (.symtab), not exported ones > (.dynsym). >> I checked with objdump, and the symbol that I need is definitly not >> present in the stripped version. > How are you defining the symbol intended for export? Is the symbol a > function or data? Does the compiler flag -fvisibility=hidden get used? > Which symbol is missing and what are the symptoms? >> And it does not really matter if I declare it static or not. > Not declaring it "static" is necessary, if not sufficient. Looking at > your code on github, here are some issues: * In block_if.h, you define > an object blocklocal_backend. This is a header, and every compilation > unit that pulls in the header will get its own copy of > blocklocal_backend. You probably want 'extern block_backend_t > blocklocal_backend;' instead. I have fixed this in a different way, so I do not need to play tricks with blocklocal_backend to handle the legacy case.So that is removed. > * You SET_DECLARE block_backend_set in block_if.c, but I think it > needs to be in block_if.h. Looked at the Macro definition, and it is `extern` so it can go into block_if.h > * There is some weirdness around linker sets being removed by the > linker if they are empty, so you may want to add blockbackend_local to > the linker set in the main program. (It's unclear to me why > blockbackend_local is treated specially regardless.) However, I'm not > quite sure why DATA_SET() in block_rbd.c is not creating > __start_set_block_backend_set / __stop_set_block_backend_set exported > symbols. As Alan asked, please provide 'nm -D foo.so'. Best, Conrad It is dynamic loaded with dlopen()/dlsym at the moment. But are you suggesting that a `DATA_SET()` actually adds to the set during dynamic loading? Note that the __start_set_block_backend_set / __stop_set_block_backend_setis avialable in the library. --WjW
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2d86d513-efe0-d25f-ae20-0fae74afa1bc>