Revisit gdb/12528 for bare metal targets

[Yao Qi <yao at codesourcery dot com>]

I see the following fail on arm-none-eabi target,

(gdb) b 24^M
Breakpoint 1 at 0x4: file
../../../../git/gdb/testsuite/gdb.base/break-on-linker-gcd-function.cc,
line 24.^M
(gdb) FAIL: gdb.base/break-on-linker-gcd-function.exp: b 24

This test case is for PR gdb/12528, but I don't think this PR is fixed
for bare metal targets.

Paul asked for the advice for this PR
<https://sourceware.org/ml/gdb-patches/2011-03/msg00662.html> about how
to determine whether an address zero in debug info means the
corresponding code has been GC'ed.
Then, flag has_section_at_zero was chosen and the code is like:

	case DW_LNE_set_address:
	  address = read_address (abfd, line_ptr, cu, &bytes_read);

	  if (address == 0 && !dwarf2_per_objfile->has_section_at_zero)
	    {
	      /* This line table is for a function which has been
		 GCd by the linker.  Ignore it.  PR gdb/12528 */

On some bare metal targets, .text section is located at 0x0 so
has_section_at_zero is true.  That is why this test fails.  I am
looking for something else to check, for example, if ADDRESS is zero
and address zero isn't within any SEC_LOAD sections of CU
("break-on-linker-gcd-function.cc"), then the function should be GC'ed
by the linker.  I am not familiar with the stuff about CU and symbols,
so I'd like your advice on it.  TIA.

-- 
Yao (éå)