[Bug binutils/5449] strip/objcopy doesn't work on ia64/hpux
--- Additional Comments From haubi at gentoo dot org 2007-12-18 08:44 --- Created an attachment (id=2148) --> (http://sourceware.org/bugzilla/attachment.cgi?id=2148&action=view) patch for binutils-2.18 (In reply to comment #9) > That is because 2.16.1 uses 4K maximum page size and my patch changes to > 64K maximum page size. Ok, then this patch works for me for binutils-2.18, thank you! -- http://sourceware.org/bugzilla/show_bug.cgi?id=5449 --- 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/5457] INTOUCH instruction incorrectly disassembled.
--- Additional Comments From shap at eros-os dot com 2007-12-18 15:59 --- Created an attachment (id=2149) --> (http://sourceware.org/bugzilla/attachment.cgi?id=2149&action=view) Revised patch, splitting CPUSHL per suggestion This patch splits CPUSHL as suggested (I think -- would appreciate confirm). -- What|Removed |Added Attachment #2127 is|0 |1 obsolete|| http://sourceware.org/bugzilla/show_bug.cgi?id=5457 --- 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
Fixing m68k movec disassembly
I've gotten annoyed enough to want to fix something :-) The disassembly logic for M68k MOVEC is awful. To do it right requires knowledge of the actual target CPU model, and we don't have that from BFD. We *do* have the target architecture level, and we can at least use that to refine the output. My proposal is that m68k disassembly should only emit a movec register mnemonic when it actually knows (based on target arch) that the mnemonic is correct. In other cases it should emit the numeric register number. I have some code that sensitizes the mnemonic selection to target architecture variant, but I would appreciate feedback on whether this seems sensible before submitting the patch. Also, my impression is that the target CPU *can* be specified on the command line (via -m), and in that case greater precision is possible. I'ld like to update the patch to deal with that. Assuming that the user has told us a CPU on the command line via -m, how can that cpu name be found from code running in opcodes/m68k-dis.c? Thanks shap ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
