Assignee: unassigned at sourceware dot org
Reporter: amonakov at gmail dot com
Created attachment 7680
--> https://sourceware.org/bugzilla/attachment.cgi?id=7680&action=edit
repro input
When trying to build pixman with -mtls-dialect=gnu2, ld produces assertion
failure whi
https://sourceware.org/bugzilla/show_bug.cgi?id=17117
Alexander Monakov changed:
What|Removed |Added
CC||hjl.tools at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=17057
Alexander Monakov changed:
What|Removed |Added
See Also||https://sourceware.org/bugz
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: amonakov at gmail dot com
CC: hjl.tools at gmail dot com
Target Milestone: ---
In the following testcase, libfoo.so is compiled so that it has GLOB_DAT
relocations
https://sourceware.org/bugzilla/show_bug.cgi?id=18841
--- Comment #5 from Alexander Monakov ---
Does it still fail with the change you mentioned in comment #2?
> 2. Make pz file scope causes it to fail with gold and ld
--
You are receiving this mail because:
You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=18829
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gmail dot com
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: amonakov at gmail dot com
Target Milestone: ---
It appears that automagic provision of __start_/__stop_SCN symbol names doesn't
work in BFD linker (works in Gold) if the section in que
https://sourceware.org/bugzilla/show_bug.cgi?id=21557
--- Comment #2 from Alexander Monakov ---
Thanks for the reference, I was missing that this handling is explicitly
limited to orphan sections. This makes my testcase invalid, but please consider
that current linker behavior appears inconsisten
: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: amonakov at gmail dot com
Target Milestone: ---
(originally mentioned in bug 21557)
Linker manual explicitly states that __start_SCN symbols are automatically
provided
https://sourceware.org/bugzilla/show_bug.cgi?id=21557
--- Comment #4 from Alexander Monakov ---
> Please open a new bug report.
Done, bug 21562.
Now I see that to use __start_SCN together with linker scripts and
--gc-sections, one should put the PROVIDE statement inside of the output
section de
https://sourceware.org/bugzilla/show_bug.cgi?id=21562
--- Comment #5 from Alexander Monakov ---
The patch looks wrong, it appears to ensure that __start_scnfoo is defined. The
linker manual says it shouldn't get defined (scnfoo is not orphan), and
therefore scnfoo should be eliminated due to --gc
https://sourceware.org/bugzilla/show_bug.cgi?id=21562
--- Comment #7 from Alexander Monakov ---
(In reply to H.J. Lu from comment #6)
> I posted a patch to always define referenced __start_SECNAME/__stop_SECNAME:
That's quite confusing, because originally bug 21557 (wrongly) complained about
tho
https://sourceware.org/bugzilla/show_bug.cgi?id=21571
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=29551
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gmail dot com
Severity: normal
Priority: P2
Component: gold
Assignee: ccoutant at gmail dot com
Reporter: amonakov at gmail dot com
CC: ian at airs dot com
Target Milestone: ---
ELF spec states that the most constraining visibility is taken from
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: amonakov at gmail dot com
Target Milestone: ---
Consider the follow testcase with two shared libraries:
$ cat > lib1.s
.globl foo
foo:
$ cat >
https://sourceware.org/bugzilla/show_bug.cgi?id=22694
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=23411
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=23411
--- Comment #7 from Alexander Monakov ---
BFD's behavior becomes very problematic with LTO: archive index does not
distinguish between normal and common definitions, and there's no explicit
plugin API to check if a definition in IR is "common"
https://sourceware.org/bugzilla/show_bug.cgi?id=23411
--- Comment #9 from Alexander Monakov ---
(In reply to Cary Coutant from comment #8)
> Is that a problem we really need to worry
> about? The only real issue with including an otherwise-unneeded object
> is the potential violation of the lang
https://sourceware.org/bugzilla/show_bug.cgi?id=23935
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=27119
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=32846
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gmail dot com
23 matches
Mail list logo
