Re: Golang binary dwarf
* Mark Wielaard:
> Hi Manoj,
>
> On Sat, 2021-02-06 at 07:03 +, Manoj Kumar via Elfutils-devel
> wrote:
>> Hi,Using dyninst, I am trying to access local variables and arguments
>> of a function which is part of a go binary.To get local variables,
>> dyninst uses libdw to find all the modules. It uses dwarf_nextcu
>> function of libdw to find all the modules of binary.When I compile a
>> go binary using "go build filename.go" then dwarf_nextcu finds all
>> the modules (almost 118) and dyninst is able to access local
>> variables and arguments of any function.But when I compile a go
>> binary with linkshared option "go build -linkshared filename.go"
>> then dwarf_nextcu finds only 5 modules. Due to that, dyninst is not
>> able to access any variable of a function.
>> Does go binary with linkshared option has different version of dwarf?
>> Could you please suggest how to use libdw for go binary with
>> linkshared option.
>
> Could you explain what the linkshared option is and what it does?
$ go tool link -help
[…]
-linkshared
link against installed Go shared libraries
[…]
The Fedora version is broken, unfortunately:
$ cat t.go
package main
func main() { }
$ go build -linkshared t.go
go build runtime/internal/sys: copying
/home/fweimer/.cache/go-build/ef/ef8092ebd194e7ec34c864584fc2216541454e9626c98ffe9d5210d2784da429-d:
open /usr/lib/golang/pkg/linux_amd64_dynlink/runtime/internal/sys.a:
permission denied
go build internal/cpu: copying
/home/fweimer/.cache/go-build/ca/ca0a2dbbc130aa21613ca27f378b8c9fda02c4082687d92b40a0d6c660bc86d1-d:
open /usr/lib/golang/pkg/linux_amd64_dynlink/internal/cpu.a: permission denied
[…]
$ rpm -qf /usr/bin/go
golang-bin-1.15.7-1.fc33.x86_64
Filed here:
So I'm not sure how we can reproduce the elfutils issue. 8-/
Thanks,
Florian
--
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill
Re: Golang binary dwarf
Hi,
Apologies for replying late. The issue can be reproduced on Ubuntu.
Please get the attached files & copy to some folder. If golang and Dyninst
10.2.1 version are installed on system then please follow the below steps:
1. export PATH_TO_DYNINST_LIB= makeThis will create c++ binary testfile
2. compile golang program usinggo build wrapecho.goThis will create wrapechoRun
wrapecho (./wrapecho) from terminal 1 and run testfile (./testfile wrapecho)
from terminal 2.
testfile will print the number of arguments and each argument name for each
function of wrapecho (like Hellocat,hello)
3. compile golang program using linkshared option
go build -linkshared wrapecho.goThis will create wrapecho
if above command does not work then use below two commands:go install
-buildmode=shared stdgo build -linkshared wrapecho.go
Run wrapecho (./wrapecho) from terminal 1 and run testfile (./testfile
wrapecho)testfile will print 0 number of arguments for each function.
Please let me know if anything is required to reproduce the issue.
Thanks
On Sunday, 7 February, 2021, 4:40:44 pm IST, Florian Weimer
wrote:
* Mark Wielaard:
> Hi Manoj,
>
> On Sat, 2021-02-06 at 07:03 +, Manoj Kumar via Elfutils-devel
> wrote:
>> Hi,Using dyninst, I am trying to access local variables and arguments
>> of a function which is part of a go binary.To get local variables,
>> dyninst uses libdw to find all the modules. It uses dwarf_nextcu
>> function of libdw to find all the modules of binary.When I compile a
>> go binary using "go build filename.go" then dwarf_nextcu finds all
>> the modules (almost 118) and dyninst is able to access local
>> variables and arguments of any function.But when I compile a go
>> binary with linkshared option "go build -linkshared filename.go"
>> then dwarf_nextcu finds only 5 modules. Due to that, dyninst is not
>> able to access any variable of a function.
>> Does go binary with linkshared option has different version of dwarf?
>> Could you please suggest how to use libdw for go binary with
>> linkshared option.
>
> Could you explain what the linkshared option is and what it does?
$ go tool link -help
[…]
-linkshared
link against installed Go shared libraries
[…]
The Fedora version is broken, unfortunately:
$ cat t.go
package main
func main() { }
$ go build -linkshared t.go
go build runtime/internal/sys: copying
/home/fweimer/.cache/go-build/ef/ef8092ebd194e7ec34c864584fc2216541454e9626c98ffe9d5210d2784da429-d:
open /usr/lib/golang/pkg/linux_amd64_dynlink/runtime/internal/sys.a:
permission denied
go build internal/cpu: copying
/home/fweimer/.cache/go-build/ca/ca0a2dbbc130aa21613ca27f378b8c9fda02c4082687d92b40a0d6c660bc86d1-d:
open /usr/lib/golang/pkg/linux_amd64_dynlink/internal/cpu.a: permission denied
[…]
$ rpm -qf /usr/bin/go
golang-bin-1.15.7-1.fc33.x86_64
Filed here:
So I'm not sure how we can reproduce the elfutils issue. 8-/
Thanks,
Florian
--
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill
Makefile
Description: Binary data
#include
#include
#include
#include
using namespace std;
// Command line parsing
#include
// DyninstAPI includes
#include "BPatch.h"
#include "BPatch_binaryEdit.h"
#include "BPatch_flowGraph.h"
#include "BPatch_function.h"
#include "BPatch_point.h"
#include "BPatch_object.h"
#include "BPatch_module.h"
#include "Type.h"
#ifdef HAVE_SELINUX
#include
#endif
using namespace Dyninst;
/* Every Dyninst mutator needs to declare one instance of BPatch */
BPatch bpatch;
int main (int argc, char *argv[])
{
if(argc < 2) {
cerr << "./codeCoverage inputbinary" << endl;
return EXIT_FAILURE;
}
char *inputprogram = argv[1];
pid_t pid ;
char line[512];
FILE * command = NULL;
char strPID[100];
sprintf(strPID,"pidof -s %s",inputprogram);
command = popen(strPID,"r");
fgets(line,512,command);
pid = strtoul(line,NULL,10);
pclose(command);
cerr << "pid of process " << pid << endl;
BPatch_addressSpace* app2 = bpatch.processAttach (NULL, pid);
if (app2 == NULL) {
cerr << "Failed to attach to the process" << endl;
return EXIT_FAILURE;
}
BPatch_process* appProc = dynamic_cast(app2);
if (appProc == NULL ) {
cerr << "BPatch_process is NULL" << endl;
return EXIT_FAILURE;
}
BPatch_image *appImage = appProc->getImage ();
if (appImage == NULL) {
cerr << "Failed to get image" << endl;
return EXIT_FAILURE;
}
vector < BPatch_module * >*modules = appImage->getModules ();
vector < BPatch_module * >::iterator moduleIter;
for (moduleIter = modules->begin (); moduleIter != modules->end ();
++moduleIter) {
char moduleName[1024];
(*moduleIter)->getName (moduleName, 10
Re: Golang binary dwarf
Hi, On Sun, 2021-02-07 at 14:54 +, Manoj Kumar wrote: > Apologies for replying late. The issue can be reproduced on Ubuntu. > Please get the attached files & copy to some folder. If golang and > Dyninst 10.2.1 version are installed on system then please follow the > below steps: > 1. export PATH_TO_DYNINST_LIB= libraries are installed, if not under /usr/local/lib>makeThis will > create c++ binary testfile > 2. compile golang program usinggo build wrapecho.goThis will create > wrapechoRun wrapecho (./wrapecho) from terminal 1 and run testfile > (./testfile wrapecho) from terminal 2. > testfile will print the number of arguments and each argument name > for each function of wrapecho (like Hellocat,hello) > 3. compile golang program using linkshared option > go build -linkshared wrapecho.goThis will create wrapecho > if above command does not work then use below two commands:go install > -buildmode=shared stdgo build -linkshared wrapecho.go > > Run wrapecho (./wrapecho) from terminal 1 and run testfile > (./testfile wrapecho)testfile will print 0 number of arguments for > each function. > > Please let me know if anything is required to reproduce the issue. Not having an ubuntu, dyninst or go install I find the above description somewhat confusing. Could you simply generate the binaries yourself and upload them somewhere for inspection or show the DWARF generated for those binaries? What exactly is the output of your program on the different generated binaries? I assume you mean that there are less Compile Units generated in the DWARF than expected. If so I am not sure what elfutils can do about that. It seems a bug in the experimental -sharedlink go linker option. Thanks, Mark
[PATCH] tests: Quote make variables in TESTS_ENVIRONMENT
Commit eb922a1b8f3a ("tests: use ${CC} instead of 'gcc' in tests")
exports ${CC} into the test environment, but doesn't quote the
value for the assignment. That doesn't work properly if the value
contains whitespace. In a multilib/biarch environment however, it's
common to set CC="gcc -m32" or similar. That causes tests to print
error messages: "/bin/sh: line 2: -m32: command not found".
Fix that by adding quotes around all make variables (not just $CC)
used in setting up TESTS_ENVIRONMENT.
Signed-off-by: Alexander Miller
---
tests/ChangeLog | 4
tests/Makefile.am | 27 ++-
2 files changed, 18 insertions(+), 13 deletions(-)
diff --git a/tests/ChangeLog b/tests/ChangeLog
index 907b635..9dc8dfa 100644
--- a/tests/ChangeLog
+++ b/tests/ChangeLog
@@ -1,3 +1,7 @@
+2021-02-07 Alexander Miller
+
+ * Makefile.am (TESTS_ENVIRONMENT): Quote variables.
+
2021-02-04 Frank Ch. Eigler
* run-debuginfod-find.sh: Smoke test --fdcache-mintmp option handling.
diff --git a/tests/Makefile.am b/tests/Makefile.am
index c145720..d6802d8 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -515,32 +515,33 @@ valgrind_cmd='valgrind -q --leak-check=full
--error-exitcode=1'
endif
-installed_TESTS_ENVIRONMENT = libdir=$(DESTDIR)$(libdir); \
- bindir=$(DESTDIR)$(bindir); \
+installed_TESTS_ENVIRONMENT = libdir='$(DESTDIR)$(libdir)'; \
+ bindir='$(DESTDIR)$(bindir)'; \
LC_ALL=C; LANG=C; \
- VALGRIND_CMD=$(valgrind_cmd); \
- abs_srcdir=$(abs_srcdir); \
- abs_builddir=$(abs_builddir); \
- abs_top_builddir=$(abs_top_builddir); \
+ VALGRIND_CMD='$(valgrind_cmd)'; \
+ abs_srcdir='$(abs_srcdir)'; \
+ abs_builddir='$(abs_builddir)'; \
+ abs_top_builddir='$(abs_top_builddir)'; \
export abs_srcdir; export abs_builddir; \
export abs_top_builddir; \
export libdir; export bindir; \
export LC_ALL; export LANG; export VALGRIND_CMD; \
unset DEBUGINFOD_URLS; \
- NM=$(NM); export NM; \
- CC=$(CC); export CC;
+ NM='$(NM)'; export NM; \
+ CC='$(CC)'; export CC;
installed_LOG_COMPILER = $(abs_srcdir)/test-wrapper.sh \
installed $(tests_rpath) \
'$(program_transform_name)'
-TESTS_ENVIRONMENT = LC_ALL=C; LANG=C; VALGRIND_CMD=$(valgrind_cmd); \
- abs_srcdir=$(abs_srcdir); abs_builddir=$(abs_builddir); \
- abs_top_builddir=$(abs_top_builddir); \
+TESTS_ENVIRONMENT = LC_ALL=C; LANG=C; VALGRIND_CMD='$(valgrind_cmd)'; \
+ abs_srcdir='$(abs_srcdir)'; \
+ abs_builddir='$(abs_builddir)'; \
+ abs_top_builddir='$(abs_top_builddir)'; \
export abs_srcdir; export abs_builddir; \
export abs_top_builddir; \
export LC_ALL; export LANG; export VALGRIND_CMD; \
unset DEBUGINFOD_URLS; \
- NM=$(NM); export NM; \
- CC=$(CC); export CC;
+ NM='$(NM)'; export NM; \
+ CC='$(CC)'; export CC;
LOG_COMPILER = $(abs_srcdir)/test-wrapper.sh \
$(abs_top_builddir)/libdw:$(abs_top_builddir)/backends:$(abs_top_builddir)/libelf:$(abs_top_builddir)/libasm:$(abs_top_builddir)/debuginfod
--
2.26.2
Re: Golang binary dwarf
Hi, I can upload the go binaries. Dyninst libraries have huge size so can't send those. Please let me know should I upload the go binaries? Program OutputProgram without linkshared option is able to find the arguments of any function and displays number of arguments with their names but a program with linkshared option can't find any argument. It's correct that there are less compiled units generated for a program with linkshared option. I think go binaries generated with linkshared option may have different dwarf. How to get the dwarf generated code for any binary? Please help me on that. Sorry I'm not aware with this. Thanks On Sunday, 7 February, 2021, 08:48:25 pm IST, Mark Wielaard wrote: Hi, On Sun, 2021-02-07 at 14:54 +, Manoj Kumar wrote: > Apologies for replying late. The issue can be reproduced on Ubuntu. > Please get the attached files & copy to some folder. If golang and > Dyninst 10.2.1 version are installed on system then please follow the > below steps: > 1. export PATH_TO_DYNINST_LIB= libraries are installed, if not under /usr/local/lib>makeThis will > create c++ binary testfile > 2. compile golang program usinggo build wrapecho.goThis will create > wrapechoRun wrapecho (./wrapecho) from terminal 1 and run testfile > (./testfile wrapecho) from terminal 2. > testfile will print the number of arguments and each argument name > for each function of wrapecho (like Hellocat,hello) > 3. compile golang program using linkshared option > go build -linkshared wrapecho.goThis will create wrapecho > if above command does not work then use below two commands:go install > -buildmode=shared stdgo build -linkshared wrapecho.go > > Run wrapecho (./wrapecho) from terminal 1 and run testfile > (./testfile wrapecho)testfile will print 0 number of arguments for > each function. > > Please let me know if anything is required to reproduce the issue. Not having an ubuntu, dyninst or go install I find the above description somewhat confusing. Could you simply generate the binaries yourself and upload them somewhere for inspection or show the DWARF generated for those binaries? What exactly is the output of your program on the different generated binaries? I assume you mean that there are less Compile Units generated in the DWARF than expected. If so I am not sure what elfutils can do about that. It seems a bug in the experimental -sharedlink go linker option. Thanks, Mark
Re: Golang binary dwarf
Hi Manoj, On Sun, Feb 07, 2021 at 04:10:20PM +, Manoj Kumar wrote: > I can upload the go binaries. Dyninst libraries have huge size so > can't send those. Please let me know should I upload the go > binaries? Program OutputProgram without linkshared option is able > to find the arguments of any function and displays number of > arguments with their names but a program with linkshared option > can't find any argument. It's correct that there are less compiled > units generated for a program with linkshared option. I think go > binaries generated with linkshared option may have different dwarf. > How to get the dwarf generated code for any binary? Please help me > on that. Sorry I'm not aware with this. Just the go binaries with/without -linkshared option should be enough to see what is going on. Thanks, Mark
Re: Golang binary dwarf
Sure. I will upload them in an hour. On Sunday, 7 February, 2021, 09:47:07 pm IST, Mark Wielaard wrote: Hi Manoj, On Sun, Feb 07, 2021 at 04:10:20PM +, Manoj Kumar wrote: > I can upload the go binaries. Dyninst libraries have huge size so > can't send those. Please let me know should I upload the go > binaries? Program OutputProgram without linkshared option is able > to find the arguments of any function and displays number of > arguments with their names but a program with linkshared option > can't find any argument. It's correct that there are less compiled > units generated for a program with linkshared option. I think go > binaries generated with linkshared option may have different dwarf. > How to get the dwarf generated code for any binary? Please help me > on that. Sorry I'm not aware with this. Just the go binaries with/without -linkshared option should be enough to see what is going on. Thanks, Mark
Re: Golang binary dwarf
Please confirm if you have got the binaries.I got failure message for elfutils-devel@sourceware.org On Sunday, 7 February, 2021, 10:42:47 pm IST, Manoj Kumar wrote: Please get the attached binaries. Please remove txt extension. md5sum wrapecho 2960d6232f818c4df8c9a8a30c4dd6d9md5sum wrapecho_linkshared 45ccbec2760ace5b37c145dfb0b102ae On Sunday, 7 February, 2021, 9:48:15 pm IST, Manoj Kumar wrote: Sure. I will upload them in an hour. On Sunday, 7 February, 2021, 09:47:07 pm IST, Mark Wielaard wrote: Hi Manoj, On Sun, Feb 07, 2021 at 04:10:20PM +, Manoj Kumar wrote: > I can upload the go binaries. Dyninst libraries have huge size so > can't send those. Please let me know should I upload the go > binaries? Program OutputProgram without linkshared option is able > to find the arguments of any function and displays number of > arguments with their names but a program with linkshared option > can't find any argument. It's correct that there are less compiled > units generated for a program with linkshared option. I think go > binaries generated with linkshared option may have different dwarf. > How to get the dwarf generated code for any binary? Please help me > on that. Sorry I'm not aware with this. Just the go binaries with/without -linkshared option should be enough to see what is going on. Thanks, Mark
Re: Golang binary dwarf
On Sun, Feb 07, 2021 at 05:16:27PM +, Manoj Kumar wrote: > Please confirm if you have got the binaries. > I got failure message for elfutils-devel@sourceware.org I got them, but they were really big: $ du -h echobin.tar.gz wrapecho* 7.7Mechobin.tar.gz 11M wrapecho_linkshared.txt 7.4Mwrapecho.txt What does wrapecho do? Looking at them it seems the wrapecho_linkshared variant (even though it is larger than the non-linkshared variant) simply dropped all debuginfo generated by the Go compiler: $ eu-readelf --debug-dump=info wrapecho.txt | grep producer | sort | uniq -c 1producer (string) "GNU AS 2.25" 147producer (string) "Go cmd/compile go1.15.1" 2producer (strp) "GNU C11 6.5.0 20181026" 16producer (strp) "GNU C 4.9.2" $ eu-readelf --debug-dump=info wrapecho_linkshared.txt | grep producer | sort | uniq -c 1producer (string) "GNU AS 2.26.1" 18producer (strp) "GNU C11 6.5.0 20181026" So the information you want to extract from them is simply not there for the Go compiler generated functions. This is probably a bug you should produce to the Go language team or Ubuntu (if it is specific to their packaging). Cheers, Mark
Re: Golang binary dwarf
Wrapecho starts a local server on port 1323. It provides handlers for url localhost:1323/ and localhost:1323/cat. The handlers simply execute some user defined code. Sure I will contact th golang team. Thanks for providing the details. On Sunday, 7 February, 2021, 10:58:26 pm IST, Mark Wielaard wrote: On Sun, Feb 07, 2021 at 05:16:27PM +, Manoj Kumar wrote: > Please confirm if you have got the binaries. > I got failure message for elfutils-devel@sourceware.org I got them, but they were really big: $ du -h echobin.tar.gz wrapecho* 7.7M echobin.tar.gz 11M wrapecho_linkshared.txt 7.4M wrapecho.txt What does wrapecho do? Looking at them it seems the wrapecho_linkshared variant (even though it is larger than the non-linkshared variant) simply dropped all debuginfo generated by the Go compiler: $ eu-readelf --debug-dump=info wrapecho.txt | grep producer | sort | uniq -c 1 producer (string) "GNU AS 2.25" 147 producer (string) "Go cmd/compile go1.15.1" 2 producer (strp) "GNU C11 6.5.0 20181026" 16 producer (strp) "GNU C 4.9.2" $ eu-readelf --debug-dump=info wrapecho_linkshared.txt | grep producer | sort | uniq -c 1 producer (string) "GNU AS 2.26.1" 18 producer (strp) "GNU C11 6.5.0 20181026" So the information you want to extract from them is simply not there for the Go compiler generated functions. This is probably a bug you should produce to the Go language team or Ubuntu (if it is specific to their packaging). Cheers, Mark
[Bug general/27366] New: 0.183: test suite is failing on linking dwfl-proc-attach
https://sourceware.org/bugzilla/show_bug.cgi?id=27366 Bug ID: 27366 Summary: 0.183: test suite is failing on linking dwfl-proc-attach Product: elfutils Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: general Assignee: unassigned at sourceware dot org Reporter: kloczko.tomasz at gmail dot com CC: elfutils-devel at sourceware dot org Target Milestone: --- [tkloczko@barrel tests]$ make dwfl-proc-attach gcc -std=gnu99 -Wall -Wshadow -Wformat=2 -Wold-style-definition -Wstrict-prototypes -Wtrampolines -Wlogical-op -Wduplicated-cond -Wnull-dereference -Wimplicit-fallthrough=5 -Werror -Wunused -Wextra -Wstack-usage=262144 -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -flto=auto -flto-partition=none -fdata-sections -ffunction-sections -Wformat -Wno-error=stack-usage= -pthread -Wl,-rpath-link,../libasm:../libdw:../libelf -Wl,-z,relro -Wl,--as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -flto=auto -flto-partition=none -fuse-linker-plugin -Wl,--gc-sections -o dwfl-proc-attach dwfl-proc-attach.o ../libdw/libdw.so /usr/bin/ld: dwfl-proc-attach.o (symbol from plugin): undefined reference to symbol 'dlopen@@GLIBC_2.2.5' /usr/bin/ld: /usr/lib64/libdl.so.2: error adding symbols: DSO missing from command line collect2: error: ld returned 1 exit status make: *** [Makefile:1940: dwfl-proc-attach] Error 1 On first look it looks like missing -ldl on linking. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug general/27366] 0.183: test suite is failing on linking dwfl-proc-attach
https://sourceware.org/bugzilla/show_bug.cgi?id=27366 --- Comment #1 from kloczek --- No I was wrong. But is still fails using glibc, gcc and binutils from rawride. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug general/27366] 0.183: test suite is failing on linking dwfl-proc-attach
https://sourceware.org/bugzilla/show_bug.cgi?id=27366 Mark Wielaard changed: What|Removed |Added CC||mark at klomp dot org --- Comment #2 from Mark Wielaard --- (In reply to kloczek from comment #1) > But is still fails using glibc, gcc and binutils from rawride. That is odd. I just did a build on rawhide that looks fine: https://koji.fedoraproject.org/koji/buildinfo?buildID=1704647 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug general/27366] 0.183: test suite is failing on linking dwfl-proc-attach
https://sourceware.org/bugzilla/show_bug.cgi?id=27366
--- Comment #3 from Mark Wielaard ---
I see you are using -flto=auto. Sadly LTO isn't supported at the moment.
Although it would be nice if it didn't totally break with -flto-partition=none.
The problem with lto might be:
/* HACK. This is a simple workaround for a combination of old glibc
and valgrind. libdw will try to dlopen libdebuginfod this causes
some unsuppressable memory leak warnings when the process is
multi-threaded under valgrind because of some bad backtraces.
So simply override dlopen and always return NULL so libdebuginfod
(and libcurl) are never loaded. This test doesn't rely on
libdebuginfod anyway. */
void *dlopen (void)
{
return NULL;
}
Maybe it needs some __attribute__((__used__)) to make sure it is kept around?
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug general/27366] 0.183: test suite is failing on linking dwfl-proc-attach (with lto)
https://sourceware.org/bugzilla/show_bug.cgi?id=27366 Mark Wielaard changed: What|Removed |Added Summary|0.183: test suite is|0.183: test suite is |failing on linking |failing on linking |dwfl-proc-attach|dwfl-proc-attach (with lto) -- You are receiving this mail because: You are on the CC list for the bug.
