This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[PATCH 1/3] LD: Convert `%P: %H:' to `%H:' in error messages


Similarly to commit 174d0a74a2e6 ("PowerPC/BFD: Convert `%P: %H:' to 
`%H:' in error messages") convert linker relocation error messages to 
use `%H:' rather `%P: %H:', removing inconsistent message composition 
like:

$ cat reloc-j.s
	.text
	.globl	foo
	.ent	foo
foo:
	j	bar
	j	bar
	.end	foo
$ cat reloc-j.ld
SECTIONS
{
  bar = 0x12345678;
  .text : { *(.text) }
  /DISCARD/ : { *(*) }
}
$ as -o reloc-j.o reloc-j.s
$ ld -T reloc-j.ld -o reloc-j reloc-j.o
ld: tmpdir/reloc-j.o: in function `foo':
(.text+0x0): relocation truncated to fit: R_MIPS_26 against `bar'
ld: (.text+0x8): relocation truncated to fit: R_MIPS_26 against `bar'
$ 

where subsequent lines referring to issues within a single function have 
the name of the linker executable prepended, but the first one does not.

As noted with the commit referred this breaks a GNU Coding Standard's 
requirement that error messages from compilers should look like this:

source-file-name:lineno: message

also quoted in `vfinfo' code handling these specifiers.

Remove the linker name prefix then, making the messages now look like:

$ ld -T reloc-j.ld -o reloc-j reloc-j.o
tmpdir/reloc-j.o: in function `foo':
(.text+0x0): relocation truncated to fit: R_MIPS_26 against `bar'
(.text+0x8): relocation truncated to fit: R_MIPS_26 against `bar'
$ 

instead.

	ld/
	* ldmain.c (reloc_overflow): Use `%H:' rather than `%P: %H:' 
	with `einfo'.
	(reloc_dangerous): Likewise.
	(unattached_reloc): Likewise.
---
Hi,

 To double-check I have not been doing something silly here I ran GCC over 
this broken program:

$ cat bad.c
int foo;

int main(void)
{
	return foo();
}
$ 

and that caused the compiler to report an error with a message structured 
similarly to our linker message concerned here, which varied slightly 
depending on the version of the compiler used, like:

$ gcc -O2 -o bad bad.c
bad.c: In function 'main':
bad.c:5: error: called object 'foo' is not a function
$ 

or:

$ gcc -O2 -o bad bad.c
bad.c: In function 'main':
bad.c:5:9: error: called object 'foo' is not a function or function pointer
  return foo();
         ^~~
bad.c:1:5: note: declared here
 int foo;
     ^~~
$ 

however neither variant of the message was prefixed with the name of the 
reporting executable (`cc1').  Which makes me feel confident I am on the 
right track.

 I think we might want to convert `%P: %C:' similarly, however I do not 
have a test case readily available, so I decided not to experiment with 
that at this time.  A MIPS-specific test case for `reloc_overflow' is 
included with 3/3, so at least we'll have minimal coverage.

 OK to apply then?

  Maciej
---
 ld/ldmain.c |    6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

binutils-ld-vfinfo-file-null-reloc.diff
Index: src/ld/ldmain.c
===================================================================
--- src.orig/ld/ldmain.c
+++ src/ld/ldmain.c
@@ -1421,7 +1421,7 @@ reloc_overflow (struct bfd_link_info *in
   if (overflow_cutoff_limit == -1)
     return;
 
-  einfo ("%X%P: %H:", abfd, section, address);
+  einfo ("%X%H:", abfd, section, address);
 
   if (overflow_cutoff_limit >= 0
       && overflow_cutoff_limit-- == 0)
@@ -1474,7 +1474,7 @@ reloc_dangerous (struct bfd_link_info *i
 		 asection *section,
 		 bfd_vma address)
 {
-  einfo (_("%X%P: %H: dangerous relocation: %s\n"),
+  einfo (_("%X%H: dangerous relocation: %s\n"),
 	 abfd, section, address, message);
 }
 
@@ -1488,7 +1488,7 @@ unattached_reloc (struct bfd_link_info *
 		  asection *section,
 		  bfd_vma address)
 {
-  einfo (_("%X%P: %H: reloc refers to symbol `%pT' which is not being output\n"),
+  einfo (_("%X%H: reloc refers to symbol `%pT' which is not being output\n"),
 	 abfd, section, address, name);
 }
 


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]