gdb/dwarf2/read.c:read_file_scope() lowpc adjustment

gdb/dwarf2/read.c:read_file_scope() lowpc adjustment

[Metzger, Markus T]

Hello Tom,

Git shows you as the last contributor to this code so I hope you may
be able to help.

While debugging some symbol lookup issue I stumbled over this...

  baseaddr = objfile->text_section_offset ();

  get_scope_pc_bounds (die, &lowpc, &highpc, cu);

  /* If we didn't find a lowpc, set it to highpc to avoid complaints
     from finish_block.  */
  if (lowpc == ((CORE_ADDR) -1))
    lowpc = highpc;
  lowpc = gdbarch_adjust_dwarf2_addr (gdbarch, lowpc + baseaddr);

  file_and_directory &fnd = find_file_and_directory (die, cu);

  cu->start_symtab (fnd.get_name (), fnd.intern_comp_dir (objfile), lowpc);

  gdb_assert (per_objfile->sym_cu == nullptr);
  scoped_restore restore_sym_cu
    = make_scoped_restore (&per_objfile->sym_cu, cu);

  /* Decode line number information if present.  We do this before
     processing child DIEs, so that the line header table is available
     for DW_AT_decl_file.  The PC check is here because, if LOWPC and
     HIGHPC are both 0x0, then there won't be any interesting code in
     the CU, but a check later on (in
     lnp_state_machine::check_line_address) will fail to properly
     exclude an entry that was removed via --gc-sections.  */
  if (lowpc != highpc)
    handle_DW_AT_stmt_list (die, cu, fnd, lowpc);

...in gdb/dwarf2/read.c:read_file_scope().

First, this

  baseaddr = objfile->text_section_offset ();

really refers to the ELF load offset, which, in the general case, need not
necessarily be the same as the offset of the text segment.  Correct?

Then, the code is adjusting low_pc but not high_pc so this check

  if (lowpc != highpc)

will pass almost guaranteed, also for the case mentioned in the comment
where we have neither low_pc nor high_pc.

Why are we adjusting low_pc at all here?  Eventually, we'd need to
relocate the entire debug info but isn't this too early?

Thanks,
Markus.

Intel Deutschland GmbH
Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de <http://www.intel.de>
Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva  
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928

Re: gdb/dwarf2/read.c:read_file_scope() lowpc adjustment

[Tom Tromey]

>> First, this
>>   baseaddr = objfile->text_section_offset ();
>> really refers to the ELF load offset, which, in the general case, need not
>> necessarily be the same as the offset of the text segment.  Correct?

In theory each offset could be different, and in theory this entry could
refer to a function in some other section, but in practice I think gdb
only really supports functions in the text section, or, at best, a
scenario where all functions in a given objfile are loaded at the same
runtime offset.

>> Then, the code is adjusting low_pc but not high_pc so this check
>>   if (lowpc != highpc)
>> will pass almost guaranteed, also for the case mentioned in the comment
>> where we have neither low_pc nor high_pc.

I don't know why I wrote it this way and not some other way.
From the comment it sounds like this is just checking for the case where
lowpc==0 and highpc==0.  And my recollection (supported by the patch) is
that this had to do with handling --gc-sections -- and in that scenario
the addresses will be set to 0.  So maybe rewording the check would be
good.

>> Why are we adjusting low_pc at all here?  Eventually, we'd need to
>> relocate the entire debug info but isn't this too early?

Personally I think it would be great if gdb delayed all the relocation
until the last possible moment -- when computing the address of a symbol
or block.  However, historically gdb always did this early, and changing
this is a massive effort.  We did, however, implement this idea for
minsyms and partial symbols.

Tom

RE: gdb/dwarf2/read.c:read_file_scope() lowpc adjustment

[Metzger, Markus T]

Thanks, Tom,

>>> First, this
>>>   baseaddr = objfile->text_section_offset ();
>>> really refers to the ELF load offset, which, in the general case, need not
>>> necessarily be the same as the offset of the text segment.  Correct?
>
>In theory each offset could be different, and in theory this entry could
>refer to a function in some other section, but in practice I think gdb
>only really supports functions in the text section, or, at best, a
>scenario where all functions in a given objfile are loaded at the same
>runtime offset.

In the same objfile or in the same compile unit?  From what I saw, so far,
GDB treats symbols section-relative (even though it relocates them too early).

In a few places, it asks for the text section offset (like here) but if that would
instead find the segment/section containing the original low_pc and then
add that segment/section's offset, I don't see why it wouldn't also work for
multiple text segments, even if they were loaded independently.  Same for
data.


>>> Why are we adjusting low_pc at all here?  Eventually, we'd need to
>>> relocate the entire debug info but isn't this too early?
>
>Personally I think it would be great if gdb delayed all the relocation
>until the last possible moment -- when computing the address of a symbol
>or block.  However, historically gdb always did this early, and changing
>this is a massive effort.  We did, however, implement this idea for
>minsyms and partial symbols.

I was missing that bit of history.  So minsyms also used to be adjusted
early and that got improved over time.  This explains the discrepancy I
was wondering about.

Thanks,
Markus.
Intel Deutschland GmbH
Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de <http://www.intel.de>
Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva  
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928

Re: gdb/dwarf2/read.c:read_file_scope() lowpc adjustment

[Tom Tromey]

>> In theory each offset could be different, and in theory this entry could
>> refer to a function in some other section, but in practice I think gdb
>> only really supports functions in the text section, or, at best, a
>> scenario where all functions in a given objfile are loaded at the same
>> runtime offset.

> In the same objfile or in the same compile unit?  From what I saw, so far,
> GDB treats symbols section-relative (even though it relocates them too early).

In the same objfile.  compunit_symtab has m_block_line_section but I
think I recall tracking this down at one point and discovering it could
only ever be SECT_OFF_TEXT.

Tom