RE: [Bug] ld aborts linking large ieee file

RE: [Bug] ld aborts linking large ieee file

[Smith, Gene]

Hi Nick,

> -----Original Message-----
> From: Nick Clifton [mailto:nickc@redhat.com]
> Sent: Thursday, March 13, 2003 10:33 AM
>
> Hi Gene,
> 
> > Gene Smith wrote:
> >  > Also, if I try to do a objcopy of the large 3rd party ieee file
> > (even > with no transformation) objcopy segfaults.  
> However, the large
> > 3rd >party ieee file lists nicely with objdump.
> > 
> > gdb shows this caused by a call to ieee_write_expression() in
> > bfd/ieee.c:2496 (binutils 2.13) with a NULL pointer in 3rd parameter
> > (pointer to asymbol). The null pointer is shortly 
> de-referenced inside
> > the function causing segfault. Don't see a difference in latest
> > cvs. Don't know all that is going on but perhaps should just return
> > false instead of calling ieee_write_expression() when r->sym_ptr_ptr
> > is null at li 2486?
> 
> Hmm, I think this one will need some more investigation.  Do you have
> a *small* file that reproduces this problem (rather than the large 3rd
> party version) that you could send to me ?  if not, then can you put
> the large file somewhere where I can download it via FTP ?  (Assuming
> that you are allowed to make this file public).
> 
> Cheers
>         Nick
> 
> PS.  Is this problem related to the other ieee linking problem that
> you posted earlier ("ld 2.13 dumps core/seg faults") ?
>

Yes, the problems are related and occur only when the 3rd party file is
linked (with ld) or copied (with objcopy). In both cases (according to the
debugger) they are having problems with two symbols that appear 1st in the
symbol table shown with objdump -xD (objdump works ok with the 3rd-p file).
Here is how it looks:

SYMBOL TABLE:
00000000	*ABS* 0020 00 conlist
00000000	*ABS* 0021 00 globaltr
   :

After this, many other symbols are listed. conlist and globaltr don't seem
to appear any where else in the listing. Have no idea what the symbols do or
what most of the columns in the symbol table mean. There is another ABS
symbol further down that looks like this (and there is no problem with it):
:
00000000 g	*ABS* 0414 00 ____FPU
:

(It has a "g" (global?) like all the other symbols.)

I was able to rebuild a changed-by-me version of objcopy so the null pointer
is not used and produced a modified 3rd-p file which when dumped looks like
this:

SYMBOL TABLE:
* empty table entry
* empty table entry
   :				(all below is unchanged)

When I ld the modified 3rd-p file (with many other files) it works without
the abort and does not complain about the empty table entries.
-gene 





 

Re: [Bug] ld aborts linking large ieee file

[Nick Clifton]

Hi Gene,

> When I ld the modified 3rd-p file (with many other files) it works without
> the abort and does not complain about the empty table entries.

Ok - can you post the patch you used ?  If it is small/simple enough
then we can accept it as "obvious" and so not need a copyright
assignment.  It may be a bit of a hack, but if allows the tools to
work and not seg-fault then it is a good thing.

Cheers
        Nick

Re: [Bug] ld aborts linking large ieee file

[Elias Athanasopoulos]

On Thu, Mar 13, 2003 at 12:09:29PM -0500, Smith, Gene wrote:
> Yes, the problems are related and occur only when the 3rd party file is
> linked (with ld) or copied (with objcopy). In both cases (according to the
> debugger) they are having problems with two symbols that appear 1st in the
> symbol table shown with objdump -xD (objdump works ok with the 3rd-p file).
> Here is how it looks:
> 
> SYMBOL TABLE:
> 00000000	*ABS* 0020 00 conlist
> 00000000	*ABS* 0021 00 globaltr
>    :

How can a symbol be neither local nor global?

ANW, have you tried localize (or globalize) these symbols with objcopy? 
Although you wrote that objcopy segfaults, I guess it doesn't always;
it depends on the operation you are asking.

Elias

-- 
University of Athens			I bet the human brain 
Physics Department				is a kludge --Marvin Minsky 

	

RE: [Bug] ld aborts linking large ieee file

[Smith, Gene]

> -----Original Message-----
> From: Elias Athanasopoulos [mailto:elathan@phys.uoa.gr]
> Sent: Friday, March 14, 2003 4:16 AM
> > 
> > SYMBOL TABLE:
> > 00000000	*ABS* 0020 00 conlist
> > 00000000	*ABS* 0021 00 globaltr
> >    :
> 
> How can a symbol be neither local nor global?
> 
> ANW, have you tried localize (or globalize) these symbols 
> with objcopy? 
> Although you wrote that objcopy segfaults, I guess it doesn't always;
> it depends on the operation you are asking.
> 
> Elias
> 
> -- 
> University of Athens			I bet the human brain 
> Physics Department				is a kludge 
> --Marvin Minsky 
 
With option "-L conlist -L globaltr" (localize sym) my modified objcopy now
segfaults. Don't see option to globalize a symbol in objcopy.
-gene	
 

Re: [Bug] ld aborts linking large ieee file

[Nick Clifton]

Hi Gene,

> The patch is against bfd/ieee.c 1.27 in cvs (from binutils-2.13) and it
> prevents objcopy from crashing when copying the original 3rd-party ieee
> file. With this patch applied the transformed 3rd-p file can then be linked
> without causing an abort() in ld. I have not touched the ld code.

Thanks - I have applied your patch with a small change.  Rather than
using a goto I have just enclosed the symbol using code inside a "if
(symbol != NULL) {....}" block.  I also added some minor formatting
fixups to other areas in the file.

Cheers
        Nick

2003-03-14  Gene Smith  <gene.smith@siemens.com>

	* ieee.c (ieee_write_expression): Handle the case where symbol is
	NULL.
	General formatting improvements.

RE: [Bug] ld aborts linking large ieee file

[Smith, Gene]

> -----Original Message-----
> From: Nick Clifton [mailto:nickc@redhat.com]
> Sent: Thursday, March 13, 2003 1:48 PM
> 
> Hi Gene,
> 
> > When I ld the modified 3rd-p file (with many other files) 
> it works without
> > the abort and does not complain about the empty table entries.
> 
> Ok - can you post the patch you used ?  If it is small/simple enough
> then we can accept it as "obvious" and so not need a copyright
> assignment.  It may be a bit of a hack, but if allows the tools to
> work and not seg-fault then it is a good thing.
> 
> Cheers
>         Nick

I also tried the latest stable binutils-2.13.2.1 and got the same problem in
objcopy. Did not try ld.

The patch is against bfd/ieee.c 1.27 in cvs (from binutils-2.13) and it
prevents objcopy from crashing when copying the original 3rd-party ieee
file. With this patch applied the transformed 3rd-p file can then be linked
without causing an abort() in ld. I have not touched the ld code.

It could be that ieee_write_expression() should not even be called if symb
pointer is null; not sure.(Sorry for the goto, just trying to get it to work
with minimal line changes.) 

--- ieee.c	Thu Mar 13 16:27:23 2003
+++ ieee.c.new	Wed Mar 12 09:44:41 2003
@@ -322,6 +322,9 @@ ieee_write_expression (abfd, value, symb
       term_count++;
     }
 
+  if (symbol == (asymbol *)NULL)
+    goto ck_pcrel;
+
   if (bfd_is_com_section (symbol->section)
       || bfd_is_und_section (symbol->section))
     {
@@ -369,7 +372,9 @@ ieee_write_expression (abfd, value, symb
 	  return false;
 	}
     }
-
+  
+ck_pcrel:
+  
   if (pcrel)
     {
       /* subtract the pc from here by asking for PC of this section*/

Re: [Bug] ld aborts linking large ieee file

[Nick Clifton]

Hi Gene,

> Gene Smith wrote:
>  > Also, if I try to do a objcopy of the large 3rd party ieee file
> (even > with no transformation) objcopy segfaults.  However, the large
> 3rd >party ieee file lists nicely with objdump.
> 
> gdb shows this caused by a call to ieee_write_expression() in
> bfd/ieee.c:2496 (binutils 2.13) with a NULL pointer in 3rd parameter
> (pointer to asymbol). The null pointer is shortly de-referenced inside
> the function causing segfault. Don't see a difference in latest
> cvs. Don't know all that is going on but perhaps should just return
> false instead of calling ieee_write_expression() when r->sym_ptr_ptr
> is null at li 2486?

Hmm, I think this one will need some more investigation.  Do you have
a *small* file that reproduces this problem (rather than the large 3rd
party version) that you could send to me ?  if not, then can you put
the large file somewhere where I can download it via FTP ?  (Assuming
that you are allowed to make this file public).

Cheers
        Nick

PS.  Is this problem related to the other ieee linking problem that
you posted earlier ("ld 2.13 dumps core/seg faults") ?

Re: [Bug] ld aborts linking large ieee file

[Gene Smith]

Gene Smith wrote:
 > Also, if I try to do a objcopy of the large 3rd party ieee file (even 
 > with no transformation) objcopy segfaults.  However, the large 3rd 
 >party ieee file lists nicely with objdump.

gdb shows this caused by a call to ieee_write_expression() in 
bfd/ieee.c:2496 (binutils 2.13) with a NULL pointer in 3rd parameter 
(pointer to asymbol). The null pointer is shortly de-referenced inside 
the function causing segfault. Don't see a difference in latest cvs. 
Don't know all that is going on but perhaps should just return false 
instead of calling ieee_write_expression() when r->sym_ptr_ptr is null 
at li 2486?
-gene

[Bug] ld aborts linking large ieee file

[Smith, Gene]

I received the following error when trying to link my code with a large
third-party ieee-695 file (which works with mri linker). 

"m68k-rtems-ld: BFD 2.13 internal error, aborting at ../../bfd/linker.c
line 2385 in _bfd_generic_link_output_symbols
 
m68k-rtems-ld: Please report this bug."

Also, if I try to do a objcopy of the large 3rd party ieee file (even with
no transformation) objcopy segfaults.  However, the large 3rd party ieee
file lists nicely with objdump.

Tks,
gene
P/s: reported this on bug-binutils also but it looks like a spam-infested
black hole.