Re: pathmap or dir command on drugs

[Fernando Nasser <fnasser@cygnus.com>]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 7555 bytes --]

David Taylor wrote:
> 
> Actually, if there is an insert, then either it should be an insert
> before or that should be an option or you need to allow <index> to
> be 0 -- otherwise you cannot insert before the first element.
> 

I agree.  '0' meaning insert at the beginning looks like a standard list thing.

-- 
Fernando Nasser
Red Hat - Toronto                       E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9
From joel.sherrill@OARcorp.com Tue Nov 07 12:14:00 2000
From: Joel Sherrill <joel.sherrill@OARcorp.com>
To: binutils@sources.redhat.com, gdb@sources.redhat.com
Subject: long file name problem with non-PE BFD COFF targets
Date: Tue, 07 Nov 2000 12:14:00 -0000
Message-id: <3A085FC5.DCAEFAA2@OARcorp.com>
X-SW-Source: 2000-11/msg00037.html
Content-length: 2673

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
From jimb@zwingli.cygnus.com Tue Nov 07 14:28:00 2000
From: Jim Blandy <jimb@zwingli.cygnus.com>
To: Daniel Berlin <dberlin@redhat.com>
Cc: Kevin Buettner <kevinb@cygnus.com>, Jim Wilson <wilson@cygnus.com>, Elena Zannoni <ezannoni@redhat.com>, Pete Wyckoff <pw@osc.edu>, gdb@sources.redhat.com, linux-ia64@linuxia64.org
Subject: Re: [Linux-ia64] Re: gdb null ptr
Date: Tue, 07 Nov 2000 14:28:00 -0000
Message-id: <npofzr8lj2.fsf@zwingli.cygnus.com>
References: <200011032142.NAA27103@wilson.cygnus.com> <1001103230254.ZM14396@ocotillo.lan> <m3em0sqv74.fsf@dan2.cygnus.com>
X-SW-Source: 2000-11/msg00038.html
Content-length: 602

I don't think limiting the caching to C++ programs solves the problem.

If I understand the situation, the SGI compiler attaches a DW_AT_name
attribute to array types.  We don't know whether this behavior occurs
only in C compilation units, or in C++ compilation units as well.

If the SGI compiler emits bogus names for array types in C++ code too,
then the same bug will reappear when debugging C++ code, even with
this patch applied.

I think the change to tag_type_to_type needs to be reverted
altogether.  I understand that it provides substantial savings in
storage, but it's simply not correct.
From jimb@zwingli.cygnus.com Tue Nov 07 14:38:00 2000
From: Jim Blandy <jimb@zwingli.cygnus.com>
To: Fernando Nasser <fnasser@cygnus.com>
Cc: David Taylor <taylor@cygnus.com>, gdb@sourceware.cygnus.com
Subject: Re: pathmap or dir command on drugs
Date: Tue, 07 Nov 2000 14:38:00 -0000
Message-id: <npn1fb8l1g.fsf@zwingli.cygnus.com>
References: <200011062125.QAA00561@texas.cygnus.com> <3A072726.BB42BEA3@cygnus.com>
X-SW-Source: 2000-11/msg00039.html
Content-length: 557

I agree with Fernando that the symmetry between pathmap entries and
breakpoints isn't compelling.  The command set should be designed to
fit the application.

It's worth taking care to keep the most common action --- adding a
pathmap --- terse.  Note that the commands for editing the source
directory list are `directory' and `show directories' --- it breaks
the `set/show' symmetry (there's a `show', but no `set' command), but
it's more convenient because it's less verbose.  I think it would be
fine for the commands to be `pathmap' and `show pathmap'.
From dberlin@redhat.com Tue Nov 07 15:38:00 2000
From: Daniel Berlin <dberlin@redhat.com>
To: Jim Blandy <jimb@cygnus.com>
Cc: Kevin Buettner <kevinb@cygnus.com>, Jim Wilson <wilson@cygnus.com>, Elena Zannoni <ezannoni@redhat.com>, Pete Wyckoff <pw@osc.edu>, gdb@sources.redhat.com, linux-ia64@linuxia64.org
Subject: Re: [Linux-ia64] Re: gdb null ptr
Date: Tue, 07 Nov 2000 15:38:00 -0000
Message-id: <m33dh3pd30.fsf@dan2.cygnus.com>
References: <200011032142.NAA27103@wilson.cygnus.com> <1001103230254.ZM14396@ocotillo.lan> <m3em0sqv74.fsf@dan2.cygnus.com> <npofzr8lj2.fsf@zwingli.cygnus.com>
X-SW-Source: 2000-11/msg00040.html
Content-length: 1151

Jim Blandy <jimb@cygnus.com> writes:

> I don't think limiting the caching to C++ programs solves the problem.
> 
> If I understand the situation, the SGI compiler attaches a DW_AT_name
> attribute to array types.  We don't know whether this behavior occurs
> only in C compilation units, or in C++ compilation units as well.
> 
> If the SGI compiler emits bogus names for array types in C++ code too,
> then the same bug will reappear when debugging C++ code, even with
> this patch applied.
> 
> I think the change to tag_type_to_type needs to be reverted
> altogether.  I understand that it provides substantial savings in
> storage, but it's simply not correct.

I'll revert it.

Okay, but we could still cache symbols and psymbols, that we have a
mangled name for, without any issues, in C++.

We could also cache most types in C++, using the mangled names of the
always existing operator or copy constructor that must be present in
the type, as the hash key.
This won't work for non-structs/classes, but we'll just not cache
them.

Anytime we have a mangled name we can use, we can cache using it,
since it's guaranteed to be unique.

--Dan