[#5825] gdb: symbols cannot map to correct source file

Document created by Aaronwu Employee on Oct 17, 2013
Version 1Show Document
  • View in full screen mode

[#5825] gdb: symbols cannot map to correct source file

Submitted By: Yi Li

Open Date

2010-01-12 08:12:57     Close Date

2010-04-20 07:51:41

Priority:

Medium     Assignee:

Jie Zhang

Board:

N/A     Silicon Revision:

0.2

Resolution:

Rejected     Fixed In Release:

N/A

Processor:

BF537     

Host Operating System:

toolchain rev.:

2009r1.1-rc2 gcc 4.1     kernel rev.:

State:

Closed     Found In Release:

2009R1.1_RC2

Is this bug repeatable?:

yes     

Summary: gdb: symbols cannot map to correct source file

Details:

 

Tested on BF537-STAMP.

linux-kernel: svn trunk r8145

gcc: bfin-uclinux-gcc 4.1 2009r1.1-2

Detail configuration please see attached bugreport.tgz.

 

Debug kernel using bfin-elf-gdb, set breakpoint to function "bfin_cs_cycles_init()" (this function is defined in arch/blackfin/kernel/time-ts.c). However, gdb says the break point is set to "include/linux/clocksource.h, line 253."

 

bfin-elf-gdb vmlinux

GNU gdb 6.6

Copyright (C) 2006 Free Software Foundation, Inc.

GDB is free software, covered by the GNU General Public License, and you are

welcome to change it and/or distribute copies of it under certain conditions.

Type "show copying" to see the conditions.

There is absolutely no warranty for GDB.  Type "show warranty" for details.

This GDB was configured as "--host=i686-pc-linux-gnu --target=bfin-elf"...

(gdb) b bfin_cs_cycles_init

Breakpoint 1 at 0x195a4c: file include/linux/clocksource.h, line 253.

(gdb)

 

 

objdump:

00195a48 <_bfin_cs_cycles_init>:

  195a48:       ed 05           [--SP] = (R7:5, P5:5);

  195a4a:       67 01           [--SP] = RETS;

  195a4c:       4d e1 18 00     P5.H = 0x18;            /* ( 24)        P5=0x1821f8 <_dma_io_base_addr> */

  195a50:       66 6f           SP += -0x14;            /* (-20) */

  195a52:       0d e1 dc 18     P5.L = 0x18dc;          /* (6364)       P5=0x1818dc <_bfin_cs_cycles> */

  195a56:       f3 e3 eb 62     CALL 0x202c <_get_cclk>;

  195a5a:       47 e1 9a 3b     R7.H = 0x3b9a;          /* (15258)      R7=0x3b9a5700(999970560) */

  195a5e:       ab a2           R3 = [P5 + 0x28];

  195a60:       07 e1 00 ca     R7.L = 0xca00;          /* (-13824)     R7=0x3b9aca00(1000000000) */

  195a64:       28 30           R5 = R0;

  195a66:       0b 30           R1 = R3;

  195a68:       42 e1 cd 1d     R2.H = 0x1dcd;          /* (7629)       R2=0x1dcd0002(499974146) */

  195a6c:       f8 60           R0 = 0x1f (X);          /*              R0=0x1f( 31) */

  195a6e:       01 67           R1 += -0x20;            /* (-32) */

  195a70:       37 30           R6 = R7;

  195a72:       18 52           R0 = R0 - R3;

  195a74:       02 e1 00 65     R2.L = 0x6500;          /* (25856)      R2=0x1dcd6500(500000000) */

 

However, if I set breakpoint to address "0x195a50", it would be OK.

 

(gdb) b *0x195a50

Breakpoint 2 at 0x195a50: file arch/blackfin/kernel/time-ts.c, line 72.

 

(gdb) l *0x195a50

0x195a50 is in bfin_cs_cycles_init (arch/blackfin/kernel/time-ts.c:72).

67        return clocksource_cyc2ns(bfin_read_cycles(&bfin_cs_cycles),

68            bfin_cs_cycles.mult, bfin_cs_cycles.shift);

69    }

70   

71    static int __init bfin_cs_cycles_init(void)

72    {

73        bfin_cs_cycles.mult = \

74            clocksource_hz2mult(get_cclk(), bfin_cs_cycles.shift);

75   

76        if (clocksource_register(&bfin_cs_cycles))

(gdb) l *0x195a4c

0x195a4c is in bfin_cs_cycles_init (include/linux/clocksource.h:253).

248         *  mult = 1000000000 * 2^shift / hz

249         *  mult = (1000000000<<shift) / hz

250         */

251        u64 tmp = ((u64)1000000000) << shift_constant;

252   

253        tmp += hz/2; /* round for do_div */

254        do_div(tmp, hz);

255   

256        return (u32)tmp;

257    }

(gdb)

 

 

Do you think GDB is behaving normally?

 

 

 

Follow-ups

 

--- Yi Li                                                    2010-01-12 08:25:20

I think the situation happens because the first line of bfin_cs_cycles_init() is

an inline function:

 

static inline u32 clocksource_hz2mult(u32 hz, u32 shift_constant)

{

        /*  hz = cyc/(Billion ns)

         *  mult/2^shift  = ns/cyc

         *  mult = ns/cyc * 2^shift

         *  mult = 1Billion/hz * 2^shift

         *  mult = 1000000000 * 2^shift / hz

         *  mult = (1000000000<<shift) / hz

         */

        u64 tmp = ((u64)1000000000) << shift_constant;

 

        tmp += hz/2; /* round for do_div */

        do_div(tmp, hz);

 

        return (u32)tmp;

}

 

But this is not what expected for breakpoints.

 

--- Yi Li                                                    2010-01-12 08:58:39

This issue can also happen when the first line of a function is a

"#define" micro. e.g:

 

(gdb) b trace_hardirqs_on

Breakpoint 5 at 0x47156: file include/trace/events/hist.h, line 13.

 

kernel/trace/trace_irqsoff.c:

void trace_hardirqs_on(void)

{

    trace_preemptirqsoff_hist(IRQS_ON, 0);

    if (!preempt_trace() && irq_trace())

        stop_critical_timing(CALLER_ADDR0, CALLER_ADDR1);

}

EXPORT_SYMBOL(trace_hardirqs_on);

 

include/trace/events/hist.h:

#if !defined(CONFIG_PREEMPT_OFF_HIST) &&

!defined(CONFIG_INTERRUPT_OFF_HIST)

#define trace_preemptirqsoff_hist(a,b)

#else

TRACE_EVENT(preemptirqsoff_hist,

...

#endif

 

--- Jie Zhang                                                2010-01-12 22:49:16

Both are expected.

 

--- Robin Getz                                               2010-04-20 07:49:57

Since this is expected behaviour - marking closed

 

 

 

    Files

    Changes

    Commits

    Dependencies

    Duplicates

    Associations

    Tags

 

File Name     File Type     File Size     Posted By

No Files Were Found

Attachments

    Outcomes