This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


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

long file name problem with non-PE BFD COFF targets



Hi,

I am tracking down a problem in the c4x port of binutils
and gdb but it appears that it may be a generic problem
in any COFF target that is using the "BFD assembler" mode
and is not PE.  Nick Clifton duplicated the 1st problem
on arm-coff.

[As an aside, there do not appear to be many binutils targets
that are COFF, use BFD GAS, and are not PE so it is quite
possible that this code is not used much.

The symptom is that the assembler is putting the VERY long
filename in the .o but gdb must not be 100% happy with the
settings because it is only finding a partial path.


His comment:

> My guess is that GDB does not use any BFD routines to read the
> filename, but rather does it itself.  I would suggest putting a
> breakpoint on the function coff_getfilename() in gdb/coffread.c and
> tracing things from there.

The code in gdb that I think needs to trip is:

  if (aux_entry->x_file.x_n.x_zeroes == 0)
    strcpy (buffer, stringtab + aux_entry->x_file.x_n.x_offset);
  else
    {
      strncpy (buffer, aux_entry->x_file.x_fname, FILNMLEN);
      buffer[FILNMLEN] = '\0';
    }

The code is taking the "else" when it should take the "if".
aux_entry->x_file.x_n.x_zeroes = 0x2e2e2f which is (I think)
not right.  aux_entry->x_file.x_n.x_offset = 0 which (I think)
does not point us to the right place in the string table either.
Right before we return from coff_getfilename(), I did the 
following:

(gdb) x/s stringtab
0x81e74f0:	 "Ä"
(gdb) 
0x81e74f2:	 ""
(gdb) 
0x81e74f3:	 ""
(gdb) 
0x81e74f4:	 "gcc2_compiled."
(gdb) 
0x81e7503:	 "_rtems_provides_crt0"
(gdb) 
0x81e7518:	 "/usr1/rtems/work/rtems/c/src/tests/samples/hello/init.c"

It would seem to me that if  aux_entry->x_file.x_n.x_zeroes 
were == 0, then gdb would run the "if" part.  Then "stringtab" 
and aux_entry->x_file.x_n.x_offset would have to point to the
string at 0x81e7518.  

This all results in coff_getfilename() returning the following result
based on buffer.

(gdb) p result
$17 = 0x81bbfac ".."
(gdb) p buffer
$18 = "../../../../..", '\000' <repeats 8177 times>

I think I have a possible culprit.  There is a lot of "C_FILE" 
code in the !BFD_ASSEMBLER path of obj-coff.c and little in 
the BFD_ASSEMBLER path.  Does anyone see any code that is 
missing?  I do not see any logic in the BFD_ASSEMBLER case
is that is equivalent to that around line 3191.

Is this enough information for someone to make a suggestion
as to what is wrong?

Thanks.

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel@OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (256) 722-9985

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