[Bug gas/803] gas should avoid F-unit NOPs (and B-unit probably, too)
--- Additional Comments From wilson at specifixinc dot com 2005-03-25 01:13 --- The patch looks OK to me, but I expect it will break the IA-64 gas testsuite, which means we need patches for that also. I haven't tried writing those patches yet. -- http://sources.redhat.com/bugzilla/show_bug.cgi?id=803 --- 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/803] gas should avoid F-unit NOPs (and B-unit probably, too)
--- Additional Comments From wilson at specifixinc dot com 2005-03-25 02:46 --- Subject: Re: gas should avoid F-unit NOPs (and B-unit probably, too) On Thu, 2005-03-24 at 18:22, hjl at lucon dot org wrote: > --- Additional Comments From hjl at lucon dot org 2005-03-25 02:22 > --- > Can we modify the patch to have it a switch to turn it on/off and make it > on by default? Then, we can just turn it off in the existing testcases and > add a new one for this. Such as a -mcpu=itanium1 switch? I suppose that could work. Or we could try fixing the testsuite to use explicit bundles, so that it stops changing every time the bundling heuristics change. Or we could just say to heck with it and regenerate all of the .d files. Or we could try to make the .d files be bundling independent. Try looking at some of the ones that Jan Beulich has added. He uses "." to match bundles when nops are involved, so that it is bundling independent. See for instance align.d. However, before we make a decision, I really think that someone should run the gas testsuite first, and check to see whether we have a problem, and if so, how big of a problem it is. There is no sense to trying to write a complicated solution if we only have a simple problem. -- http://sources.redhat.com/bugzilla/show_bug.cgi?id=803 --- 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/803] gas should avoid F-unit NOPs (and B-unit probably, too)
--- Additional Comments From wilson at specifixinc dot com 2005-03-25 21:07 --- Subject: Re: gas should avoid F-unit NOPs (and B-unit probably, too) On Fri, 2005-03-25 at 09:18, hjl at lucon dot org wrote: > I think we should add -mcpu=[itanium1|itanium2] and make itanium2 the default. I'm OK with that. Long term, I think writing testcases the way Jan did is a better solution, but we've got 2k nops in just the opc-*.d files alone, and fixing them all seems like too much work for now when we are just trying to get David's patch in. -- http://sources.redhat.com/bugzilla/show_bug.cgi?id=803 --- 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/803] gas should avoid F-unit NOPs (and B-unit probably, too)
--- Additional Comments From wilson at specifixinc dot com 2005-03-28 21:36 --- Subject: Re: gas should avoid F-unit NOPs (and B-unit probably, too) On Mon, 2005-03-28 at 13:03, hjl at lucon dot org wrote: > This patch adds "-mtune=[itanium1|itanium2]". I will update > NEWS and doc if it is OK. I think the extra_goodness change is a little confusing. You are reusing the parameter "slot" for the return value, even though the return value has nothing to do with slot numbers. I had to read the code twice before I figured out why you were changing the slot numbers. I would prefer a new local variable named "goodness" or "retval" or whatever. And then we can initialize it to a sensible value like 0. Or perhaps just "return 2" instead of "slot = 2" like the original code had. There is also the issue that maybe there should be a "default: abort ();" to make sure the code gets appropriately modified when future processors are added. Otherwise, it all looks OK to me. -- http://sources.redhat.com/bugzilla/show_bug.cgi?id=803 --- 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/803] gas should avoid F-unit NOPs (and B-unit probably, too)
--- Additional Comments From wilson at specifixinc dot com 2005-03-28 22:26 --- Subject: Re: gas should avoid F-unit NOPs (and B-unit probably, too) On Mon, 2005-03-28 at 13:48, hjl at lucon dot org wrote: > This is an updated patch. I documented the change and modified > extra_goodness. OK. Thanks. -- http://sources.redhat.com/bugzilla/show_bug.cgi?id=803 --- 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/803] gas should avoid F-unit NOPs (and B-unit probably, too)
--- Additional Comments From wilson at specifixinc dot com 2005-03-29 02:19 --- HJ checked in his patch to fix this. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://sources.redhat.com/bugzilla/show_bug.cgi?id=803 --- 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 binutils/947] Extension to BFD and addr2line to print inlining chain
--- Additional Comments From wilson at specifixinc dot com 2005-05-12 20:38 --- Subject: Re: New: Extension to BFD and addr2line to print inlining chain On Thu, 2005-05-12 at 12:10, fnf at specifixinc dot com wrote: > The patch (which I'll attach separately) allows addr2line to print > additional information about how we arrived at that address via several > levels of inlining: This binutils patch requires a gcc patch to emit the DW_AT_call_file and DW_AT_call_line info. I expect to check that in soon. I was waiting for proof that it did something useful before checking it in. This patch can be found here: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20967 -- http://sources.redhat.com/bugzilla/show_bug.cgi?id=947 --- 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/994] section switch in function causes segfault
--- Additional Comments From wilson at specifixinc dot com 2005-06-08 18:48 --- Nick's patch avoids the assembler core dump, but results in corrupted unwind info. IMHO, this is worse, since it converted an obvious error into a silent one. I'm thinking the assembler should emit a warning (or perhaps an error) when this problem is seen. Also, the IA-64 compiler should emit a warning (or perhaps an error) when the -freorder-blocks-and-partition option is used, which will say that the option isn't supported for IA-64. It is exactly because of these kinds of problems why I keep saying that section switching should be a hard error. It will be so hard to modify the assembler to get this case right that it likely isn't worth the trouble. I think it is better is to fix the compiler to avoid constructs like this. It will probably take a lot of compiler work too though. The .text.unlikely code needs to be emitted after the function end. Also, you either need to guarantee that you will never put any code in .text.unlikely that can throw an exception, or else you need to emit proper unwind info for it. Emitting proper unwind info for it may require info about the context in which it is being called, in case we need something more than just a body region. Better might be to avoid such cases, which means we need to avoid putting any function returns in a .text.unlikely section, and we need to avoid putting any shrink wrapped prologue/epilogue code in there, etc. This is likely to be a big mess, even if implemented by someone who understands IA-64 code. On second thought, if this is a big enough mess in the compiler, then it might be worthwhile to try to make this work in the assembler. Getting this right in the assembler means that a lot of the assembler internal data in tc-ia64.c needs to be put in a structure and maintained separately for every text region, so that we can handle nested text regions, pushing/popping text regions, etc, and then still be able to sort everything out at the end. My worry here though would be that there are so few people who both understand the inner details of how IA-64 code works, and are willing to do binutils work, that we may not be able to find a competent volunteer to do this work. -- What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://sources.redhat.com/bugzilla/show_bug.cgi?id=994 --- 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/994] section switch in function causes segfault
--- Additional Comments From wilson at specifixinc dot com 2005-06-08 19:55 --- Created an attachment (id=511) --> (http://sources.redhat.com/bugzilla/attachment.cgi?id=511&action=view) Warn for section switch that corrupts unwind info. This is my fix for the problem. It does two things: 1) It emits a warning when this problem is detected. tmp.s:21: Warning: Corrupted unwind info due to unsupported section switching 2) It tries to get the unwind info as correct as possible. With Nick's patch, the trailing body region has a length that is a large number computed from an address returned by malloc. With my patch, it is the correct number for this testcase. However, it is only the correct number if it is guaranteed that there is no code after the .text.unlikely section switch. This is not guaranteed to be true in general. So we still need the warning, or code to check for this special case. It isn't immediately obvious how to check for this, or whether we can even check for it without changes to the machine independent parts of the assembler, so I have made no attempt to write code for this check. I simply emit the warning unconditionally. -- What|Removed |Added Attachment #510 is|0 |1 obsolete|| AssignedTo|unassigned at sources dot |wilson at specifixinc dot |redhat dot com |com Status|REOPENED|ASSIGNED http://sources.redhat.com/bugzilla/show_bug.cgi?id=994 --- 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/994] section switch in function causes segfault
--- Additional Comments From wilson at specifixinc dot com 2005-06-08 20:09 --- I should point out that while my patch does get the unwind info correct for the .text section (assuming no additional code in .text after the section switch), the .text.unlikely section unwind info is still missing, and hence the code is still broken. Thus the warning may still be useful even if we check for the case where there is no more code in .text after the section switch. -- http://sources.redhat.com/bugzilla/show_bug.cgi?id=994 --- 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/994] section switch in function causes segfault
--- Additional Comments From wilson at specifixinc dot com 2005-06-08 20:00 --- Richard, is my solution (a warning) acceptable? Or do you have another suggestion? It might be possible to do better, either add more code to get the unwind info correct in this case, or add code to determine when the warning is not necessary (as in this case), but I'm not motivated to try either, as I don't believe this assembler construct should be valid in the first place. -- http://sources.redhat.com/bugzilla/show_bug.cgi?id=994 --- 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/994] section switch in function causes segfault
--- Additional Comments From wilson at specifixinc dot com 2005-06-08 21:12 --- Fixed by my patch, which has already been checked in. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://sources.redhat.com/bugzilla/show_bug.cgi?id=994 --- 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
