Re: [Bug general/24000] couple of testsuite fails with uclibc library
Hi, >>> Don't disable symbol versioning, without it binary compatibility is broken. >> >> As per the following commit disabled symbol versioning for uclibc >> https://sourceware.org/git/?p=elfutils.git;a=commit; >> h=bafacacaf7659a4933604662daba26a480b29a8d >> >> with uclibc,the test suite hangs in middle when compiled with Symbol >> versioning > > hmmm. I think that commit might have been a mistake in hindsight. The option to disable symbol versioning is appreciated here. I don't think it's a mistake. There are platforms which don't support symbol versioning at all. best, Ulf
[Bug general/24000] couple of testsuite fails with uclibc library
https://sourceware.org/bugzilla/show_bug.cgi?id=24000 --- Comment #15 from selva --- (In reply to Mark Wielaard from comment #14) > Created attachment 11614 [details] > Handle malloc(0) specially when decompressing > > Sorry, that patch was clearly untested. This one is. Thanks,With this patch test passed. PASS: run-elfputzdata.sh -- You are receiving this mail because: You are on the CC list for the bug.
Symbol versioning (Was: [Bug general/24000] couple of testsuite fails with uclibc library)
On Tue, Feb 19, 2019 at 07:59:53AM +, Ulf Hermann wrote: > >>> Don't disable symbol versioning, without it binary compatibility is > >>> broken. > >> As per the following commit disabled symbol versioning for uclibc > >> https://sourceware.org/git/?p=elfutils.git;a=commit; > >> h=bafacacaf7659a4933604662daba26a480b29a8d > >> > >> with uclibc,the test suite hangs in middle when compiled with Symbol > >> versioning > > > > hmmm. I think that commit might have been a mistake in hindsight. > > The option to disable symbol versioning is appreciated here. I don't > think it's a mistake. There are platforms which don't support symbol > versioning at all. The problem is that without it every elfutils release would (possibly) break the ABI between the shared libraries and programs using them. And we don't have/use a different mechanism to indicate symbols/ABI changed. How do you prevent things breaking when upgrading the elfutils libraries? Cheers, Mark
Re: Symbol versioning (Was: [Bug general/24000] couple of testsuite fails with uclibc library)
> The problem is that without it every elfutils release would (possibly) > break the ABI between the shared libraries and programs using them. > And we don't have/use a different mechanism to indicate symbols/ABI > changed. How do you prevent things breaking when upgrading the > elfutils libraries? I ship the version of elfutils the application links against with the application. That is common practice on windows (and also on e.g. macOS). The concept of package management only exist on some platforms and only in this context symbol versioning makes sense. Even on linux, with things like flatpak, binary compatibility between different versions of a library becomes less important. best, Ulf
Re: Symbol versioning (Was: [Bug general/24000] couple of testsuite fails with uclibc library)
On Tue, Feb 19, 2019 at 11:30:08AM +, Ulf Hermann wrote: > > The problem is that without it every elfutils release would (possibly) > > break the ABI between the shared libraries and programs using them. > > And we don't have/use a different mechanism to indicate symbols/ABI > > changed. How do you prevent things breaking when upgrading the > > elfutils libraries? > > I ship the version of elfutils the application links against with the > application. That is common practice on windows (and also on e.g. > macOS). The concept of package management only exist on some platforms > and only in this context symbol versioning makes sense. Even on linux, > with things like flatpak, binary compatibility between different > versions of a library becomes less important. It might work if you always compile everything from source (but even then you need to at least keep API source compatible) and link statically. But even things like flatpak support runtimes/libraries. As it turns out elfutils is part of the freedesktop base sdk, so even when using such packaging setup it still is important for elfutils to keep ABI. My point is more that if we disable symbol versioning we have to make it much more clear that the resulting shared libaries aren't really usable as "normal". Cheers, Mark
[Bug general/24000] couple of ELF compression testsuite fails with uclibc library
https://sourceware.org/bugzilla/show_bug.cgi?id=24000 Mark Wielaard changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Summary|couple of testsuite fails |couple of ELF compression |with uclibc library |testsuite fails with uclibc ||library --- Comment #16 from Mark Wielaard --- Thanks for testing. I pushed this: commit ff7fe986679b0811591ef6e40cf485fa9f037e07 Author: Mark Wielaard Date: Tue Feb 19 16:27:40 2019 +0100 libelf: Handle zero size decompressed data. This is a corner case that will most likely never occur in practice, but we have several testcases that compress and decompress zero sized data. In that case during decompression we might malloc a buffer of size zero. It is allowed for malloc to return NULL in that case. But we do need a non-NULL buffer to return and set as result. So make sure to always at least allocate one byte. Also make sure that we don't allocate a zero sized conversion buffer for the data. https://sourceware.org/bugzilla/show_bug.cgi?id=24000 Signed-off-by: Mark Wielaard Lets close this bug. Could you please open a new bug in case you still see other testsuite failures? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug general/24240] New: couple of elftuiltls testsuite fails with uclibc library
https://sourceware.org/bugzilla/show_bug.cgi?id=24240 Bug ID: 24240 Summary: couple of elftuiltls testsuite fails with uclibc library Product: elfutils Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: general Assignee: unassigned at sourceware dot org Reporter: ksd.selvakumar at yahoo dot in CC: elfutils-devel at sourceware dot org Target Milestone: --- Created attachment 11621 --> https://sourceware.org/bugzilla/attachment.cgi?id=11621&action=edit Complete testsuite log When elfutils is compiled against uclibc i got the below memory exhaust with eu-elflint eu-elflint src/nm.o invalid machine flags: 0x500 eu-elflint: memory exhausted Attached the whole testsuite log. Reference https://sourceware.org/bugzilla/show_bug.cgi?id=24000 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug general/24000] couple of ELF compression testsuite fails with uclibc library
https://sourceware.org/bugzilla/show_bug.cgi?id=24000 --- Comment #17 from selva --- (In reply to Mark Wielaard from comment #16) > Thanks for testing. I pushed this: > > commit ff7fe986679b0811591ef6e40cf485fa9f037e07 > Author: Mark Wielaard > Date: Tue Feb 19 16:27:40 2019 +0100 > > libelf: Handle zero size decompressed data. > > This is a corner case that will most likely never occur in practice, > but we have several testcases that compress and decompress zero sized > data. In that case during decompression we might malloc a buffer of > size zero. It is allowed for malloc to return NULL in that case. But > we do need a non-NULL buffer to return and set as result. So make sure > to always at least allocate one byte. Also make sure that we don't > allocate a zero sized conversion buffer for the data. > > https://sourceware.org/bugzilla/show_bug.cgi?id=24000 > > Signed-off-by: Mark Wielaard > > Lets close this bug. > > Could you please open a new bug in case you still see other testsuite > failures? Thanks, opened new one. https://sourceware.org/bugzilla/show_bug.cgi?id=24240 -- You are receiving this mail because: You are on the CC list for the bug.
