* XCOFF 64 function address wrong? @ 2005-03-09 8:14 David Lecomber 2005-03-09 12:53 ` Nick Clifton 0 siblings, 1 reply; 13+ messages in thread From: David Lecomber @ 2005-03-09 8:14 UTC (permalink / raw) To: binutils Reposting this because it didn't make it into the mailing list archive, so I guess it didn't make it elsewhere (although it did go through to GDB and its archive) I have a 64-bit AIX 5.2 XLC 7 compiled hello world binary. I've built up gdb and binutils with --enable-64-bit-bfd - from latest CVS. In GDB, it miscalculates the main(), as 0x428 (instead of 0x10000428). I think the trouble could be within the binutils bfd package, used by GDB. So, in using a fresh binutils's "objdump -t": [snip] AUX val 104 prmhsh 0 snhsh 0 typ 1 algn 3 clss 0 stb 0 snstb 0 [ 89](sec 1)(fl 0x00)(ty 20)(scl 2) (nx 2) 0x00000428 .main AUX tagndx 0 ttlsiz 0x68 lnnos 2806 next 100 AUX indx 87 prmhsh 0 snhsh 0 typ 2 algn 0 clss 0 stb 0 snstb 0 .main : 1 : 0x43c 2 : 0x44c [snip] Note the 0x0000428 .main, and the line number info following it, all have the wrong address.. Assuming that this is what ought to be being displayed. Curiously, if I then ask objdump to "objdump -S" it gets things right: [snip] 0000000100000428 <.main>: 100000428: 7c 08 02 a6 mflr r0 10000042c: fb e1 ff f8 std r31,-8(r1) 100000430: f8 01 00 10 std r0,16(r1) 100000434: f8 21 ff 81 stdu r1,-128(r1) 100000438: eb e2 00 80 ld r31,128(r2) [snip] For comparison, with a GCC compiled executable, those numbers are the real addresses of the functions, and GDB gets breakpoints correct. I'm willing to put some time in to getting this sorted out, but at present don't know what I'm looking for -- so any help greatly appreciated. Regards David -- David Lecomber <david@allinea.com> ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: XCOFF 64 function address wrong? 2005-03-09 8:14 XCOFF 64 function address wrong? David Lecomber @ 2005-03-09 12:53 ` Nick Clifton 2005-03-09 14:54 ` David Lecomber 0 siblings, 1 reply; 13+ messages in thread From: Nick Clifton @ 2005-03-09 12:53 UTC (permalink / raw) To: David Lecomber; +Cc: binutils Hi David, > I have a 64-bit AIX 5.2 XLC 7 compiled hello world binary. I've built > up gdb and binutils with --enable-64-bit-bfd - from latest CVS. > > In GDB, it miscalculates the main(), as 0x428 (instead of 0x10000428). This looks like a truncation to 32-bits rather than a more general miscalculation... > So, in using a fresh binutils's "objdump -t": > [ 89](sec 1)(fl 0x00)(ty 20)(scl 2) (nx 2) 0x00000428 .main > Note the 0x0000428 .main, > I'm willing to put some time in to getting this sorted out, but at > present don't know what I'm looking for -- so any help greatly > appreciated. Have a look at the function coff_print_symbol() in bfd/coffgen.c. This is the function that is printing out the incorrect value for .main. My guess is that for some reason XCOFF64 is not defined for your configuration and so it is printing a 32-bit value instead of a 64-bit value. Cheers Nick ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: XCOFF 64 function address wrong? 2005-03-09 12:53 ` Nick Clifton @ 2005-03-09 14:54 ` David Lecomber 2005-03-09 15:39 ` Nick Clifton 0 siblings, 1 reply; 13+ messages in thread From: David Lecomber @ 2005-03-09 14:54 UTC (permalink / raw) To: Nick Clifton; +Cc: binutils > Have a look at the function coff_print_symbol() in bfd/coffgen.c. This > is the function that is printing out the incorrect value for .main. My > guess is that for some reason XCOFF64 is not defined for your > configuration and so it is printing a 32-bit value instead of a 64-bit > value. > That's exactly right. Now where should that be getting defined? My config settings according to config status are: configured by ./configure, generated by GNU Autoconf 2.59, with options \"'--cache-file=./config.cache' '--build=powerpc-ibm-aix5.2.0.0' '--host=powerpc-ibm-aix5.2.0.0' '--target=powerpc-ibm-aix5.2.0.0' '--with-gnu-as' '--with-gnu-ld' '--enable-64-bit-bfd' '--program-transform-name=s,y,y,' '--srcdir=.' 'CC=gcc' 'CFLAGS=-g -O2 ' 'LDFLAGS=' 'build_alias=powerpc-ibm-aix5.2.0.0' 'host_alias=powerpc-ibm-aix5.2.0.0' 'target_alias=powerpc-ibm-aix5.2.0.0'\" Cheers David > Cheers > Nick -- David Lecomber <david@allinea.com> ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: XCOFF 64 function address wrong? 2005-03-09 14:54 ` David Lecomber @ 2005-03-09 15:39 ` Nick Clifton 2005-03-09 17:52 ` David Lecomber 0 siblings, 1 reply; 13+ messages in thread From: Nick Clifton @ 2005-03-09 15:39 UTC (permalink / raw) To: David Lecomber; +Cc: binutils Hi David, >>guess is that for some reason XCOFF64 is not defined for your >>configuration and so it is printing a 32-bit value instead of a 64-bit >>value. > That's exactly right. > > Now where should that be getting defined? A simple grep shows that it is defined in bfd/coff64-rs6000.c. > My config settings according > to config status are: > > '--target=powerpc-ibm-aix5.2.0.0' '--with-gnu-as' '--with-gnu-ld' > '--enable-64-bit-bfd' '--program-transform-name=s,y,y,' '--srcdir=.' The target would appear to be the problem. If the target was: --target=powerpc64-ibm-aix5.2.0.0 then I think that it should work. [See bfd/config.bfd for where this target is matched. Look for the targ_defvec and then compare that the list of vectors in bfd/configure.in. You want one that triggers the inclusion of coff64-rs6000]. Cheers Nick ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: XCOFF 64 function address wrong? 2005-03-09 15:39 ` Nick Clifton @ 2005-03-09 17:52 ` David Lecomber 2005-03-10 10:22 ` Nick Clifton 0 siblings, 1 reply; 13+ messages in thread From: David Lecomber @ 2005-03-09 17:52 UTC (permalink / raw) To: Nick Clifton; +Cc: binutils > The target would appear to be the problem. If the target was: > > --target=powerpc64-ibm-aix5.2.0.0 > > then I think that it should work. > Tried that -- and still the ifdef in coffgen.c is still not happening. Even tried to do --host the same too.. > [See bfd/config.bfd for where this target is matched. Look for the > targ_defvec and then compare that the list of vectors in > bfd/configure.in. You want one that triggers the inclusion of > coff64-rs6000]. But how could coff64-rs6000.c file #defining a value influence coffgen.c (unless there's some autogeneration going on here)? Shouldn't this be in a .h file? Is there a better test for XCOFF64/32 status than a compile time ifdef - surely we'd want mixed capability? Ta, David -- David Lecomber <david@allinea.com> ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: XCOFF 64 function address wrong? 2005-03-09 17:52 ` David Lecomber @ 2005-03-10 10:22 ` Nick Clifton 2005-03-10 21:56 ` David Lecomber 0 siblings, 1 reply; 13+ messages in thread From: Nick Clifton @ 2005-03-10 10:22 UTC (permalink / raw) To: David Lecomber; +Cc: binutils [-- Attachment #1: Type: text/plain, Size: 1049 bytes --] Hi David, > But how could coff64-rs6000.c file #defining a value influence coffgen.c > (unless there's some autogeneration going on here)? It can't. You have uncovered a bug. > Shouldn't this be > in a .h file? Is there a better test for XCOFF64/32 status than a > compile time ifdef - surely we'd want mixed capability? Exactly. The idea was that XCOFF64 was defined in coff64-rs6000.c which then included coffcode.h. If support for 32-bit COFF targets was also being included in the bfd library then their *.c files would include coffcode.h without defining XCOFF64 and so both 32-bit and 64-bit formats would be supported. As you have discovered this does not work with the current way that the coff_print_symbol() function is coded in coffgen.c. Would you like to try the attached, untested patch ? It is at best a workaround since all it really does is to try to make sure that if a symbol has a 64-bit value then it is displayed as such, but at least this is better than displaying a truncated version. Cheers Nick [-- Attachment #2: coffgen.c.patch --] [-- Type: text/plain, Size: 2415 bytes --] Index: bfd/coffgen.c =================================================================== RCS file: /cvs/src/src/bfd/coffgen.c,v retrieving revision 1.48 diff -c -3 -p -r1.48 coffgen.c *** bfd/coffgen.c 21 Feb 2005 11:21:29 -0000 1.48 --- bfd/coffgen.c 10 Mar 2005 10:03:45 -0000 *************** coff_print_symbol (abfd, filep, symbol, *** 1991,2018 **** else val = combined->u.syment.n_value - (unsigned long) root; - #ifndef XCOFF64 fprintf (file, ! "(sec %2d)(fl 0x%02x)(ty %3x)(scl %3d) (nx %d) 0x%08lx %s", combined->u.syment.n_scnum, combined->u.syment.n_flags, combined->u.syment.n_type, combined->u.syment.n_sclass, ! combined->u.syment.n_numaux, ! (unsigned long) val, ! symbol->name); ! #else ! /* Print out the wide, 64 bit, symbol value */ ! fprintf (file, ! "(sec %2d)(fl 0x%02x)(ty %3x)(scl %3d) (nx %d) 0x%016llx %s", ! combined->u.syment.n_scnum, ! combined->u.syment.n_flags, ! combined->u.syment.n_type, ! combined->u.syment.n_sclass, ! combined->u.syment.n_numaux, ! val, ! symbol->name); ! #endif for (aux = 0; aux < combined->u.syment.n_numaux; aux++) { --- 1991,2019 ---- else val = combined->u.syment.n_value - (unsigned long) root; fprintf (file, ! "(sec %2d)(fl 0x%02x)(ty %3x)(scl %3d) (nx %d) ", combined->u.syment.n_scnum, combined->u.syment.n_flags, combined->u.syment.n_type, combined->u.syment.n_sclass, ! combined->u.syment.n_numaux); ! ! /* We used to test for XCOFF64 being defined here in order to ! determine whether we are displaying 64-bit or 32-bit symbol ! values. But this does not work because XCOFF64 is only defined ! in coff64-rs6000.c just before it includes coffcode.h. Instead ! we check the symbols's value and see if any of the top 32 bits ! are set. This is not ideal since it can lead to mixed styles ! in the output, but it does at least mean that 64-bit symbols will ! not be displayed in a truncated fashion. */ ! if (val <= 0xFFFFFFFFULL) ! fprintf (file, "0x%08lx", (unsigned long) val); ! else ! /* Print out the wide, 64 bit, symbol value. */ ! fprintf (file, "0x%016llx", val); ! ! fprintf (file, " %s", symbol->name); for (aux = 0; aux < combined->u.syment.n_numaux; aux++) { ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: XCOFF 64 function address wrong? 2005-03-10 10:22 ` Nick Clifton @ 2005-03-10 21:56 ` David Lecomber 2005-03-11 10:37 ` Nick Clifton 0 siblings, 1 reply; 13+ messages in thread From: David Lecomber @ 2005-03-10 21:56 UTC (permalink / raw) To: Nick Clifton; +Cc: binutils > Would you like to try the attached, untested patch ? It is at best a > workaround since all it really does is to try to make sure that if a > symbol has a 64-bit value then it is displayed as such, but at least > this is better than displaying a truncated version. > This fixes partially the problem -- the .main is properly addressed -- but the line numbering list remains truncated -- this being the 1 : 0x43c bit: [ 89](sec 1)(fl 0x00)(ty 20)(scl 2) (nx 2) 0x0000000100000428 .main AUX tagndx 0 ttlsiz 0x68 lnnos 2806 next 100 AUX indx 87 prmhsh 0 snhsh 0 typ 2 algn 0 clss 0 stb 0 snstb 0 .main : 1 : 0x43c 2 : 0x44c Thanks d. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: XCOFF 64 function address wrong? 2005-03-10 21:56 ` David Lecomber @ 2005-03-11 10:37 ` Nick Clifton 2005-03-24 2:03 ` David Lecomber 0 siblings, 1 reply; 13+ messages in thread From: Nick Clifton @ 2005-03-11 10:37 UTC (permalink / raw) To: David Lecomber; +Cc: binutils [-- Attachment #1: Type: text/plain, Size: 289 bytes --] Hi David, > This fixes partially the problem -- the .main is properly addressed -- > but the line numbering list remains truncated -- this being the > 1 : 0x43c bit: Ah yes. Please try this revised patch (instead of the previous one, rather than in addition to it). Cheers Nick [-- Attachment #2: coffgen.c.patch --] [-- Type: text/plain, Size: 3091 bytes --] Index: bfd/coffgen.c =================================================================== RCS file: /cvs/src/src/bfd/coffgen.c,v retrieving revision 1.48 diff -c -3 -p -r1.48 coffgen.c *** bfd/coffgen.c 21 Feb 2005 11:21:29 -0000 1.48 --- bfd/coffgen.c 11 Mar 2005 10:35:38 -0000 *************** coff_print_symbol (abfd, filep, symbol, *** 1991,2018 **** else val = combined->u.syment.n_value - (unsigned long) root; - #ifndef XCOFF64 fprintf (file, ! "(sec %2d)(fl 0x%02x)(ty %3x)(scl %3d) (nx %d) 0x%08lx %s", combined->u.syment.n_scnum, combined->u.syment.n_flags, combined->u.syment.n_type, combined->u.syment.n_sclass, ! combined->u.syment.n_numaux, ! (unsigned long) val, ! symbol->name); ! #else ! /* Print out the wide, 64 bit, symbol value */ ! fprintf (file, ! "(sec %2d)(fl 0x%02x)(ty %3x)(scl %3d) (nx %d) 0x%016llx %s", ! combined->u.syment.n_scnum, ! combined->u.syment.n_flags, ! combined->u.syment.n_type, ! combined->u.syment.n_sclass, ! combined->u.syment.n_numaux, ! val, ! symbol->name); ! #endif for (aux = 0; aux < combined->u.syment.n_numaux; aux++) { --- 1991,2019 ---- else val = combined->u.syment.n_value - (unsigned long) root; fprintf (file, ! "(sec %2d)(fl 0x%02x)(ty %3x)(scl %3d) (nx %d) ", combined->u.syment.n_scnum, combined->u.syment.n_flags, combined->u.syment.n_type, combined->u.syment.n_sclass, ! combined->u.syment.n_numaux); ! ! /* We used to test for XCOFF64 being defined here in order to ! determine whether we are displaying 64-bit or 32-bit symbol ! values. But this does not work because XCOFF64 is only defined ! in coff64-rs6000.c just before it includes coffcode.h. Instead ! we check the symbols's value and see if any of the top 32 bits ! are set. This is not ideal since it can lead to mixed styles ! in the output, but it does at least mean that 64-bit symbols will ! not be displayed in a truncated fashion. */ ! if (val <= 0xFFFFFFFFULL) ! fprintf (file, "0x%08lx", (unsigned long) val); ! else ! /* Print out the wide, 64 bit, symbol value. */ ! fprintf (file, "0x%016llx", val); ! ! fprintf (file, " %s", symbol->name); for (aux = 0; aux < combined->u.syment.n_numaux; aux++) { *************** coff_print_symbol (abfd, filep, symbol, *** 2091,2100 **** l++; while (l->line_number) { ! fprintf (file, "\n%4d : 0x%lx", ! l->line_number, ! ((unsigned long) ! (l->u.offset + symbol->section->vma))); l++; } } --- 2092,2107 ---- l++; while (l->line_number) { ! fprintf (file, "\n%4d : ", l->line_number); ! ! val = l->u.offset + symbol->section->vma; ! ! /* See comment about XCOFF64 above. */ ! if (val <= 0xFFFFFFFFULL) ! fprintf (file, "0x%lx", (unsigned long) val); ! else ! fprintf (file, "0x%llx", val); ! l++; } } ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: XCOFF 64 function address wrong? 2005-03-11 10:37 ` Nick Clifton @ 2005-03-24 2:03 ` David Lecomber 2005-04-04 16:19 ` Nick Clifton 0 siblings, 1 reply; 13+ messages in thread From: David Lecomber @ 2005-03-24 2:03 UTC (permalink / raw) To: Nick Clifton; +Cc: binutils Hi Nick Sorry for the delay -- our p615 decided to clean its hard disk... This revised fix does indeed resolve the problems: output is now as the full 64-bit address. I have compiled this without the --enable-64-bit- bfd - is this flag necessary these days? Regards David On Fri, 2005-03-11 at 10:48 +0000, Nick Clifton wrote: > Hi David, > > > This fixes partially the problem -- the .main is properly addressed -- > > but the line numbering list remains truncated -- this being the > > 1 : 0x43c bit: > > Ah yes. Please try this revised patch (instead of the previous one, > rather than in addition to it). > > Cheers > Nick > > > plain text document attachment (coffgen.c.patch) > Index: bfd/coffgen.c > =================================================================== > RCS file: /cvs/src/src/bfd/coffgen.c,v > retrieving revision 1.48 > diff -c -3 -p -r1.48 coffgen.c > *** bfd/coffgen.c 21 Feb 2005 11:21:29 -0000 1.48 > --- bfd/coffgen.c 11 Mar 2005 10:35:38 -0000 > *************** coff_print_symbol (abfd, filep, symbol, > *** 1991,2018 **** > else > val = combined->u.syment.n_value - (unsigned long) root; > > - #ifndef XCOFF64 > fprintf (file, > ! "(sec %2d)(fl 0x%02x)(ty %3x)(scl %3d) (nx %d) 0x%08lx %s", > combined->u.syment.n_scnum, > combined->u.syment.n_flags, > combined->u.syment.n_type, > combined->u.syment.n_sclass, > ! combined->u.syment.n_numaux, > ! (unsigned long) val, > ! symbol->name); > ! #else > ! /* Print out the wide, 64 bit, symbol value */ > ! fprintf (file, > ! "(sec %2d)(fl 0x%02x)(ty %3x)(scl %3d) (nx %d) 0x%016llx %s", > ! combined->u.syment.n_scnum, > ! combined->u.syment.n_flags, > ! combined->u.syment.n_type, > ! combined->u.syment.n_sclass, > ! combined->u.syment.n_numaux, > ! val, > ! symbol->name); > ! #endif > > for (aux = 0; aux < combined->u.syment.n_numaux; aux++) > { > --- 1991,2019 ---- > else > val = combined->u.syment.n_value - (unsigned long) root; > > fprintf (file, > ! "(sec %2d)(fl 0x%02x)(ty %3x)(scl %3d) (nx %d) ", > combined->u.syment.n_scnum, > combined->u.syment.n_flags, > combined->u.syment.n_type, > combined->u.syment.n_sclass, > ! combined->u.syment.n_numaux); > ! > ! /* We used to test for XCOFF64 being defined here in order to > ! determine whether we are displaying 64-bit or 32-bit symbol > ! values. But this does not work because XCOFF64 is only defined > ! in coff64-rs6000.c just before it includes coffcode.h. Instead > ! we check the symbols's value and see if any of the top 32 bits > ! are set. This is not ideal since it can lead to mixed styles > ! in the output, but it does at least mean that 64-bit symbols will > ! not be displayed in a truncated fashion. */ > ! if (val <= 0xFFFFFFFFULL) > ! fprintf (file, "0x%08lx", (unsigned long) val); > ! else > ! /* Print out the wide, 64 bit, symbol value. */ > ! fprintf (file, "0x%016llx", val); > ! > ! fprintf (file, " %s", symbol->name); > > for (aux = 0; aux < combined->u.syment.n_numaux; aux++) > { > *************** coff_print_symbol (abfd, filep, symbol, > *** 2091,2100 **** > l++; > while (l->line_number) > { > ! fprintf (file, "\n%4d : 0x%lx", > ! l->line_number, > ! ((unsigned long) > ! (l->u.offset + symbol->section->vma))); > l++; > } > } > --- 2092,2107 ---- > l++; > while (l->line_number) > { > ! fprintf (file, "\n%4d : ", l->line_number); > ! > ! val = l->u.offset + symbol->section->vma; > ! > ! /* See comment about XCOFF64 above. */ > ! if (val <= 0xFFFFFFFFULL) > ! fprintf (file, "0x%lx", (unsigned long) val); > ! else > ! fprintf (file, "0x%llx", val); > ! > l++; > } > } -- David Lecomber <david@allinea.com> ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: XCOFF 64 function address wrong? 2005-03-24 2:03 ` David Lecomber @ 2005-04-04 16:19 ` Nick Clifton 2005-04-15 11:49 ` Nick Clifton 2005-05-16 17:07 ` David Lecomber 0 siblings, 2 replies; 13+ messages in thread From: Nick Clifton @ 2005-04-04 16:19 UTC (permalink / raw) To: David Lecomber; +Cc: binutils [-- Attachment #1: Type: text/plain, Size: 615 bytes --] Hi David, > This revised fix does indeed resolve the problems: output is now as the > full 64-bit address. Bad news - the patch does not work. Or rather it introduces a compile time warning message for some build environments and since we are now compiling with -Werror specified this stops the build. The good news however is that I have a simpler patch which I think should do the right thing (tm). Please could you try it and let me know if it works for you ? Cheers Nick bfd/ChangeLog 2005-04-04 Nick Clifton <nickc@redhat.com> * coffgen.c (coff_print_symbol): Use fprintf_vma to print a vma. [-- Attachment #2: coffgen.c.patch --] [-- Type: text/plain, Size: 2169 bytes --] Index: bfd/coffgen.c =================================================================== RCS file: /cvs/src/src/bfd/coffgen.c,v retrieving revision 1.49 diff -c -3 -p -r1.49 coffgen.c *** bfd/coffgen.c 22 Mar 2005 16:14:41 -0000 1.49 --- bfd/coffgen.c 4 Apr 2005 16:15:59 -0000 *************** coff_print_symbol (bfd *abfd, *** 1895,1922 **** else val = combined->u.syment.n_value - (unsigned long) root; ! #ifndef XCOFF64 ! fprintf (file, ! "(sec %2d)(fl 0x%02x)(ty %3x)(scl %3d) (nx %d) 0x%08lx %s", combined->u.syment.n_scnum, combined->u.syment.n_flags, combined->u.syment.n_type, combined->u.syment.n_sclass, ! combined->u.syment.n_numaux, ! (unsigned long) val, ! symbol->name); ! #else ! /* Print out the wide, 64 bit, symbol value. */ ! fprintf (file, ! "(sec %2d)(fl 0x%02x)(ty %3x)(scl %3d) (nx %d) 0x%016llx %s", ! combined->u.syment.n_scnum, ! combined->u.syment.n_flags, ! combined->u.syment.n_type, ! combined->u.syment.n_sclass, ! combined->u.syment.n_numaux, ! val, ! symbol->name); ! #endif for (aux = 0; aux < combined->u.syment.n_numaux; aux++) { --- 1895,1908 ---- else val = combined->u.syment.n_value - (unsigned long) root; ! fprintf (file, "(sec %2d)(fl 0x%02x)(ty %3x)(scl %3d) (nx %d)", combined->u.syment.n_scnum, combined->u.syment.n_flags, combined->u.syment.n_type, combined->u.syment.n_sclass, ! combined->u.syment.n_numaux); ! fprintf_vma (file, val); ! fprintf (file, " %s", symbol->name); for (aux = 0; aux < combined->u.syment.n_numaux; aux++) { *************** coff_print_symbol (bfd *abfd, *** 1995,2004 **** l++; while (l->line_number) { ! fprintf (file, "\n%4d : 0x%lx", ! l->line_number, ! ((unsigned long) ! (l->u.offset + symbol->section->vma))); l++; } } --- 1981,1988 ---- l++; while (l->line_number) { ! fprintf (file, "\n%4d : ", l->line_number); ! fprintf_vma (file, l->u.offset + symbol->section->vma); l++; } } ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: XCOFF 64 function address wrong? 2005-04-04 16:19 ` Nick Clifton @ 2005-04-15 11:49 ` Nick Clifton 2005-05-16 17:07 ` David Lecomber 1 sibling, 0 replies; 13+ messages in thread From: Nick Clifton @ 2005-04-15 11:49 UTC (permalink / raw) To: binutils Hi Guys, I have not heard back from David about this problem, but I consider the patch to be reasonably obvious, so I am going to apply it anyway. Cheers Nick > bfd/ChangeLog > 2005-04-04 Nick Clifton <nickc@redhat.com> > > * coffgen.c (coff_print_symbol): Use fprintf_vma to print vma values. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: XCOFF 64 function address wrong? 2005-04-04 16:19 ` Nick Clifton 2005-04-15 11:49 ` Nick Clifton @ 2005-05-16 17:07 ` David Lecomber 2005-05-17 13:04 ` Nick Clifton 1 sibling, 1 reply; 13+ messages in thread From: David Lecomber @ 2005-05-16 17:07 UTC (permalink / raw) To: Nick Clifton; +Cc: binutils Hi Nick, Finally got the chance to check this one, and I can confirm that this works and has resolved the failure to print 64-bit addresses on AIX 5.2 Thanks again for the patch, Regards David On Mon, 2005-04-04 at 17:16 +0100, Nick Clifton wrote: > Hi David, > > > This revised fix does indeed resolve the problems: output is now as the > > full 64-bit address. > > Bad news - the patch does not work. Or rather it introduces a compile > time warning message for some build environments and since we are now > compiling with -Werror specified this stops the build. > > The good news however is that I have a simpler patch which I think > should do the right thing (tm). > > Please could you try it and let me know if it works for you ? > > Cheers > Nick > > bfd/ChangeLog > 2005-04-04 Nick Clifton <nickc@redhat.com> > > * coffgen.c (coff_print_symbol): Use fprintf_vma to print a vma. > > plain text document attachment (coffgen.c.patch) > Index: bfd/coffgen.c > =================================================================== > RCS file: /cvs/src/src/bfd/coffgen.c,v > retrieving revision 1.49 > diff -c -3 -p -r1.49 coffgen.c > *** bfd/coffgen.c 22 Mar 2005 16:14:41 -0000 1.49 > --- bfd/coffgen.c 4 Apr 2005 16:15:59 -0000 > *************** coff_print_symbol (bfd *abfd, > *** 1895,1922 **** > else > val = combined->u.syment.n_value - (unsigned long) root; > > ! #ifndef XCOFF64 > ! fprintf (file, > ! "(sec %2d)(fl 0x%02x)(ty %3x)(scl %3d) (nx %d) 0x%08lx %s", > combined->u.syment.n_scnum, > combined->u.syment.n_flags, > combined->u.syment.n_type, > combined->u.syment.n_sclass, > ! combined->u.syment.n_numaux, > ! (unsigned long) val, > ! symbol->name); > ! #else > ! /* Print out the wide, 64 bit, symbol value. */ > ! fprintf (file, > ! "(sec %2d)(fl 0x%02x)(ty %3x)(scl %3d) (nx %d) 0x%016llx %s", > ! combined->u.syment.n_scnum, > ! combined->u.syment.n_flags, > ! combined->u.syment.n_type, > ! combined->u.syment.n_sclass, > ! combined->u.syment.n_numaux, > ! val, > ! symbol->name); > ! #endif > > for (aux = 0; aux < combined->u.syment.n_numaux; aux++) > { > --- 1895,1908 ---- > else > val = combined->u.syment.n_value - (unsigned long) root; > > ! fprintf (file, "(sec %2d)(fl 0x%02x)(ty %3x)(scl %3d) (nx %d)", > combined->u.syment.n_scnum, > combined->u.syment.n_flags, > combined->u.syment.n_type, > combined->u.syment.n_sclass, > ! combined->u.syment.n_numaux); > ! fprintf_vma (file, val); > ! fprintf (file, " %s", symbol->name); > > for (aux = 0; aux < combined->u.syment.n_numaux; aux++) > { > *************** coff_print_symbol (bfd *abfd, > *** 1995,2004 **** > l++; > while (l->line_number) > { > ! fprintf (file, "\n%4d : 0x%lx", > ! l->line_number, > ! ((unsigned long) > ! (l->u.offset + symbol->section->vma))); > l++; > } > } > --- 1981,1988 ---- > l++; > while (l->line_number) > { > ! fprintf (file, "\n%4d : ", l->line_number); > ! fprintf_vma (file, l->u.offset + symbol->section->vma); > l++; > } > } -- David Lecomber, Software Director, http://www.allinea.com Allinea Software +44 1926 623231 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: XCOFF 64 function address wrong? 2005-05-16 17:07 ` David Lecomber @ 2005-05-17 13:04 ` Nick Clifton 0 siblings, 0 replies; 13+ messages in thread From: Nick Clifton @ 2005-05-17 13:04 UTC (permalink / raw) To: David Lecomber; +Cc: binutils Hi David, > Finally got the chance to check this one, and I can confirm that this > works and has resolved the failure to print 64-bit addresses on AIX 5.2 Good oh - I have checked the patch into the sources. Cheers Nick ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2005-05-17 12:55 UTC | newest] Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2005-03-09 8:14 XCOFF 64 function address wrong? David Lecomber 2005-03-09 12:53 ` Nick Clifton 2005-03-09 14:54 ` David Lecomber 2005-03-09 15:39 ` Nick Clifton 2005-03-09 17:52 ` David Lecomber 2005-03-10 10:22 ` Nick Clifton 2005-03-10 21:56 ` David Lecomber 2005-03-11 10:37 ` Nick Clifton 2005-03-24 2:03 ` David Lecomber 2005-04-04 16:19 ` Nick Clifton 2005-04-15 11:49 ` Nick Clifton 2005-05-16 17:07 ` David Lecomber 2005-05-17 13:04 ` Nick Clifton
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).