gdb/bfd: avoid crash when architecture is forced to csky or riscv

gdb/bfd: avoid crash when architecture is forced to csky or riscv

I built GDB with `--enable-targets=all`, then started GDB passing it
an x86-64 executable, finally I ran 'maint selftest', and observed GDB
crash like this:

  BFD: BFD (GNU Binutils) 2.36.50.20210519 assertion fail ../../src/bfd/hash.c:438
  Aborted (core dumped)

The problem originates from two locations, for example in csky-dis.c
(csky_get_disassembler) where we do this:

  const char *sec_name = NULL;
  ...
  sec_name = get_elf_backend_data (abfd)->obj_attrs_section;
  if (bfd_get_section_by_name (abfd, sec_name) != NULL)
    ...

We end up in here because during the selftests GDB forces the
architecture to be csky, but the BFD being accessed is still of type
x86-64.  As a result obj_attrs_section returns NULL, which means we
end up passing NULL to bfd_get_section_by_name.  If we follow the
function calls from bfd_get_section_by_name we eventually end up in
bfd_hash_hash, which asserts that the string (i.e. the name) is not
NULL.

The same crash can be reproduced in GDB without using the selftests,
for example:

  (gdb) file x86_64.elf
  (gdb) start
  (gdb) set architecture csky
  (gdb) disassemble main
  Dump of assembler code for function main:
  BFD: BFD (GNU Binutils) 2.36.50.20210519 assertion fail ../../src/bfd/hash.c:438
  Aborted (core dumped)

The fix I propose here is to have bfd_get_section_by_name return NULL
if name is ever NULL.  For consistency I updated
bfd_get_section_by_name_if in the same way, even though I'm not
hitting any problems along that code path right now.

I looked through the source tree and removed two NULL checks in
bfd/dwarf2.c which are no longer needed, its possible that there are
additional NULL checks that could be removed, I just didn't find them.

bfd/ChangeLog:

	* section.c (bfd_get_section_by_name): Return NULL if name is
	NULL.
	(bfd_get_section_by_name_if): Likewise.
	* dwarf2.c (read_section): Remove unneeded NULL check.
	(find_debug_info): Likewise.