Re: Correct ELF machine for coldfire?
Hi Daniel, Should this be getting set to EM_COLDFIRE, or is the existing behavior correct? I think that it is a bug. ie the number should be EM_COLDFIRE. The GNU tools never generate EM_COLDFIRE. I think some non-GNU tools do. Ok, but is the EM_COLDFIRE number the correct one to use ? (ie are the GNU tools wrong ?) It would appear so given the name, but maybe it is an unofficial number. Cheers Nick ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/5692] ld segfault linked to bfd elf error
--- Additional Comments From amodra at bigpond dot net dot au 2008-02-01 12:52 --- Nick, I think your patch is just papering over the real problem, which is that elf32_arm_size_dynamic_sections calls bfd_elf32_arm_init_maps for all input bfds regardless of target. bfd_elf32_arm_init_maps then calls bfd_elf_get_elf_syms on a non-ELF input bfd. (I think a better patch to bfd_elf_get_elf_syms would be to abort on non-ELF input.) -- What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://sourceware.org/bugzilla/show_bug.cgi?id=5692 --- 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
Re: Correct ELF machine for coldfire?
On Fri, 2008-02-01 at 10:40 +, Nick Clifton wrote: > > The GNU tools never generate EM_COLDFIRE. I think some non-GNU tools > > do. > > Ok, but is the EM_COLDFIRE number the correct one to use ? (ie are the GNU > tools wrong ?) It would appear so given the name, but maybe it is an > unofficial number. Nick: I suspect that this is a huge can of worms. First, it will get everyone entangled in the "should m68k be split" discussion. Second, there will be compatibility issues. Third, doing a split won't really benefit the target, because the dingbats at FreeScale have made some incompatible and conflicting choices within the Coldfire line. Concretely, this means that splitting the architecture won't absolve the developer of the need to specify the target CPU in any case, and from an expressiveness perspective there just isn't that big a difference between "its a coldfire" and "its an m68k+isa_b CPU". Looking over our kernel, I'm not convinced (for the moment) that there is anything CPU dependent at this level that can't be handled sufficiently with #define's supplied from the BSP. shap ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: Correct ELF machine for coldfire?
On Thu, 2008-01-31 at 15:22 -0500, Daniel Jacobowitz wrote: > The GNU tools never generate EM_COLDFIRE. I think some non-GNU tools > do. Daniel: Thank you. That's a bit of a relief. I may have it misconfigured, but at least I seem to have it misconfigured correctly. :-) shap ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/5712] New: gas can't parse ARM .save directives for FPA registers
According to the docs here: http://sourceware.org/binutils/docs-2.18/as/ARM-Directives.html#index-g_t_0040code_007b_002esave_007d-directive_002c-ARM-609 you should be able to specify an FPA register in ARM .save directives, like the following: sfmfd f4, 1, [sp]! .save f4, 1 These directives are usually generated by g++. However, if you attempt to assemble this, using "gas -mfpu=fpa", you'll get: test.s: Assembler messages: test.s:2: Error: expected , This is because gas apparently doesn't skip the register name when looking for the following comma. The function s_arm_unwind_save(), in gas/config/tc-arm.c, peeks ahead to parse the type of register that follows a .save directive, using arm_reg_parse_mult(). When it finds a known register, it uses its type to call the appropriate handler for that type. Unfortunately, for FPA registers, it calls s_arm_unwind_save_fpa() *without* advancing the input_line_pointer to just afer the register name. Since the first thing s_arm_unwind_save_fpa() expects to find is a comma, it will always fail, with: "expected , ". Since arm_reg_parse_multi() already advanced the peek pointer to just after the register name, just setting input_line_pointer to peek is a nice, one-line fix. -- Summary: gas can't parse ARM .save directives for FPA registers Product: binutils Version: 2.19 (HEAD) Status: NEW Severity: normal Priority: P2 Component: gas AssignedTo: unassigned at sources dot redhat dot com ReportedBy: dimitry at andric dot com CC: bug-binutils at gnu dot org GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: arm-omap2-linux-gnueabi http://sourceware.org/bugzilla/show_bug.cgi?id=5712 --- 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/5712] gas can't parse ARM .save directives for FPA registers
--- Additional Comments From dimitry at andric dot com 2008-02-01 23:21 --- Created an attachment (id=2225) --> (http://sourceware.org/bugzilla/attachment.cgi?id=2225&action=view) Test case for .save of an FPA register -- http://sourceware.org/bugzilla/show_bug.cgi?id=5712 --- 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/5712] gas can't parse ARM .save directives for FPA registers
--- Additional Comments From dimitry at andric dot com 2008-02-01 23:22 --- Created an attachment (id=2226) --> (http://sourceware.org/bugzilla/attachment.cgi?id=2226&action=view) Fix for properly parsing .save directives with an FPA register -- http://sourceware.org/bugzilla/show_bug.cgi?id=5712 --- 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/5713] New: strings: use '-0' as option will meet infinite loop
When I use the command "strings" like this: "strings -0 file" will trap in
infinite loop.
The binutils version is 2.17.50.0.6. Has this bug been fixed?
If not, here is my patch.
Thank you.
Chu Li
Signed-off-by: Chu Li <[EMAIL PROTECTED]>
--
diff --git a/strings.c b/strings.c
index 4c68ea8..8ee2783 100644
--- a/strings.c
+++ b/strings.c
@@ -274,6 +274,9 @@ main (int argc, char **argv)
}
}
+ if(string_min == 0)
+fatal (_("invalid number %d"), string_min);
+
if (string_min < 0)
string_min = 4;
--
Summary: strings: use '-0' as option will meet infinite loop
Product: binutils
Version: 2.17
Status: NEW
Severity: normal
Priority: P2
Component: binutils
AssignedTo: unassigned at sources dot redhat dot com
ReportedBy: chul at cn dot fujitsu dot com
CC: bug-binutils at gnu dot org
http://sourceware.org/bugzilla/show_bug.cgi?id=5713
--- 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/5713] strings: use '-0' as option will meet infinite loop
--- Additional Comments From chul at cn dot fujitsu dot com 2008-02-02 02:46 --- Created an attachment (id=2227) --> (http://sourceware.org/bugzilla/attachment.cgi?id=2227&action=view) After applying this patch, when use "strings -0 file", "invalid number 0" will be reported. -- http://sourceware.org/bugzilla/show_bug.cgi?id=5713 --- 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
