From mboxrd@z Thu Jan  1 00:00:00 1970
From: der.herr@hofr.at (Nicholas Mc Guire)
Date: Thu, 3 Dec 2015 18:43:48 +0000
Subject: How to correctly decode fun+X/Y
In-Reply-To: <n3q0qe$gdc$1@ger.gmane.org>
References: <n3q0qe$gdc$1@ger.gmane.org>
Message-ID: <20151203184348.GA28666@osadl.at>
To: kernelnewbies@lists.kernelnewbies.org
List-Id: kernelnewbies.lists.kernelnewbies.org

On Thu, Dec 03, 2015 at 09:14:38PM +0300, Matwey V. Kornilov wrote:
> Hello,
> 
> I have the following stack trace:
> 
> [ 1351.381696] a.out           S c0afb050     0  1676   1658 0x00000000
> [ 1351.387048] [<c0afb050>] (__schedule) from [<c0afb4d0>]
> (schedule+0x58/0xcc)
> [ 1351.392436] [<c0afb4d0>] (schedule) from [<c069369c>]
> (tty_port_block_til_ready+0x1a8/0x35c)
> [ 1351.396937] [<c069369c>] (tty_port_block_til_ready) from [<c06ab220>]
> (uart_open+0x118/0x158)
> [ 1351.402560] [<c06ab220>] (uart_open) from [<c068b768>]
> (tty_open+0x11c/0x600)
> [ 1351.407043] [<c068b768>] (tty_open) from [<c03e1ce4>]
> (chrdev_open+0xb4/0x188)
> [ 1351.412556] [<c03e1ce4>] (chrdev_open) from [<c03db3dc>]
> (do_dentry_open+0x230/0x330)
> [ 1351.417038] [<c03db3dc>] (do_dentry_open) from [<c03dc64c>]
> (vfs_open+0x64/0x6c)
> [ 1351.422470] [<c03dc64c>] (vfs_open) from [<c03eaf5c>]
> (do_last+0x510/0xd94)
> [ 1351.426909] [<c03eaf5c>] (do_last) from [<c03eb86c>]
> (path_openat+0x8c/0x270)
> [ 1351.432398] [<c03eb86c>] (path_openat) from [<c03ecd78>]
> (do_filp_open+0x70/0xd4)
> [ 1351.436815] [<c03ecd78>] (do_filp_open) from [<c03dc9cc>]
> (do_sys_open+0x120/0x1e4)
> [ 1351.442117] [<c03dc9cc>] (do_sys_open) from [<c03dcab8>]
> (SyS_open+0x28/0x30)
> [ 1351.447046] [<c03dcab8>] (SyS_open) from [<c021cd40>]
> (ret_fast_syscall+0x0/0x34)
> 
> 
> Could please explain, how to correctly decode
> tty_port_block_til_ready+0x1a8/0x35c to the instruction or line of code
> using gdb?
> 
> I have kernel image and separate debug info.
>
The numbers after the symbol name are offset/length
so in your case the offset from tty_port_block_til_ready was 
0x1a8 and the length of the function tty_port_block_til_ready
0x35c.

if you have the appropriate kernel sources also it
probably would be easier if you generate the .lst file
that contains tty_port_block_til_ready =>  drivers/tty/tty_port.c 
so   make drivers/tty/tty_port.lst   would give you
the annotated c file with the assebler code interleaved 
and then you can inspect the relevant assembler in the
c-code context.

thx!
hofrat