--- Additional Comments From tom at hukatronic dot cz 2005-06-08 10:05
---
Proposed fix also fixed the problem reported in
http://lists.gnu.org/archive/html/bug-binutils/2005-06/msg0.html
--
http://sources.redhat.com/bugzilla/show_bug.cgi?id=991
--- You are receiving this ma
--- Additional Comments From nickc at redhat dot com 2005-06-08 15:46
---
Created an attachment (id=510)
--> (http://sources.redhat.com/bugzilla/attachment.cgi?id=510&action=view)
Fix seg fault by checking for a NULL pointer
--
http://sources.redhat.com/bugzilla/show_bug.cgi?id=994
Hi Mario,
I can't build a 68k C cross compiler under cygwin starting from:
binutils-2.16
newlib-1.13.0
gcc-4.0.0
because an error compiling libgcc2.c in function _fixunsdfsi for M68040
Using binutils-2.15 there is no more error and the generated 68k cross
compiler w
--- Additional Comments From nickc at redhat dot com 2005-06-08 17:04
---
Hi Tom,
Thanks for reporting this problem and submit the patches to fix it. I have
checked them in, with a little tidying up of the formatting and a few comments
added, and I also created this ChangeLog entry:
--- Additional Comments From nickc at redhat dot com 2005-06-08 15:45
---
Hi Richard,
Agreed, the assembler should not crash. I am applying the patch in the
attachmrnt to stop the seg fault hapeening.
Cheers
Nick
gas/ChangeLog
2005-06-08 Nick Clifton <[EMAIL PROTECTED]>
The script below works when the linker is "GNU ld version 2.13.90.0.18 20030206"
(RedHat 9) but not when it is "GNU ld version 2.16.91 20050608" (CVS HEAD). In
both cases, the compiler used is "gcc version 3.2.2 20030222 (Red Hat Linux
3.2.2-5)".
The reason is that
--- 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 warni
--- Additional Comments From hjl at lucon dot org 2005-06-08 18:56 ---
A patch is posted at
http://sourceware.org/ml/binutils/2005-06/msg00185.html
--
http://sources.redhat.com/bugzilla/show_bug.cgi?id=995
--- You are receiving this mail because: ---
You are on the CC list f
--- 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 thin
--- 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 m
--- 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 determ
--- Additional Comments From jepler at sds2 dot com 2005-06-08 20:05
---
I believe I isolated the change that causes the problem. It seems to have been
made less than two days ago. Since I hadn't looked at binutils cvs in so long,
I'm astounded that it turned out to be so recent a chan
azp:44% cat h.s
.data
msg:.asciz "hello world.\n"
msglen = .-msg-1
msglen=msglen & 0xff
azp:45% as -a h.s -o h.o
h.s: Assembler messages:
h.s:5: Error: symbol definition loop encountered at `msglen'
h.s:5: Error: undefined symbol `msglen' in operation setting `msglen'
h.s:5: Internal
--- Additional Comments From rth at gcc dot gnu dot org 2005-06-08 20:19
---
Yes, your warning solution is acceptable.
I may look into disabling the section switching stuff for ia64. I'm unconvinced
it's worth the effort it would take to get all the unwind info correct. This is
"solve
Computed lengths are used as 32 bit values, even when they are less
than 128. Symbols assigned values less than 128 and used generate
a one byte immediate in pushl $value, while symbols with computed
lengths appear as 4 byte immediate values, even though they have the
same small value.
Al
--- 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
Stat
--- Additional Comments From mark at codesourcery dot com 2005-06-08 22:02
---
Oh, and, meanwhile, I'll be trying to reproduce this myself. Thanks!
--
http://sources.redhat.com/bugzilla/show_bug.cgi?id=996
--- You are receiving this mail because: ---
You are on the CC list
--- Additional Comments From mark at codesourcery dot com 2005-06-08 22:01
---
I'm not sure why you're seeing, but it is indeed very plausible that it's my
fault.
BFD has an open-file cache, and should close files and reopen them as necessary.
Do you have any idea what's different aft
--- Additional Comments From mark at codesourcery dot com 2005-06-08 22:38
---
Subject: Re: Linking requires one open file per object file
mark at codesourcery dot com wrote:
> --- Additional Comments From mark at codesourcery dot com 2005-06-08
> 22:01 ---
> I'm not sure why
--- Additional Comments From hjl at lucon dot org 2005-06-09 01:13 ---
Created an attachment (id=513)
--> (http://sources.redhat.com/bugzilla/attachment.cgi?id=513&action=view)
A testcase
This test case shows the -l outputs before and after the patch in bug 806.
--
http://sources.re
"nm -l" used to work on assembly file compiled with "-gdwarf-2". With
the patch in bug 806, it no longer works.
--
Summary: [Regression]: "nm -l" no longer works on assembly file
Product: binutils
Version: unspecified
Status: NEW
Severity: no
--- Additional Comments From hjl at lucon dot org 2005-06-09 06:09 ---
A patch is posted at
http://sourceware.org/ml/binutils/2005-06/msg00206.html
--
http://sources.redhat.com/bugzilla/show_bug.cgi?id=1000
--- You are receiving this mail because: ---
You are on the CC list
--- Additional Comments From amodra at bigpond dot net dot au 2005-06-09
06:29 ---
This is a consequence of the way gas resolves symbols. The problem is that the
first assignment to msglen isn't resolved immediately when parts of the
expression use symbols ("." and "msg" here) in differ
--- Additional Comments From amodra at bigpond dot net dot au 2005-06-09
06:36 ---
This is a result of delayed expression evaluation. If you assemble without
listings turned on, the optimal push insn will be chosen.
--
What|Removed |Added
---
--
What|Removed |Added
OtherBugsDependingO||998
nThis||
http://sources.redhat.com/bugzilla/show_bug.cgi?id=997
25 matches
Mail list logo
