This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: Broken -frepo (was Re: PATCH: PR ld/1396: prohibited cross reference to a local symbol)
- From: Jakub Jelinek <jakub at redhat dot com>
- To: "H. J. Lu" <hjl at lucon dot org>
- Cc: binutils at sources dot redhat dot com, gcc-patches at gcc dot gnu dot org
- Date: Thu, 30 Mar 2006 18:47:25 +0200
- Subject: Re: Broken -frepo (was Re: PATCH: PR ld/1396: prohibited cross reference to a local symbol)
- References: <2734.192.168.201.6.1128350711.squirrel@pc300> <20051004195249.GB13574@lucon.org> <20060330135134.GC30252@sunsite.mff.cuni.cz> <20060330151554.GA8047@lucon.org>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Thu, Mar 30, 2006 at 07:15:54AM -0800, H. J. Lu wrote:
> When .o file isn't compiled with -g, the old linker outputs:
>
> lib.o: In function `bar':
> : prohibited cross reference from .text to `foo' in .foo
>
> I changed it to one line:
>
> lib.o: In function `bar': prohibited cross reference from .text to `foo' in .foo
>
> I have no strong opinion one way or the other.
Digging some more into vfinfo, this sounds very wrong.
<bfd>: In function `function':
is on a separate line for a reason - if there is more than one error
with the same bfd/filename/function, ld will emit it just once, and with
In function on the same line that's just plain ugly (in addition that it
breaks tools that parse ld output). Say:
a.o: In function `main':a.C:(.text+0xd): undefined reference to `C<int>::C()'
a.C:(.text+0x2b): undefined reference to `foobar'
where previously we would print here:
a.o: In function `main':
a.C:(.text+0xd): undefined reference to `C<int>::C()'
a.C:(.text+0x2b): undefined reference to `foobar'
(in both cases the In function `main' is for both errors, but it is really
non-obvious in the first case).
The reason why you got the ugly
lib.o: In function `bar':
: prohibited cross reference from .text to `foo' in .foo
is IMHO because ld just failed to print the location.
When bfd_find_nearest_line fails, it will for %C print:
lib.o:(.text+0x7): prohibited cross reference from .text to `foo' in .foo
so I don't understand why it doesn't provide section/offset also when it
knows the function name, but doesn't know file/line. The following patch
reverts the ldmisc.c changes from last October and makes ld print for your
testcase (if I revert the ldcref.c fix, otherwise I don't get the error
obviously)
lib.o: In function `bar':
(.text+0x7): prohibited cross reference from .text to `foo' in .foo
Ok for trunk?
2006-03-30 Jakub Jelinek <jakub@redhat.com>
* ldmisc.c (vfinfo): Revert 2005-10-05 changes. If
bfd_find_nearest_line succeeded for %C or %D, but filename
is NULL, print section+offset at the end.
--- ld/ldmisc.c.jj 2005-12-14 13:50:35.000000000 +0100
+++ ld/ldmisc.c 2006-03-30 18:23:59.000000000 +0200
@@ -1,6 +1,6 @@
/* ldmisc.c
Copyright 1991, 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999, 2000,
- 2001, 2002, 2003, 2004, 2005
+ 2001, 2002, 2003, 2004, 2005, 2006
Free Software Foundation, Inc.
Written by Steve Chamberlain of Cygnus Support.
@@ -337,7 +337,7 @@ vfinfo (FILE *fp, const char *fmt, va_li
&& strcmp (last_file, filename) != 0)
|| strcmp (last_function, functionname) != 0)
{
- lfinfo (fp, _("%B: In function `%T'"),
+ lfinfo (fp, _("%B: In function `%T':\n"),
abfd, functionname);
last_bfd = abfd;
@@ -353,20 +353,17 @@ vfinfo (FILE *fp, const char *fmt, va_li
discard_last = FALSE;
}
else
- lfinfo (fp, "%B", abfd);
+ lfinfo (fp, "%B:", abfd);
if (filename != NULL)
- fprintf (fp, ":%s", filename);
+ fprintf (fp, "%s:", filename);
if (functionname != NULL && fmt[-1] == 'G')
- lfinfo (fp, ":%T", functionname);
- else if (filename != NULL)
- {
- if (linenumber != 0)
- fprintf (fp, ":%u", linenumber);
- else
- lfinfo (fp, ":(%A+0x%v)", section, offset);
- }
+ lfinfo (fp, "%T", functionname);
+ else if (filename != NULL && linenumber != 0)
+ fprintf (fp, "%u", linenumber);
+ else
+ lfinfo (fp, "(%A+0x%v)", section, offset);
}
else
lfinfo (fp, "%B:(%A+0x%v)", abfd, section, offset);
Jakub