My employer assigned a few engineers to GNU toolchains so that we make some contribution to the projects. I am one of the engineers, and would like to start with this bug. As it does not seem that I can assign this bug to myself, I am leaving this comment here. I would like to take a look at this bug, and will see if this is in my area or not. If it is, I will do my best to fix this bug.

(In reply to Stephen Kim from comment #1)
> My employer assigned a few engineers to GNU toolchains so that we make some
> contribution to the projects. I am one of the engineers, and would like to
> start with this bug. As it does not seem that I can assign this bug to
> myself, I am leaving this comment here. I would like to take a look at this
> bug, and will see if this is in my area or not. If it is, I will do my best
> to fix this bug.

Hi Stephen,

First of all thank you for proposing your help here, that's much appreciated. You'll find more info on how to contribute at [1]. As to assigning bugzilla ticket, I believe this is only possible once you get commit approval, at least that's how it work in GCC bugzilla.

[1] https://sourceware.org/gdb/contribute/

Best regards.

Stephen, I've given editbugs privileges to your account and to the accounts of a a couple of your colleagues that I recognized as contributing upstream recently.  Welcome on board!

Another URL to look at is:
  https://sourceware.org/gdb/wiki/ContributionChecklist

Hi, all, 

I could not reproduce this bug. Here are my configurations:

I have an Ubuntu box:
 $ lsb_release -a
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 16.10
Release:	16.10
Codename:	yakkety

It comes up with a binary package for the cross compiler:
$ arm-none-eabi-gcc --version
arm-none-eabi-gcc (15:4.9.3+svn231177-1) 4.9.3 20150529 (prerelease)
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

I think I configured my GDB with the options in this bug report, and the version is:
 $ ./gdb --version
GNU gdb (GDB) 8.0.50.20170908-git

The test case was from:
https://bugs.launchpad.net/gcc-arm-embedded/+bug/1700646

There was a batch file as far as I remember it. I made a bash script from it as follows:
$ cat ./build.sh 
#!/bin/bash
arm-none-eabi-gcc -O0 -fno-common -fpie -ffunction-sections -fdata-sections -Wall -mcpu=cortex-m0 -mthumb -mfloat-abi=soft -g3 -T"linker_script.ld" -Wl,-Map,gdb_test.map,--gc-sections,-emain -nostdlib main.c -o gdb_test2.elf
arm-none-eabi-objcopy --output-target binary gdb_test2.elf gdb_test2.bin

Then, I did what is described in this bug report:
$ ./gdb
GNU gdb (GDB) 8.0.50.20170908-git
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=x86_64-linux-gnu --target=arm-none-eabi".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word".
(gdb) add-symbol-file ./gdb_test2.elf 0x1fff0000
add symbol table from file "./gdb_test2.elf" at
	.text_addr = 0x1fff0000

The bug was not reproducible. Would you check if the bug is gone in the 8..50-20170908 GDB? Otherwise, I guess the difference would be the compiler we used.

(y or n) y
Reading symbols from ./gdb_test2.elf...done.
(gdb) br main
Breakpoint 1 at 0x1fff0000

I cannot modify my comments. The add-symbol-file command asked a "yes or no" question above. I answered "y" to it, and was able to set a break point with the address of main, I believe.

I am able to reproduce this bug on GDB trunk: commit 984c723.

Initial investigation suggests problem is visible only when we dont use default linker script while compiling .text section that is loaded in gdb at an offset address.

GDB fails to process line information successfully even though it can properly calculate symbol address with offset included.

This requires further investigation.

Still could not reproduce this bug.

The master branch has been updated by Omair Javaid <omjavaid@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=7ab6656f274b450942deb8800257c0d2e060fa84

commit 7ab6656f274b450942deb8800257c0d2e060fa84
Author: Omair Javaid <omair.javaid@linaro.org>
Date:   Tue May 15 19:04:21 2018 +0500

    Fix lost line info for symbol at addr zero
    
    This patch fixes a unique condition where GDB fails to provide line
    information of symbol at address zero when code is compiled with text
    address zero but loaded at an offset > 0.
    
    For example lets compile following code snippet:
    
    int main() {
      return 0;
    }
    
    gcc -O0 -g3 -nostdlib -emain -Wl,-Ttext=0x00 -o file.out file.c
    
    Start gdb and run:
    
    add-symbol-file file.out 0xffff0000
    info line main
    
    GDB will return error saying no line info is available for the symbol.
    
    This is a direct consequence of the fix for PR 12528 where GDB tries to ignore
    line table for a function which has been garbage collected by the linker.
    
    As the garbage collected symbols are sent to address zero GDB assumes a symbol
    actually placed at address zero as garbage collected.
    
    This was fixed with an additional check address < lowpc. But when symbol is
    loaded at an offset lowpc becomes lowpc + offset while no offset is added to
    address rather final symbol address is calculated based on baseaddr and address
    added together. So in case where symbols are loaded at an offset the condition
    address < lowpc will always return true.
    
    This patch fixes this by comparing address against a non offset lowpc.
    
    This patch also adds a GDB test case to replicate this behavior.
    
    gdb:
    
    2018-06-27  Omair Javaid  <omair.javaid@linaro.org>
    
    	PR gdb/21695
    	* dwarf2read.c (lnp_state_machine::check_line_address): Update declaration.
    	(dwarf_decode_lines_1): Adjust.
    
    gdb/testsuite:
    
    2018-06-27  Omair Javaid  <omair.javaid@linaro.org>
    
    	PR gdb/21695
    	* gdb.base/infoline-reloc-main-from-zero.exp: New test.
    	* gdb.base/infoline-reloc-main-from-zero.c: New file.

(In reply to Sourceware Commits from comment #8)
> The master branch has been updated by Omair Javaid <omjavaid@sourceware.org>:
> 
> https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;
> h=7ab6656f274b450942deb8800257c0d2e060fa84
> 
> commit 7ab6656f274b450942deb8800257c0d2e060fa84
> Author: Omair Javaid <omair.javaid@linaro.org>
> Date:   Tue May 15 19:04:21 2018 +0500
> 
>     Fix lost line info for symbol at addr zero

Can this be closed?