On Tue, 26 Feb 2019, Tom de Vries wrote:
>>> Specifically I am now seeing
>>>
>>> gmake[4]: *** No rule to make target 'b3test_dwz_buildid',
>>> needed by 'b3test_dwz_buildid.log'.
> The only way of reproducing it was to deinstall dwz.
:
> Fixed in patch below, committed as trivial.
Great, th
On 25-02-19 21:03, Tom de Vries wrote:
> On 25-02-19 15:12, Gerald Pfeifer wrote:
>> Specifically I am now seeing
>>
>> gmake[4]: *** No rule to make target 'b3test_dwz_buildid',
>> needed by 'b3test_dwz_buildid.log'.
>>
>> in my build/test logs. (Note, this is GNU make 4.2.1, so might reprod
On 25-02-19 15:12, Gerald Pfeifer wrote:
> Specifically I am now seeing
>
> gmake[4]: *** No rule to make target 'b3test_dwz_buildid',
> needed by 'b3test_dwz_buildid.log'.
>
> in my build/test logs. (Note, this is GNU make 4.2.1, so might reproduce
> on your SUSE systems as well?)
Hi Ger
Hi Tom,
I'm afraid this triggers on my (FreeBSD-based) testers:
2019-01-29 Tom de Vries
* install-debuginfo-for-buildid.sh.in: New script.
* Makefile.am (check_PROGRAMS): Add b2test and b3test.
(TESTS): Add b2test_buildid and b3test_dwz_buildid.
* Makefile.in
On Tue, Jan 29, 2019 at 3:17 PM Segher Boessenkool
wrote:
>
> On Sun, Jan 27, 2019 at 01:53:18PM -0800, Ian Lance Taylor wrote:
> > 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 t
On Sun, Jan 27, 2019 at 01:53:18PM -0800, Ian Lance Taylor wrote:
> 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.
Or you just set .DELETE_ON_ERROR, we requir
On Tue, Jan 29, 2019 at 12:24 AM Tom de Vries wrote:
>
> On 27-01-19 22:53, Ian Lance Taylor wrote:
> > On Sun, Jan 27, 2019 at 1:16 PM Tom de Vries 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
cktrace. 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
On Sun, Jan 27, 2019 at 1:16 PM Tom de Vries 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
> >
est-cases b2test_buildid and b3test_dwz_buildid.
The last one triggers the segfault fixed by "[backtrace] Avoid segfault"
( r268275 ).
2019-01-27 Tom de Vries
* Makefile.am (check_PROGRAMS): Add b2test and b3test.
(TESTS): Add b2test_buildid, b3test_dwz and b3test_dwz_bu
On Fri, Jan 25, 2019 at 12:15:28PM -0500, 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) mentio
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
On Fri, Jan 25, 2019 at 5:27 AM Tom de Vries wrote:
>
> On 25-01-19 14:17, Tom de Vries wrote:
> > On 25-01-19 01:51, Ian Lance Taylor wrote:
> >> On Thu, Jan 24, 2019 at 4:11 PM Nathan Sidwell wrote:
> >>>
> >>> I just tripped over a segfault in libbacktrace. We apply strrchr to a
> >>> possibl
On Fri, Jan 25, 2019 at 5:17 AM Tom de Vries wrote:
>
> On 25-01-19 01:51, Ian Lance Taylor wrote:
> > On Thu, Jan 24, 2019 at 4:11 PM Nathan Sidwell wrote:
> >>
> >> I just tripped over a segfault in libbacktrace. We apply strrchr to a
> >> possibly NULL filename, with predictable results when
On 25-01-19 14:17, Tom de Vries wrote:
> On 25-01-19 01:51, Ian Lance Taylor wrote:
>> On Thu, Jan 24, 2019 at 4:11 PM Nathan Sidwell wrote:
>>>
>>> I just tripped over a segfault in libbacktrace. We apply strrchr to a
>>> possibly NULL filename, with predictable results when it is.
>>>
>>> elf.c
On 25-01-19 01:51, Ian Lance Taylor wrote:
> On Thu, Jan 24, 2019 at 4:11 PM Nathan Sidwell wrote:
>>
>> I just tripped over a segfault in libbacktrace. We apply strrchr to a
>> possibly NULL filename, with predictable results when it is.
>>
>> elf.c:3044 passes NULL as the filename parm:
>>
On Thu, Jan 24, 2019 at 4:11 PM Nathan Sidwell wrote:
>
> I just tripped over a segfault in libbacktrace. We apply strrchr to a
> possibly NULL filename, with predictable results when it is.
>
> elf.c:3044 passes NULL as the filename parm:
> ret = elf_add (state, NULL, d, base_address,
I just tripped over a segfault in libbacktrace. We apply strrchr to a
possibly NULL filename, with predictable results when it is.
elf.c:3044 passes NULL as the filename parm:
ret = elf_add (state, NULL, d, base_address, error_callback, data,
fileline_fn, foun
18 matches
Mail list logo
