gdb: remove code to prepend comp dir in buildsym_compunit::start_subfile

The bit of code removed by this patch was introduced to fix the same
kind of problem that the previous patch fixes.  That is, to try to match
existing subfiles when different name forms are used to refer to a same
file.

The thread for the patch that introduced this code is:

  https://pi.simark.ca/gdb-patches/45F8CBDF.9090501@hq.tensilica.com/

The important bits are that the compiler produced a compilation unit
with:

    DW_AT_name : test.c
    DW_AT_comp_dir : /home/maxim/W/BadgerPass/PR_14999

and DWARF v2 line table with:

    The Directory Table:
    /home/maxim/W/BadgerPass/PR_14999

    The File Name Table:
    Entry Dir Time Size Name
    1 1 1173897037 152 test.c

Because the main symtab was created with only DW_AT_name, it was named
"test.c".  And because the path built from the line header contained the
"directory" part, it was "/home/maxim/W/BadgerPass/PR_14999/test.c".
Because of this mismatch, thing didn't work, so they added this code to
prepend the compilation directory to the existing subfile names, so that
this specific case would work.

With the changes done earlier in this series, where subfiles are
identified using the "most complete path possible", this case would be
handled.  The main subfile's would be
"/home/maxim/W/BadgerPass/PR_14999/test.c" from the start
(DW_AT_comp_dir + DW_AT_name).  It's not so different from some DWARF 5
cases actually, which make the compilation directory explicit in the
line table header.

I therefore think that this code is no longer needed.  It does feel like
a quick hack to make one specific case work, and we have a more general
solution now.  Also, this code was introduced to work around a problem
in the DWARF debug info or the DWARF debug info reader.  In general, I
think it's preferable for these hacks to be located in the specific
debug info reader code, rather than in the common code.

Even though this code was added to work around a DWARF reader problem,
it's possible that some other debug info reader has started taking
advantage of this code in the mean time.  It's very difficult to
know or verify, but I think the likelyhood is quite small, so I'm
proposing to get rid of it to simplify things a little bit.

Change-Id: I710b8ec0d449d1b110d67ddf9fcbdb2b37108306

0 files changed, 0 insertions, 0 deletions