[Bug gas/1630] gas weakref tests fail on most (all?) targets
-- What|Removed |Added Status|NEW |ASSIGNED http://sourceware.org/bugzilla/show_bug.cgi?id=1630 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/1630] gas weakref tests fail on most (all?) targets
--- Additional Comments From aoliva at sourceware dot org 2005-11-05 17:19 --- Fixed -- What|Removed |Added CC|aoliva at sources dot redhat| |dot com | Status|ASSIGNED|RESOLVED Resolution||FIXED http://sourceware.org/bugzilla/show_bug.cgi?id=1630 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/4184] # 0 "" 2 doesn't handle assembler input buffer properly
--- Additional Comments From aoliva at sourceware dot org 2007-03-15 05:24 --- http://sourceware.org/ml/binutils/2007-03/msg00149.html -- What|Removed |Added AssignedTo|unassigned at sources dot |aoliva at sourceware dot org |redhat dot com | Status|NEW |ASSIGNED http://sourceware.org/bugzilla/show_bug.cgi?id=4184 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/31652] New: weak def in discarded comdat section becomes unreferenced undefweak with ld -r
https://sourceware.org/bugzilla/show_bug.cgi?id=31652 Bug ID: 31652 Summary: weak def in discarded comdat section becomes unreferenced undefweak with ld -r Product: binutils Version: 2.43 (HEAD) URL: https://sourceware.org/pipermail/binutils/2024-April/1 33602.html Status: NEW Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: aoliva at sourceware dot org Target Milestone: --- The following, say t.s, is dystilled from libstdc++-v3's floating_to_chars.o: .section .text.foobar,"axG",@progbits,foo,comdat .weak foo .type foo,@function foo: # .dc.a undef .size foo, . - foo .weak bar .set bar, foo The weak definitions were originally implicit instantiations of to_chars_i, and the aliases were originally meant for abi compatibility because of changes in int128_t mangling. The following, say m.s, is dystilled from a libstdc++-v3/testsuite/std/time/clock/system/io.cc: .section .text.foobar,"axG",@progbits,foo,comdat .weak foo .type foo,@function foo: .size foo, . - foo .global _start .set _start,foo And here's how to trigger the problem: (simplified from the emails, dropping the unnecessary archive and linking the object file in it directly; the asm sources were also simplified, dropping bits that were meant to pull t.o from the archive) gas/as-new t.s -o t.o && gas/as-new m.s -o m.o && ld/ld-new m.o t.o -o m -r && binutils/nm-new m | grep bar w bar Tested with 2.38, 2.42, and 2.42.50.20240413, targeting x86_64-linux-gnu, and also 2.42 targeting multiple vxworks7r2 targets. This is probably expected behavior: the weakly-defined symbol in t.o lives in a discarded section, so it decays to weak-undefined, and it most likely goes unnoticed on systems that support undefweak. If this were a final link, the bar symbol would be gone. So would the undef symbol, if the reference to it in t.s were uncommented. But because this is a relocatable link, both undefined symbols would remain. Both of them are a problem for e.g. vxworks kernel modules, that never undergo final linking, and whose loader rejects undefined symbols, even weak ones, if they're not defined elsewhere. I hoped --strip-discarded would get rid of undef, if not bar, but no such luck. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/26143] gas generates invalid line table entry
https://sourceware.org/bugzilla/show_bug.cgi?id=26143 --- Comment #4 from Alexandre Oliva --- tom> I get the impression that the "which might not be the same as that of the following assembly instruction" formulation refers to a situation like this yup nick> what do you think that the assembler should be doing in this situation? ISTM that .cfi_endproc should implicitly bump (increment or reset) the view number. I don't think that would solve the issue of strict dwarf compliance though. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/22870] slow aarch64 assembler for source with lots of .loc directives
https://sourceware.org/bugzilla/show_bug.cgi?id=22870 --- Comment #2 from Alexandre Oliva --- I suspect the source of the problem is the lack of view reset asserts. Without that, the assembler gets an uninterrupted chain of symbolic views, in which each view is computed based on the view before it and the offset between the addresses in which they were issued. Depending on the order in which the assembler attempts to resolve each view to a constant, it could get expensive. It was never meant for this kind of use: it was expected that most views would be zero-asserts, so this wouldn't arise. The issuance of view asserts was disabled in GCC, triggering this undesirable behavior in the assembler, but I'm not sure I'd consider it a bug in gas. GCC can and should avoid these long chains, issuing view reset asserts after insns known to generate code. It has code to do so, but it's disabled because a few targets had wrong lengths and need auditing and possibly overriding in a target hook. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/22870] slow aarch64 assembler for source with lots of .loc directives
https://sourceware.org/bugzilla/show_bug.cgi?id=22870 Alexandre Oliva changed: What|Removed |Added CC||aoliva at sourceware dot org --- Comment #4 from Alexandre Oliva --- IIRC it already does that; it only emits symbolic expressions when, at the time it sees the .loc directive, it can't yet determine whether . > .LVL(#-1) (IOW, have we advanced PC since the previous view in the same subsection?). If we can do more to resolve these early, we will certainly cut short the expression bloat and dep chain. Now, even if we can't determine that earlier, we could still do better. We multiply the negation of the above by (.LVU# + 1) (IOW, the successor to the previous view). If the multiplication could take a shortcut if one of the operands is found to be zero (it often will be, in this particular case) and resolve the result to zero (not necessarily for good, since relaxing might turn an align to nothing), we'd get much shorter evaluations overall. If optimizing multiplication is no good, maybe we could introduce a ternary operator for internal use, for use in this case? All that said, GCC will soon cut the chains short at function entry points, where it will force a view reset. This should shrink the chain lengths significantly, but I guess we can still use any of the suggested above to improve it so we only hit the O(2^n) case with small n. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/22870] slow aarch64 assembler for source with lots of .loc directives
https://sourceware.org/bugzilla/show_bug.cgi?id=22870 Alexandre Oliva changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at sourceware dot org |aoliva at sourceware dot org --- Comment #5 from Alexandre Oliva --- Mine, just awaiting some feedback on the proposed courses of action. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/24444] assembling big file with a lot of .loc views takes forever
https://sourceware.org/bugzilla/show_bug.cgi?id=2 Alexandre Oliva changed: What|Removed |Added Status|NEW |ASSIGNED CC||aoliva at sourceware dot org Assignee|unassigned at sourceware dot org |aoliva at sourceware dot org --- Comment #1 from Alexandre Oliva --- Mine. Patch at https://sourceware.org/ml/binutils/2019-04/msg00161.html -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/24444] assembling big file with a lot of .loc views takes forever
https://sourceware.org/bugzilla/show_bug.cgi?id=2 Alexandre Oliva changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Alexandre Oliva --- Fixed -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/22870] slow aarch64 assembler for source with lots of .loc directives
https://sourceware.org/bugzilla/show_bug.cgi?id=22870 Alexandre Oliva changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Alexandre Oliva --- Uhh... Do you still observe this slow down? We've fixed other instances of this at various times. Please reopen if it's still observable. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/6446] Handling of EF_FRV_PIC
--- Additional Comments From aoliva at sourceware dot org 2008-06-03 04:35 --- The patch does indeed appear to get the code to patch the spec (thanks, Nick!), but I'm concerned that, at this point, it might be wiser to change the spec to match the code, for a couple of kernels and libcs might be relying on the current bug :-( -- http://sourceware.org/bugzilla/show_bug.cgi?id=6446 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/9785] FRV doesn't work on 64bit host
--- Additional Comments From aoliva at sourceware dot org 2009-01-26 18:18 --- "Doesn't support" is quite strong. It was mostly developed on 64-bit hosts. Anyhow, I'll have a look as soon as I get a chance. Wouldn't mind if someone beat me to it. I remember having fixed a bunch of these truncation issues back when I started, it shouldn't be too hard to locate this one. -- http://sourceware.org/bugzilla/show_bug.cgi?id=9785 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
