[Bug gas/1804] Wrong output for 64-bit difference of labels
--- Additional Comments From amodra at bigpond dot net dot au 2005-11-05 08:36 --- This is caused by tc-hppa.c:md_apply_fix treating the fixup as only being 32 bit. A simpler testcase is .data .dword L$FE0061-L$FB0061 .text L$FB0061: nop L$FE0061: -- http://sourceware.org/bugzilla/show_bug.cgi?id=1804 --- 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 ld/1811] ELF linker loads member of archive for common symbol
--- Additional Comments From hjl at lucon dot org 2005-11-05 15:13 --- Created an attachment (id=746) --> (http://sourceware.org/bugzilla/attachment.cgi?id=746&action=view) A testcase I think Solaris linker hehavior makes some senses. Kean, can you try this testcase with your linker? I got bash-3.00$ make gcc-c -o main.o main.c gcc-c -o define.o define.c ar rv libtest.a define.o ar: creating libtest.a a - define.o gcc -o main1 main.o libtest.a gcc -o main2 main.o define.o gcc -shared -o libtest.so define.o gcc -o main3 main.o libtest.so -Wl,-rpath,. ./main1 3 ./main2 3 ./main3 3 It is very consistent. -- http://sourceware.org/bugzilla/show_bug.cgi?id=1811 --- 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/1630] gas weakref tests fail on most (all?) targets
-- What|Removed |Added Status|NEW |ASSIGNED http://sourceware.org/bugzilla/show_bug.cgi?id=1630 --- 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/1630] gas weakref tests fail on most (all?) targets
--- Additional Comments From aoliva at sourceware dot org 2005-11-05 17:19 --- Fixed -- What|Removed |Added CC|aoliva at sources dot redhat| |dot com | Status|ASSIGNED|RESOLVED Resolution||FIXED http://sourceware.org/bugzilla/show_bug.cgi?id=1630 --- 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 ld/1811] ELF linker loads member of archive for common symbol
-- What|Removed |Added CC||kean at armory dot com http://sourceware.org/bugzilla/show_bug.cgi?id=1811 --- 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 ld/1811] ELF linker loads member of archive for common symbol
--- Additional Comments From kean at armory dot com 2005-11-05 19:03 --- (In reply to comment #5) > Unfortunately it's too simple to allude to the historical handling of common > symbols. In a.out linkers when a common symbol appears in an object, and the > symbol is defined in an object in an archive, then the object in the archive > is > pulled into the link (actually this is somewhat target dependent--the SunOS You sure about that? I tries on OpenServer and UnixWare. On OSR5, I tried in both COFF and ELF modes. In all three cases, the symbol was pulled from the object and NOT the archive. The SunOS behaviour you described is a bit funky :) > This last behaviour is of course pretty crazy. But in general it isn't > reasonable for the ELF ABI to claim that they just rely on historical > behaviour > for the definition of common symbols, because in fact ELF common symbols do > not > act like historical ones do. Thats a fair comment. I guess it depends on whose view of "historical" behaviour you take. The author of the gABI is of course a UnixWare-head, so his notion of "historical" may be a wee bit biased. But he has been with AT&T/USL/Novell/SCO/Caldera/SCO-again for an aweful long time, and is a mine of historical info. > That said, I was never all that happy with this change, and I think the > behaviour before the change was more coherent. But, unfortunately, given the > way that system files and libraries are written, it is important that we be > compatible with system linkers. You say the UnixWare linker acts differently. And OpenServer, for what thats worth (actually from a historical perspective, its worth a bit becuase its a dual-ABI system supporting both SVR3.2 COFF and SVR4 ELF). The problem I have with teh current implementation is this. Despite what looks like rational behaviour with H.J's test cases (I'll respond to his comment next), I dont think the test case proves anything except that the bahviour *looks* rational. But in terms of every day developer activities, its not. *Especially* in the case where the symbol in teh object is the same as the symbol in a system library. The particular case that casued me to discover this bug was trying to compile jwhois with a version of gcc that was newly modified to used the GNU ld (historically, on OSR5 and UnixWare, the native ld was used which was why I never saw this problem before). jwhois legitimately wants to use its own getopt() library, to support the GNU style long options. I now get a link failure becuase optopt is defined in both jwhois and libc.so. It is worth noting that libc.so is in fact a normal ar archive that has some number of objects in it that are mean to be linked directly into the a.out, as well as a copy of libc.so.1, which is what gets you the dynamic portion - a common trick). The libc.so has a member opt_Data.a, which defined optopt, optind, optarg etc. optopt is initialized to 0. In jwhois (and indeed anything that uses the GNU getopt), optopt isn't initialized, its just declared as 'char *optopt;'. By forcing the symbol to come from libc.so simply becuase the one in there is a normal data symbol and the the one in getopt.o is a common is wrong. The linker needs no other symbols from opt_data.o, and is pulling it in only because of the common/global thing. Extend that to more common cases where I want to, for example, override malloc for a debugging malloc library. If any portion of malloc had a data symbol (like a mallopt structure or some such), I would be unable to override malloc() with my spiffy new malloc-debugging library becuase GNU ld would be pulling in the object from the library. The above situation is made even worse when you are using libc.a instead of libc.so, for static links. > That suggests that we need to make this target dependent. This is precedent > for > this in the a.out linker, and the use of the common_skip_ar_aymbols field in > struct bfd_link_info. Of course I would be happy with making this behaviour optional, becuase that would get around my immediate problem and I can go about using GNU ld to my heart's content. But I think that people who think they need the current behaviour are in for some nasty surprises, as described above. I tested this on Solaris 10, and the native link editor does in fact behave the same way the GNU one does, but that doesn't necessarily make either one correct. Sorry for the rambling reply :) -- http://sourceware.org/bugzilla/show_bug.cgi?id=1811 --- 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 ld/1811] ELF linker loads member of archive for common symbol
--- Additional Comments From kean at armory dot com 2005-11-05 19:06 --- > I think Solaris linker hehavior makes some senses. Kean, can you try > this testcase with your linker? I agree on teh surface it makes sense, but it also has very specific broken behaviour. See previous comment. > ./main1 > 3 > > ./main2 > 3 > > ./main3 > 3 > I get: ./main1 0 ./main2 3 ./main3 3 On OSR5 in COFF mode (no main3 becasue no shared libraries): ./main1 0 ./main2 3 The above using the native tools of course. Using gcc, I get the same results you do becuase its using the same ld you are. -- http://sourceware.org/bugzilla/show_bug.cgi?id=1811 --- 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/1804] Wrong output for 64-bit difference of labels
--- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca
2005-11-06 00:27 ---
Subject: Re: Wrong output for 64-bit difference of labels
> --- Additional Comments From amodra at bigpond dot net dot au 2005-11-05
> 08:36 ---
> This is caused by tc-hppa.c:md_apply_fix treating the fixup as only being 32
> bit.
Does this look like a reasonable fix?
Dave
--
J. David Anglin [EMAIL PROTECTED]
National Research Council of Canada (613) 990-0752 (FAX: 952-6602)
Index: config/tc-hppa.c
===
RCS file: /cvs/src/src/gas/config/tc-hppa.c,v
retrieving revision 1.126
diff -u -3 -p -r1.126 tc-hppa.c
--- config/tc-hppa.c13 Oct 2005 01:06:01 - 1.126
+++ config/tc-hppa.c6 Nov 2005 00:13:48 -
@@ -4436,7 +4436,7 @@ md_apply_fix (fixP, valP, seg)
valueT *valP;
segT seg ATTRIBUTE_UNUSED;
{
- unsigned char *buf;
+ char *fixpos;
struct hppa_fix_struct *hppa_fixP;
offsetT new_val;
int insn, val, fmt;
@@ -4481,8 +4481,16 @@ md_apply_fix (fixP, valP, seg)
return;
}
- buf = (unsigned char *) (fixP->fx_frag->fr_literal + fixP->fx_where);
- insn = bfd_get_32 (stdoutput, buf);
+ fixpos = fixP->fx_frag->fr_literal + fixP->fx_where;
+
+ /* Handle fixups for complex expressions that evaluate to a constant. */
+ if (fixP->fx_r_type == R_HPPA_COMPLEX && fixP->fx_done)
+{
+ number_to_chars_bigendian (fixpos, *valP, fixP->fx_size);
+ return;
+}
+
+ insn = bfd_get_32 (stdoutput, fixpos);
fmt = bfd_hppa_insn2fmt (stdoutput, insn);
/* If there is a symbol associated with this fixup, then it's something
@@ -4652,7 +4660,7 @@ md_apply_fix (fixP, valP, seg)
}
/* Insert the relocation. */
- bfd_put_32 (stdoutput, insn, buf);
+ bfd_put_32 (stdoutput, insn, fixpos);
}
/* Exactly what point is a PC-relative offset relative TO?
--
http://sourceware.org/bugzilla/show_bug.cgi?id=1804
--- 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/1804] Wrong output for 64-bit difference of labels
--- Additional Comments From amodra at bigpond dot net dot au 2005-11-06
03:12 ---
I'd be inclined to use
if (fixP->fx_size > 4)
{
/* Handle constant output. */
number_to_chars_bigendian (fixpos, *valP, fixP->fx_size);
return;
}
After all, if the fixup is for a dword, none of the insn handling code in
md_apply_fix is appropriate. In fact, it would be even better to avoid anything
in md_apply_fix that assumes a fixup is for an insn, ie. bfd_hppa_insn2fmt
shouldn't be in md_apply_fix at all. Instead, pass the insn fmt (if it is an
insn) in via fx_r_format.
--
http://sourceware.org/bugzilla/show_bug.cgi?id=1804
--- 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/1804] Wrong output for 64-bit difference of labels
--- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca
2005-11-06 03:57 ---
Subject: Re: Wrong output for 64-bit difference of labels
> --- Additional Comments From amodra at bigpond dot net dot au 2005-11-06
> 03:12 ---
> I'd be inclined to use
>
> if (fixP->fx_size > 4)
I was thinking that other sizes might in theory be used for expressions.
For example, GCC uses .word for label differences in switch tables.
>{
> /* Handle constant output. */
> number_to_chars_bigendian (fixpos, *valP, fixP->fx_size);
> return;
>}
>
> After all, if the fixup is for a dword, none of the insn handling code in
> md_apply_fix is appropriate. In fact, it would be even better to avoid
> anything
> in md_apply_fix that assumes a fixup is for an insn, ie. bfd_hppa_insn2fmt
> shouldn't be in md_apply_fix at all. Instead, pass the insn fmt (if it is an
> insn) in via fx_r_format.
I agree. It appears that there aren't any conflicts between data and
insn format values. It also appears that insn formats are set by pa_ip,
so it shouldn't be necessary to call bfd_hppa_insn2fmt.
I'm amazed that data fixups work at all on hppa64.
Dave
--
http://sourceware.org/bugzilla/show_bug.cgi?id=1804
--- 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 ld/1811] ELF linker loads member of archive for common symbol
--- Additional Comments From ian at airs dot com 2005-11-06 04:58 --- Am I sure about the a.out behaviour? Yes, I am. When I refer to SunOS I do mean SunOS 4, pre Solaris, which used the a.out object file format. The strange behaviour of common symbols increasing size even without linking in the object file was used to make stdin/stdout/stderr work in the traditional a.out libc. A linker which failed to implement it correctly could not link a "hello, world" program. AT&T went to COFF in SVR3, and they changed the behaviour of common symbols at that time. I've used SVR2, but I don't have a clear recollection of how the linker worked. I think that on Solaris we have to do what the native linker does. Likewise on UnixWare. So if they have different behaviour, we have to have different defaults. It would of course be reasonable to provide a command line option to control this. -- http://sourceware.org/bugzilla/show_bug.cgi?id=1811 --- 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
