[Bug ld/2729] ld terminated with signal 11 [Segmentation fault]
-- What|Removed |Added CC||dannysmith at users dot ||sourceforge dot net http://sourceware.org/bugzilla/show_bug.cgi?id=2729 --- 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
NOLOAD problem with binutils 2.16.92
Hi, I had posted a problem related to binutils 2.16.92 Please refer to the following link for the posted problem, http://lists.gnu.org/archive/html/bug-binutils/2006-07/msg00041.html After further investigation, I found that this problem also exists for ARM and m32r targets also. Kindly let me know your comments on the same. Regards, Ashutosh Yeole KPIT Cummins InfoSystems Ltd. Pune, India Free download of GNU based tool-chains for Renesas' SH, H8, R8C, M16C and M32C Series. The following site also offers free technical support to its users. Visit http://www.kpitgnutools.com for details. Latest versions of KPIT GNU tools were released on June 1, 2006. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: [Bug gas/2848] macro name syntax changed
Hi Roman, You read it correctly, the intention is to provide the opcodes foo.b/foo.w/foo.l, so using "foo .l" would be even more confusing. OK, so presumably a workaround is to provide individual macros with the names "foo.b", "foo.w" and so on, rather than just one macro. The point is that gas broke compatibility here, so I can't provide > such opcodes at all anymore. Hmm, well the change was to make macros names consistent with other names. ie if string was a valid name for a (pseudo) opcode or a label, then it could also be a valid name for a macro. I appreciate however that this did break backwards compatibility. So please could you try out the uploaded patch and let me know if it works for you. (You will need to add the command line switch --no-dot-in-macro-names to assembler command line). Cheers Nick ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/2848] macro name syntax changed
--- Additional Comments From nickc at redhat dot com 2006-07-26 10:41 --- Subject: Re: macro name syntax changed Hi Roman, > You read it correctly, the intention is to provide the opcodes > foo.b/foo.w/foo.l, so using "foo .l" would be even more confusing. OK, so presumably a workaround is to provide individual macros with the names "foo.b", "foo.w" and so on, rather than just one macro. > The point is that gas broke compatibility here, so I can't provide > such opcodes at all anymore. Hmm, well the change was to make macros names consistent with other names. ie if string was a valid name for a (pseudo) opcode or a label, then it could also be a valid name for a macro. I appreciate however that this did break backwards compatibility. So please could you try out the uploaded patch and let me know if it works for you. (You will need to add the command line switch --no-dot-in-macro-names to assembler command line). Cheers Nick -- http://sourceware.org/bugzilla/show_bug.cgi?id=2848 --- 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/2848] macro name syntax changed
--- Additional Comments From nickc at redhat dot com 2006-07-26 10:42 --- Created an attachment (id=1185) --> (http://sourceware.org/bugzilla/attachment.cgi?id=1185&action=view) Add new GAS command line switch --no-dot-in-macro-names -- http://sourceware.org/bugzilla/show_bug.cgi?id=2848 --- 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/2848] macro name syntax changed
--- Additional Comments From zippel at linux-m68k dot org 2006-07-26 11:21 --- (In reply to comment #3) > OK, so presumably a workaround is to provide individual macros with the > names "foo.b", "foo.w" and so on, rather than just one macro. This is not possible, if it has to work with various versions of binutils. > Hmm, well the change was to make macros names consistent with other > names. ie if string was a valid name for a (pseudo) opcode or a label, > then it could also be a valid name for a macro. I appreciate however > that this did break backwards compatibility. What's the point of making this "consistent"? At least for m68k the old rules made more sense and should be the default here. -- http://sourceware.org/bugzilla/show_bug.cgi?id=2848 --- 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
