[Bug ld/15516] GNU LD is confused when linker plugin turns COMDAT symbol into static w/o renaming.

2013-05-24 Thread marxin.liska at gmail dot com
http://sourceware.org/bugzilla/show_bug.cgi?id=15516 Martin Liška marxin.liska at gmail dot com changed: What|Removed |Added CC

[Bug ld/15516] GNU LD is confused when linker plugin turns COMDAT symbol into static w/o renaming.

2013-05-24 Thread marxin.liska at gmail dot com
MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable html head base href=3Dhttp://sourceware.org/bugzilla/; / /head body p div ba class=3Dbz_bug_link=20 bz_status_RESOLVED bz_closed

[Bug ld/15516] GNU LD is confused when linker plugin turns COMDAT symbol into static w/o renaming.

2013-06-02 Thread marxin.liska at gmail dot com
http://sourceware.org/bugzilla/show_bug.cgi?id=15516 --- Comment #11 from Martin Liška marxin.liska at gmail dot com --- So the bug is really present in binutils trunk (May 24 2013). ld --version: GNU ld (GNU Binutils) 2.23.52.20130524 gcc --version: gcc (GCC) 4.9.0 20130517

[Bug ld/15516] GNU LD is confused when linker plugin turns COMDAT symbol into static w/o renaming.

2013-06-02 Thread marxin.liska at gmail dot com
http://sourceware.org/bugzilla/show_bug.cgi?id=15516 --- Comment #12 from Martin Liška marxin.liska at gmail dot com --- Created attachment 7054 -- http://sourceware.org/bugzilla/attachment.cgi?id=7054action=edit Libreoffice saxparser object files -- You are receiving this mail

[Bug ld/15516] GNU LD is confused when linker plugin turns COMDAT symbol into static w/o renaming.

2013-06-02 Thread marxin.liska at gmail dot com
http://sourceware.org/bugzilla/show_bug.cgi?id=15516 Martin Liška marxin.liska at gmail dot com changed: What|Removed |Added Status|RESOLVED

[Bug gold/15660] New: out of file descriptors and couldn't close any

2013-06-20 Thread marxin.liska at gmail dot com
: gold Assignee: ian at airs dot com Reporter: marxin.liska at gmail dot com CC: ccoutant at google dot com I've encountered similar bug to: http://sourceware.org/bugzilla/show_bug.cgi?id=10708 during linking of chromium binary. ld --version GNU gold (GNU Binutils

[Bug gold/15660] out of file descriptors and couldn't close any

2013-06-20 Thread marxin.liska at gmail dot com
http://sourceware.org/bugzilla/show_bug.cgi?id=15660 --- Comment #3 from Martin Liška marxin.liska at gmail dot com --- ulimit -n 1024 I tried same command line without --start-group/--end-group, but didn't hel p. Next step was to create one large archive, so: ar r [list of all

[Bug gold/15660] out of file descriptors and couldn't close any

2013-06-20 Thread marxin.liska at gmail dot com
http://sourceware.org/bugzilla/show_bug.cgi?id=15660 --- Comment #5 from Martin Liška marxin.liska at gmail dot com --- I did so, thin library was created, but linker is still complaining about f ile descriptors: g++ -Wl,-z,now -Wl,-z,relro -pthread -Wl,-z,noexecstack -fPIC -pie -L. -flt o

[Bug gold/15660] out of file descriptors and couldn't close any

2013-06-20 Thread marxin.liska at gmail dot com
http://sourceware.org/bugzilla/show_bug.cgi?id=15660 --- Comment #7 from Martin Liška marxin.liska at gmail dot com --- I'll try to link it without -flto, but I used -fno-fat-lto-objects. It will take me some time to recompile chromium. Weird is that ld.bfd is able to link the binary

[Bug gold/15660] out of file descriptors and couldn't close any

2014-03-17 Thread marxin.liska at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=15660 --- Comment #11 from Martin Liška marxin.liska at gmail dot com --- There's my out/Release build folder: https://drive.google.com/file/d/0B0pisUJ80pO1UzFGNGJhaW1xbVE/edit?usp=sha ring It's ~3.4GB tar with bzip2 (~6GB extracted). ld

[Bug gold/15660] out of file descriptors and couldn't close any

2014-03-17 Thread marxin.liska at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=15660 --- Comment #12 from Martin Liška marxin.liska at gmail dot com --- Created attachment 7476 -- https://sourceware.org/bugzilla/attachment.cgi?id=7476action=edit ld args and liblto plugin -- You are receiving this mail because: You

[Bug ld/24267] ld discards a symbol with -flto and -static

2019-02-25 Thread marxin.liska at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=24267 Martin Liška changed: What|Removed |Added CC||dave.korn.cygwin at gmail dot com,

[Bug ld/24267] ld discards a symbol with -flto and -static

2019-02-25 Thread marxin.liska at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=24267 --- Comment #4 from Martin Liška --- (In reply to H.J. Lu from comment #3) > (In reply to Martin Liška from comment #2) > > (In reply to H.J. Lu from comment #1) > > > Does it happen on Linux? > > > > No, it's specific to w64-mingw32 target.

[Bug ld/24267] ld discards a symbol with -flto and -static

2019-02-26 Thread marxin.liska at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=24267 --- Comment #8 from Martin Liška --- (In reply to H.J. Lu from comment #7) > (In reply to Martin Liška from comment #6) > > > > > > Not regression. They are LTO bug fixes. > > > > Can you be please more concrete? > > Check PR 23958, PR

[Bug ld/24267] ld discards a symbol with -flto and -static

2019-02-28 Thread marxin.liska at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=24267 --- Comment #11 from Martin Liška --- I've got a patch candidate that can solve it: diff --git a/bfd/coffgen.c b/bfd/coffgen.c index 309e1249ac..1d200b066b 100644 --- a/bfd/coffgen.c +++ b/bfd/coffgen.c @@ -2678,9 +2678,9 @@

[Bug ld/24267] ld discards a symbol with -flto and -static

2019-02-28 Thread marxin.liska at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=24267 --- Comment #13 from Martin Liška --- > > What do ELF linkers (gold and bfd) get? We get: (gdb) p owner_sec->owner->filename $5 = 0x69ae80 "main.o (symbol from plugin)" -- You are receiving this mail because: You are on the CC list for

[Bug ld/24267] ld discards a symbol with -flto and -static

2019-02-28 Thread marxin.liska at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=24267 --- Comment #15 from Martin Liška --- Yes, both return: ... 262 545ca41eb4de6c9c PREVAILING_DEF _ZNKSt5ctypeIcE8do_widenEc -- You are receiving this mail because: You are on the CC list for the bug.

[Bug ld/24267] ld discards a symbol with -flto and -static

2019-02-27 Thread marxin.liska at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=24267 --- Comment #10 from Martin Liška --- > I don't understand much the details but I think what H.J. Lu was trying to > say is that maybe was fixed for ELF but not for PE/COFF so to have a look at > the mentioned PRs. > I cannot suggest any of

[Bug ld/24267] ld discards a symbol with -flto and -static

2019-02-27 Thread marxin.liska at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=24267 Martin Liška changed: What|Removed |Added CC||eliz at gnu dot org -- You are

[Bug ld/24267] ld discards a symbol with -flto and -static

2019-02-27 Thread marxin.liska at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=24267 Martin Liška changed: What|Removed |Added CC||eliz at gnu dot org -- You are

[Bug ld/24267] ld discards a symbol with -flto and -static

2019-03-06 Thread marxin.liska at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=24267 --- Comment #19 from Martin Liška --- H.J. : Can you please help me how to find a place which makes a real decision about which BFD (object) will be used for each symbol? -- You are receiving this mail because: You are on the CC list for

[Bug ld/24267] ld discards a symbol with -flto and -static

2019-02-25 Thread marxin.liska at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=24267 Martin Liška changed: What|Removed |Added Summary|ld discard a symbol with|ld discards a symbol with

[Bug ld/24267] New: ld discard a symbol with -flto and -static

2019-02-25 Thread marxin.liska at gmail dot com
Component: ld Assignee: unassigned at sourceware dot org Reporter: marxin.liska at gmail dot com Target Milestone: --- This is follow up of: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81879 $ cat simpler.ii namespace std { template struct char_traits; template > cl

[Bug ld/24267] ld discard a symbol with -flto and -static

2019-02-25 Thread marxin.liska at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=24267 Martin Liška changed: What|Removed |Added CC||amodra at gmail dot com -- You are

[Bug ld/24267] ld discards a symbol with -flto and -static

2019-03-01 Thread marxin.liska at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=24267 --- Comment #18 from Martin Liška --- > I meant it must be PREVAILING_DEF and can't be PREVAILING_DEF_IRONLY. Yes, PREVAILING_DEF would be fine as well for COFF. -- You are receiving this mail because: You are on the CC list for the bug.

[Bug ld/24267] ld discards a symbol with -flto and -static

2019-02-25 Thread marxin.liska at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=24267 --- Comment #2 from Martin Liška --- (In reply to H.J. Lu from comment #1) > Does it happen on Linux? No, it's specific to w64-mingw32 target. I'm testing that on Linux where I use cross compiler + wine: $ wine --version wine-4.1 -- You

[Bug ld/24267] ld discards a symbol with -flto and -static

2019-03-11 Thread marxin.liska at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=24267 --- Comment #21 from Martin Liška --- (In reply to H.J. Lu from comment #20) > (In reply to Martin Liška from comment #19) > > H.J. : Can you please help me how to find a place which makes a real > > decision about which BFD (object) will be

[Bug ld/24267] ld discards a symbol with -flto and -static

2019-03-12 Thread marxin.liska at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=24267 --- Comment #23 from Martin Liška --- (In reply to H.J. Lu from comment #22) > Works for me with binutils 2.32: > Have you tried to run the binary with wine? You'll probably see something like: wine: Unhandled page fault on read access to

[Bug ld/24267] ld discards a symbol with -flto and -static

2019-03-15 Thread marxin.liska at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=24267 --- Comment #26 from Martin Liška --- (In reply to H.J. Lu from comment #25) > Created attachment 11681 [details] > A patch > > Please try this. Good job H.J. I can confirm it works for a simple test-case and I see: 737 54db81cc670131ad

[Bug gas/24165] fivefold time and memory usage since commit 3ae729d5 on large files generated by lto

2019-02-04 Thread marxin.liska at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=24165 Martin Liška changed: What|Removed |Added CC||marxin.liska at gmail dot com

[Bug gas/24434] Missing testsuite coverage for AVX512F gathers (and scatters?) with no base register

2019-04-10 Thread marxin.liska at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=24434 Martin Liška changed: What|Removed |Added CC||marxin.liska at gmail dot com

[Bug gas/24434] Missing testsuite coverage for AVX512F gathers (and scatters?) with no base register

2019-04-10 Thread marxin.liska at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=24434 --- Comment #3 from Martin Liška --- (In reply to Jan Beulich from comment #2) > (In reply to Martin Liška from comment #1) > > Fixed in bintuils with: > > > > commit 629cfaf1b0fbb32a985607c774bd8e7870b9fa94 (HEAD, refs/bisect/bad) > >

[Bug gas/24434] Missing testsuite coverage for AVX512F gathers (and scatters?) with no base register

2019-04-10 Thread marxin.liska at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=24434 Martin Liška changed: What|Removed |Added CC||jbeulich at novell dot com -- You

[Bug gas/24464] New: rx: Fatal error: Infinite loop encountered whilst attempting to compute the addresses of symbols in section P

2019-04-18 Thread marxin.liska at gmail dot com
: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: gas Assignee: unassigned at sourceware dot org Reporter: marxin.liska at gmail dot com Target Milestone: --- Using rx cross gas I see: $ cat pr90045.s

[Bug gas/24464] rx: Fatal error: Infinite loop encountered whilst attempting to compute the addresses of symbols in section P

2019-04-18 Thread marxin.liska at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=24464 Martin Liška changed: What|Removed |Added CC||hjl.tools at gmail dot com,

[Bug binutils/24768] Stop using __gnu_lto_slim symbol as a detection of a slim LTO object

2019-07-04 Thread marxin.liska at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=24768 --- Comment #1 from Martin Liška --- Created attachment 11883 --> https://sourceware.org/bugzilla/attachment.cgi?id=11883=edit Patch candidate I would appreciate feedback about the patch before I'll send it to the mailing list. -- You

[Bug binutils/24768] Stop using __gnu_lto_slim symbol as a detection of a slim LTO object

2019-07-15 Thread marxin.liska at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=24768 --- Comment #3 from Martin Liška --- > > The layout of this struct depends on the host compiler. Won't that cause > problems in object file portability? You are right, I will change streaming of the structure to be always LE in a ELF file.

[Bug ld/24912] New: g++.dg/lto/pr90990 FAILs with gld 2.32.51

2019-08-16 Thread marxin.liska at gmail dot com
Component: ld Assignee: unassigned at sourceware dot org Reporter: marxin.liska at gmail dot com Target Milestone: --- Copy from https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91376: 've just tried Solaris/SPARC and x86 bootstraps with gas and gld from binutils master. Doing so

[Bug ld/24912] g++.dg/lto/pr90990 FAILs with gld 2.32.51

2019-08-16 Thread marxin.liska at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=24912 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug binutils/24768] Stop using __gnu_lto_slim symbol as a detection of a slim LTO object

2019-07-29 Thread marxin.liska at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=24768 --- Comment #5 from Martin Liška --- Should be implemented now. Let's keep this issue to remove later the usage of __gnu_lto_slim. -- You are receiving this mail because: You are on the CC list for the bug.

[Bug gold/24123] incremental_copy_test failure when building with gcc-9

2019-09-24 Thread marxin.liska at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=24123 Martin Liška changed: What|Removed |Added CC||marxin.liska at gmail dot com -- You

[Bug binutils/25355] nm reports data variable as "T" with -flto

2020-02-12 Thread marxin.liska at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=25355 Martin Liška changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED

[Bug binutils/25355] nm reports data variable as "T" with -flto

2020-02-12 Thread marxin.liska at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=25355 --- Comment #39 from Martin Liška --- > > What is wrong to use the matching lto-wrapper for the plugin being used? It's probably fine. I'm just wondering how to use a locally install GCC to cooperate fine with binutils. -- You are

[Bug binutils/25355] nm reports data variable as "T" with -flto

2020-02-12 Thread marxin.liska at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=25355 --- Comment #40 from Martin Liška --- I will have to start using AR=gcc-ar, ... -- You are receiving this mail because: You are on the CC list for the bug.

[Bug binutils/25355] nm reports data variable as "T" with -flto

2020-02-12 Thread marxin.liska at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=25355 --- Comment #34 from Martin Liška --- I have one more question. It's a quite common case for me that that I do testing of the built GCC : $ export PATH=/home/marxin/bin/gcc/bin/:$PATH && export

[Bug binutils/25355] nm reports data variable as "T" with -flto

2020-02-12 Thread marxin.liska at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=25355 --- Comment #37 from Martin Liška --- > > Which liblto_plugin.so did nm load? Which liblto_plugin.so should nm load? It loads the following plugin: stat("/usr/bin/../lib64/bfd-plugins", 0x7fffd980) = -1 ENOENT (No such file or

[Bug binutils/25355] nm reports data variable as "T" with -flto

2020-02-12 Thread marxin.liska at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=25355 Martin Liška changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|---

[Bug binutils/25640] nm shows symbol as 'U' while showed as 'T'

2020-03-06 Thread marxin.liska at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=25640 --- Comment #2 from Martin Liška --- Heh. Then we should use -flto-partition=none or one. Anyway, to be honest, I'm still not fully convinced about the selected approach (of using LTO for nm). There's still a possibility to extend lto plugin

[Bug binutils/25640] nm shows symbol as 'U' while showed as 'T'

2020-03-06 Thread marxin.liska at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=25640 Martin Liška changed: What|Removed |Added CC||hjl.tools at gmail dot com -- You

[Bug binutils/25640] New: nm shows symbol as 'U' while showed as 'T'

2020-03-06 Thread marxin.liska at gmail dot com
: binutils Assignee: unassigned at sourceware dot org Reporter: marxin.liska at gmail dot com Target Milestone: --- Created attachment 12352 --> https://sourceware.org/bugzilla/attachment.cgi?id=12352=edit test-case Using latest release I see: $ gcc connection.i -O2

[Bug binutils/25640] nm shows symbol as 'U' while showed as 'T'

2020-03-06 Thread marxin.liska at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=25640 --- Comment #5 from Martin Liška --- (In reply to H.J. Lu from comment #4) > Created attachment 12355 [details] > Pass -flto-partition=none to GCC This seems right to me. Anyway, can't we built on something like:

[Bug binutils/25355] nm reports data variable as "T" with -flto

2020-02-18 Thread marxin.liska at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=25355 Martin Liška changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED

[Bug binutils/25355] nm reports data variable as "T" with -flto

2020-02-18 Thread marxin.liska at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=25355 --- Comment #49 from Martin Liška --- If I revert backport of 99845b3b77ed1248b6fb94707f88868bde358ccc, then it's fine. -- You are receiving this mail because: You are on the CC list for the bug.

[Bug binutils/25355] nm reports data variable as "T" with -flto

2020-02-18 Thread marxin.liska at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=25355 --- Comment #53 from Martin Liška --- (In reply to H.J. Lu from comment #52) > Created attachment 12297 [details] > A new patch The patch works for me! Thank you. -- You are receiving this mail because: You are on the CC list for the bug.

[Bug binutils/25355] nm reports data variable as "T" with -flto

2020-02-19 Thread marxin.liska at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=25355 --- Comment #60 from Martin Liška --- (In reply to H.J. Lu from comment #59) > Fixed on master branch. Good. Please pull the revision to the 2.34 branch. -- You are receiving this mail because: You are on the CC list for the bug.

[Bug binutils/25355] nm reports data variable as "T" with -flto

2020-02-21 Thread marxin.liska at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=25355 --- Comment #63 from Martin Liška --- I have one more question about the lto-wrapper usage: is there any reason why 'ar' and 'ranlib' also use it? It makes building of some packages significantly slower. -- You are receiving this mail

[Bug binutils/25355] nm reports data variable as "T" with -flto

2020-02-21 Thread marxin.liska at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=25355 Martin Liška changed: What|Removed |Added See Also||https://sourceware.org/bugz

[Bug binutils/25584] New: ar and ranlib should not call lto-wrapper for LTO bytecode

2020-02-21 Thread marxin.liska at gmail dot com
: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: marxin.liska at gmail dot com Target Milestone: --- It's a follow up of PR25355: https://sourceware.org/bugzilla/show_bug.cgi?id=25355#c63 -- You are receiving

[Bug binutils/25584] ar and ranlib should not call lto-wrapper for LTO bytecode

2020-02-21 Thread marxin.liska at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=25584 Martin Liška changed: What|Removed |Added See Also||https://sourceware.org/bugz

[Bug binutils/25355] nm reports data variable as "T" with -flto

2020-02-21 Thread marxin.liska at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=25355 --- Comment #65 from Martin Liška --- > > Please open a new bug. Sure: https://sourceware.org/bugzilla/show_bug.cgi?id=25584 -- You are receiving this mail because: You are on the CC list for the bug.

[Bug binutils/25584] ar and ranlib should not call lto-wrapper for LTO bytecode

2020-02-21 Thread marxin.liska at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=25584 --- Comment #4 from Martin Liška --- Yes, I used the updated binutils to build a LTO project. -- You are receiving this mail because: You are on the CC list for the bug.

[Bug binutils/25584] ar and ranlib should not call lto-wrapper for LTO bytecode

2020-02-21 Thread marxin.liska at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=25584 --- Comment #2 from Martin Liška --- I can confirm the patch works. -- You are receiving this mail because: You are on the CC list for the bug.

[Bug binutils/25355] nm reports data variable as "T" with -flto

2020-02-10 Thread marxin.liska at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=25355 --- Comment #15 from Martin Liška --- Thank you H.J. I can confirm the patch works: Before: $ cat x.c int nm_test_var; int nm_test_var2 = 1234; extern int foo (void); int main () { return foo (); } $ gcc-9 -fno-common x.c -c -flto &&

[Bug binutils/25355] nm reports data variable as "T" with -flto

2020-02-11 Thread marxin.liska at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=25355 --- Comment #24 from Martin Liška --- Ok, I've got one another problem with the 2 commits (de66c68d899600286b0d054508a2ed7beee64870 and 39f2b43be6ccc3acb29ab84dee48180b6a8fcba5) applied on top of the bintuils 2.34 release. I built a openSUSE

[Bug binutils/25355] nm reports data variable as "T" with -flto

2020-02-11 Thread marxin.liska at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=25355 --- Comment #28 from Martin Liška --- Created attachment 12286 --> https://sourceware.org/bugzilla/attachment.cgi?id=12286=edit libiberty archive -- You are receiving this mail because: You are on the CC list for the bug.

[Bug binutils/25355] nm reports data variable as "T" with -flto

2020-02-11 Thread marxin.liska at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=25355 --- Comment #20 from Martin Liška --- Created attachment 12283 --> https://sourceware.org/bugzilla/attachment.cgi?id=12283=edit valgrind log file -- You are receiving this mail because: You are on the CC list for the bug.

[Bug binutils/25355] nm reports data variable as "T" with -flto

2020-02-11 Thread marxin.liska at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=25355 --- Comment #23 from Martin Liška --- > > It looks like you were using one of my old patches. Line 860 in plugin.c > doesn't do anything on master branch. You are right, sorry for the noise. -- You are receiving this mail because: You

[Bug binutils/25355] nm reports data variable as "T" with -flto

2020-02-11 Thread marxin.liska at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=25355 --- Comment #27 from Martin Liška --- > > Works for me on master branch. Please try master branch to see if > it works for you. It looks one needs a system setup to have multiple plug-in which cause that: $ ls

[Bug binutils/25355] nm reports data variable as "T" with -flto

2020-02-11 Thread marxin.liska at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=25355 Martin Liška changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED

[Bug binutils/25355] nm reports data variable as "T" with -flto

2020-02-11 Thread marxin.liska at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=25355 --- Comment #31 from Martin Liška --- (In reply to H.J. Lu from comment #30) > Created attachment 12287 [details] > Try this I can confirm that patch works. -- You are receiving this mail because: You are on the CC list for the bug.

[Bug binutils/25355] nm reports data variable as "T" with -flto

2020-02-18 Thread marxin.liska at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=25355 --- Comment #54 from Martin Liška --- However, I see one another segfault: $ cat 1.i int a; $ cat 2.i [empty file] $ gcc -flto=auto -O2 -fPIC 1.i -c $ gcc -flto=auto -O2 -fPIC 2.i -c $ ar cru x.a 1.o 2.o $ ranlib x.a Segmentation fault (core

[Bug binutils/25355] nm reports data variable as "T" with -flto

2020-02-18 Thread marxin.liska at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=25355 --- Comment #57 from Martin Liška --- > Try the latest one. I can confirm it works. -- You are receiving this mail because: You are on the CC list for the bug.

[Bug binutils/25355] nm reports a variable as "T" with -flto and -fno-common

2020-01-09 Thread marxin.liska at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=25355 --- Comment #4 from Martin Liška --- (In reply to Nick Bowler from comment #2) > Summary of the issue in libtool: > > libtool needs to produce C declarations for arbitrary symbols based on nm > output, in order to implement various features

[Bug binutils/25355] nm reports a variable as "T" with -flto and -fno-common

2020-01-09 Thread marxin.liska at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=25355 Martin Liška changed: What|Removed |Added CC||bfriesen at simple dot dallas.tx.u

[Bug binutils/25355] nm reports a variable as "T" with -flto and -fno-common

2020-01-20 Thread marxin.liska at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=25355 --- Comment #9 from Martin Liška --- > > Amusingly, "nm" is also busted on objects using this trick with -flto, > showing a_ as an undefined symbol which is not the case. But that > shouldn't cause any issue for libtool's uses of nm.

[Bug binutils/25355] New: nm reports a variable as "T" with -flto and -fno-common

2020-01-08 Thread marxin.liska at gmail dot com
ty: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: marxin.liska at gmail dot com Target Milestone: --- As being discussed here: https://lists.gnu.org/archive/html/libtool/2020-01/msg00022.html nm reports mi

[Bug binutils/25640] nm shows symbol as 'U' while showed as 'T'

2020-03-09 Thread marxin.liska at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=25640 --- Comment #7 from Martin Liška --- (In reply to H.J. Lu from comment #4) > Created attachment 12355 [details] > Pass -flto-partition=none to GCC The patch does not work, very likely due to: lto-wrapper.c:608: 604 /* Drop

[Bug binutils/25640] nm shows symbol as 'U' while showed as 'T'

2020-03-09 Thread marxin.liska at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=25640 --- Comment #9 from Martin Liška --- (In reply to H.J. Lu from comment #8) > (In reply to Martin Liška from comment #7) > > (In reply to H.J. Lu from comment #4) > > > Created attachment 12355 [details] > > > Pass -flto-partition=none to GCC

[Bug gas/25295] Gas should have way to define symbol version without exporting its target

2020-04-06 Thread marxin.liska at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=25295 Martin Liška changed: What|Removed |Added CC||hjl.tools at gmail dot com -- You

[Bug gas/25295] Gas should have way to define symbol version without exporting its target

2020-04-06 Thread marxin.liska at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=25295 Martin Liška changed: What|Removed |Added CC||marxin.liska at gmail dot com

[Bug binutils/25737] New: Document which readelf and binutils options support debuginfod

2020-03-27 Thread marxin.liska at gmail dot com
: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: marxin.liska at gmail dot com Target Milestone: --- I have a few comments about debuginfod support: 1) it's not easy to identify which options do support debuginfod

[Bug gas/25295] Gas should have way to define symbol version without exporting its target

2020-05-09 Thread marxin.liska at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=25295 Martin Liška changed: What|Removed |Added CC|marxin.liska at gmail dot com | -- You are receiving