lkml.org 
[lkml]   [2004]   [Feb]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: kgdb: rename i386-stub.c to kgdb.c
    Tom Rini wrote:
    > On Wed, Feb 25, 2004 at 01:17:15PM -0800, George Anzinger wrote:
    >
    >>Pavel Machek wrote:
    >>
    >>>Hi!
    >>>
    >>>
    >>>
    >>>>>kgdb uses really confusing names for arch-dependend parts. This fixes
    >>>>>it. Okay to commit?
    >>>>
    >>>>Why is arch/$x/kernel/$x-stub.c confusing? The name $x-stub.c is
    >>>>indicative of architecture dependent code in it. Err, well so is the path.
    >>>
    >>>
    >>>
    >>>Well, looking at i386-stub.c, how do you know it is kgdb-related?
    >>>
    >>>
    >>>
    >>>>PPC and sparc stubs in present vanilla kernel use this naming convention.
    >>>>That's why I adopted it.
    >>>>
    >>>>I find kernel/kgdbstub.c, arch/$x/kernel/$x-stub.c more consistent
    >>>>compared to kernel/kgdbstub.c, arch/$x/kernel/kgdb.c
    >>>
    >>>
    >>>I actually made it kernel/kgdb.c and arch/*/kernel/kgdb.c. I believe
    >>>there's no point where one could be confused....
    >>
    >>gdb itself gets confused with this. Try, for example, time.c which, on the
    >>x86, is in both arch and common code. I use emacs with kgdb and it gets
    >>confused when I point at a location in the source and tell it to set a
    >>break point.
    >>
    >>Please, lets have only one of each name.
    >
    >
    > We can't. We've had various things (most notably MODVERSIONS prior to
    > 2.6) which are unhappy with that, and in the end, the problem ends up
    > being fixed elsewhere. In fact, this should be able to as well. Using
    > your time.c example:
    > (gdb) break arch/i386/kernel/time.c:set_rtc_mmss
    > Breakpoint 3 at 0xc010ee90: file arch/i386/kernel/time.c, line 174.
    > (gdb) break kernel/time.c:sys_time
    > Breakpoint 4 at 0xc011f0cc: file time.h, line 301.
    >
    > So shouldn't it be a matter of somehow just not having a time.c
    > reference as well in the debug data?

    No it is related to the point and grunt option in emacs:

    I would guess it is a problem in the emacs interface where one points at a
    location in the code window and enters a command to set a break point ( I think
    it is "^x " (control X space)). It would appear that emacs then only sends the
    file name to gdb rather than the full path.

    This is not a show stopping problem, only confusing. Once gdb figures out the
    right source, all is well. I usually do it by setting a break point at the
    function by name, thus avoiding the point and grunt thing.
    >

    --
    George Anzinger george@mvista.com
    High-res-timers: http://sourceforge.net/projects/high-res-timers/
    Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 14:01    [W:0.029 / U:1.236 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site