Re: Another Issue for 5.0

Re: Another Issue for 5.0

[David Taylor]

    Date: Thu, 17 Feb 2000 08:26:39 -0800 (PST)
    From: Daniel Berlin <dan@cgsoftware.com>

    IMHO, the overload resolution for DWARF2/STABS/all non-hp platforms should
    really be fixed for 5.0.
    I have patches to do this (in fact, i'm about to send another jumbo patch
    to gdb-patches with it all combined so i don't have to keep emailing it to
    people :P), with no regressions, well, actually, that's not true.
    Some overload resolution things that were xfail before in the testsuite
    now pass.
    Sorry about that. I'll try to make sure i keep the broken things broken in
    the future. :P

    But, anyway, i get about 5-10 emails a week asking for those patches.
    Even on HP using aCC, where overload resolution works, you get benefits
    because i added support for references in overloads, and fixed a problem
    where the compares against function names were whitespace sensitive where
    they shouldn't have been (so operator [] would be considered the same
    function as operator[] when we were hunting down overloads).

    Maybe i'm biased, but anyone working on C++ programs would love it.

    I'm starting to work on other C++ language support related things, if
    anyone has any specific requests, let me know.

    --Dan

Is there a copyright assignment on file?

I'd love to look over the patch.
From jimb@zwingli.cygnus.com Sat Apr 01 00:00:00 2000
From: Jim Blandy <jimb@zwingli.cygnus.com>
To: Todd Whitesel <toddpw@windriver.com>
Cc: gdb@sourceware.cygnus.com (GDB Developers)
Subject: Re: symfile.c:symfile_bfd_open()
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <npya7752wo.fsf@zwingli.cygnus.com>
References: <200003241351.FAA06850@alabama.wrs.com>
X-SW-Source: 2000-q1/msg00804.html
Content-length: 1075

> While merging up to 4.18 (as a stepping stone to devo), I noticed
> something that we're doing locally here which seems generally useful
> for cross developing folks.
> 
> symfile.c:symfile_bfd_open() opens objects/executables using BFD.
> 
> It tells openp() to search the $PATH, which is obviously handy for
> native, but seems to make no sense whatsoever for cross development.

Yep.

> Our local patch is to add a second argument to symfile_bfd_open,
> "use_source_path", which ends up being set to 1 nearly all of the
> time, since with our targets we are always cross developing. In
> that case, we have openp() search source_path instead of getenv("PATH").

How do you decide what to pass for the use_source_path argument?  Is
it a user-settable option?

> Does the multi-arch stuff provide a clean test for native vs. cross?
> That'd be a better decision-maker than the "use_source_path" argument.

I don't think you can tell at all.  What if I'm debugging an i386
embedded system on Linux?  Then, whether I'm native or remote is a
matter of which target I select.
From hjl@lucon.org Sat Apr 01 00:00:00 2000
From: "H . J . Lu" <hjl@lucon.org>
To: Chris Blizzard <blizzard@redhat.com>
Cc: Christopher Blizzard <blizzard@mozilla.org>, tromey@cygnus.com, gdb@sourceware.cygnus.com
Subject: Re: problems with gdb
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <20000218101700.A19913@lucon.org>
References: <38A47E89.3F4674B3@mozilla.org> <npael3tqk6.fsf@zwingli.cygnus.com> <38AB2DC4.FA9A3C71@redhat.com> <87zot0y99f.fsf@cygnus.com> <38AC0B97.19AE4BAE@mozilla.org> <38AD8469.27616453@redhat.com>
X-SW-Source: 2000-q1/msg00338.html
Content-length: 415

On Fri, Feb 18, 2000 at 12:42:01PM -0500, Chris Blizzard wrote:
> Christopher Blizzard wrote:
> > 
> > Program received signal SIGTRAP, Trace/breakpoint trap.
> > 0x404cbd41 in ?? () from /lib/libc.so.6
> > (gdb) shar libc.so.6
> > Reading symbols from /lib/libc.so.6...done.
> > 

There are many linuxthreads problems since lin-thread.c was
introduced. Unfortunately, I don't have the time to track it
down.

H.J.
From rearnsha@arm.com Sat Apr 01 00:00:00 2000
From: Richard Earnshaw <rearnsha@arm.com>
To: "Xavier Bestel" <xbestel@aplio.fr>
Cc: rearnsha@arm.com
Subject: Re: single-step 
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200002281725.RAA24931@cam-mail2.cambridge.arm.com>
References: <045d01bf820f$922ce7c0$30fd62c2@aplio.fr>
X-SW-Source: 2000-q1/msg00440.html
Content-length: 684

> ok, so if I understood the system, when SOFTWARE_SINGLE_STEP_P=1,
> SOFTWARE_SINGLE_STEP is the function which emulates the singlestepping using
> breakpoints.
> but if I don't define SOFTWARE_SINGLE_STEP_P, or if I define it to 1, then
> do I have to provide a specialized SOFTWARE_SINGLE_STEP_P() ? There is no
> such thing in tm-arm.h.

Arggh!  Sorry, I've mislead you.  I've got some local patches in my tree 
for doing that and I'd forgotten that I hadn't submitted them yet.  I'm 
sure this code used to be there, but for some reason it has been deleted.

It appears that at this time, you can't single step if there is no 
hardware or OS support for the feature.

Richard.

Re: Another Issue for 5.0

[Chris Faylor]

In article < 200002181809.NAA06156@texas.cygnus.com >,
David Taylor  <taylor@cygnus.com> wrote:
>    Date: Thu, 17 Feb 2000 08:26:39 -0800 (PST)
>    From: Daniel Berlin <dan@cgsoftware.com>
>
>    IMHO, the overload resolution for DWARF2/STABS/all non-hp platforms should
>    really be fixed for 5.0.
>    I have patches to do this (in fact, i'm about to send another jumbo patch
>    to gdb-patches with it all combined so i don't have to keep emailing it to
>    people :P), with no regressions, well, actually, that's not true.
>    Some overload resolution things that were xfail before in the testsuite
>    now pass.
>    Sorry about that. I'll try to make sure i keep the broken things broken in
>    the future. :P
>
>    But, anyway, i get about 5-10 emails a week asking for those patches.
>    Even on HP using aCC, where overload resolution works, you get benefits
>    because i added support for references in overloads, and fixed a problem
>    where the compares against function names were whitespace sensitive where
>    they shouldn't have been (so operator [] would be considered the same
>    function as operator[] when we were hunting down overloads).
>
>    Maybe i'm biased, but anyone working on C++ programs would love it.
>
>    I'm starting to work on other C++ language support related things, if
>    anyone has any specific requests, let me know.
>
>Is there a copyright assignment on file?
>
>I'd love to look over the patch.

Nick Duffek has already looked over the patch and verified that it works exactly
as Dan has suggested.  He should be able to apply the patch as soon as the
assignment clears.

I think that this falls into Jim Blandy's maintainership area so it will be up
to him to say yea or nay, though.

cgf
-- 
cgf@cygnus.com                        Cygnus Solutions, a Red Hat company
http://sourcware.cygnus.com/          http://www.redhat.com/
From rearnsha@arm.com Sat Apr 01 00:00:00 2000
From: Richard Earnshaw <rearnsha@arm.com>
To: Scott Bambrough <scottb@netwinder.org>
Cc: rearnsha@arm.com
Subject: Re: Breakpoint problem when running on gdb-4.18 arm/thumb simulator target
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200001131530.PAA27948@cam-mail2.cambridge.arm.com>
References: <387DE3A6.A2BCAB58@netwinder.org>
X-SW-Source: 2000-q1/msg00029.html
Content-length: 222

> 
> ARM CPU's currently have no hardware support for breakpoints that I know of.

ARM cores with 'I' in the product name (eg ARM7TDMI, ARM9TDMI) have 
hardware breakpoints.  These are part of the ICE hardware.

Richard