On Tue, Jan 29, 2019 at 12:24 AM Tom de Vries <tdevr...@suse.de> wrote: > > On 27-01-19 22:53, Ian Lance Taylor wrote: > > On Sun, Jan 27, 2019 at 1:16 PM Tom de Vries <tdevr...@suse.de> wrote: > >> > >> On 25-01-19 18:15, Nathan Sidwell wrote: > >>> On 1/25/19 5:28 AM, Tom de Vries wrote: > >>>> > >>>> This patch fixes it by passing "" instead of NULL, in the call to > >>>> elf_add at line 3083 (for .gnu_debugaltlink), not the call to elf_add at > >>>> line 3044 (for .gnu_debuglink) mentioned above. > >>>> > >>>> Nathan, does this fix the problem for you? If not, can you provide a > >>>> reproducer, or give a hint on how one could be constructed? > >>> > >>> I still hit the problem, and am installing this as sufficiently obvious. > >>> I'm on a fedora system debugging pr88995. The debuglink_name is > >>> "../../.dwz/isl-0.16.1-7.fc29.x86_64" > >>> > >> > >> I've managed to reproduce this segfault instance by adding a test-case > >> that uses both build-id and dwz. > >> > >> OK for trunk? > > > >> +elf_for_test.c: elf.c > >> + PWD=$$(pwd -P); \ > >> + BUILD_ID_DIR="usr/lib/debug/.build-id/"; \ > >> + SEARCH='#define SYSTEM_BUILD_ID_DIR'; \ > >> + REPLACE="#define SYSTEM_BUILD_ID_DIR \"$$PWD/$$BUILD_ID_DIR\""; \ > >> + $(SED) "s%^$$SEARCH.*\$$%$$REPLACE%" \ > >> + $< \ > >> + > $@ > > > > You need to use a temporary file, such as $@.tmp, for the final sed > > command, followed by a mv to $@. Otherwise a failure in the sed will > > leave what appears to be an up to date file. > > > > Done. > > Also, I've factored out a script install-debuginfo-for-buildid.sh, > hoping this will make things more readable/maintainable. > > > Honestly I'm not sure this patch is worth doing. It adds a lot of > > complex mechanism in order to test a patch that is fairly obvious. > > Agreed, the patch is fairly obvious. > > But at the moment, there's no test-case that exercises the build-id > support in libbacktrace. IMO, that alone would be a good reason to add > this test-case. > > > While it's good practice to add a test for every change, it's not good > > practice for the testsuite to become so complex that it becomes in > > itself difficult to maintain. > > Understood. > > Please let me know if this is acceptable, or if I can do anything that > would make this easier to maintain.
I guess this is OK. Please add a copyright header to the new shell script. Also please add a comment explaining what it does. Thanks. Ian
