This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug debug/77985] DW_AT_comp_dir is omitted when filename is absolute and the file does not contain a specific typedef


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77985

--- Comment #8 from infinity0 at pwned dot gg ---
(In reply to Richard Biener from comment #6)
> So I just fixed the bug here, but yes, I don't know about the design
> decision.  I suppose CWD was decided to be useless in case of an absolute
> path to the file.
> 
> I don't think the debug info preserves -I paths in any standard way, so
> what's exactly the reason you consider CWD not redundant here?  [we could
> rewrite the file-name to relative to CWD]

Sorry, I only noticed your reply after I posted that patch. The main reasons
are:

1. So I can write a test case for the next patch I'd be submitting, since GCC
submission processes demand this :p and

2. Reduces code complexity - my patch deletes more lines than it adds.

3. It will be able to handle any extensions to DWARF in the future that add
relative paths elsewhere that one would want to resolve against DW_AT_comp_dir.
One could reuse the same logic everywhere (in bad pseudo-code):

resolve_some_dwarf_path (path) {
  return relative(path) ? DW_AT_comp_dir/path : path;
}

Conceptually, the working directory is independent from an input file, so it
would not be redundant to add it in the general case. *Sometimes*, *parts* of
it might be redundant yes - and rewriting the filename to be relative to this,
would remove the redundancy. Doing this is compatible with the above points,
and I could amend the patch to do this, although I suggest it's not worth the
effort (unless there is a function in GCC code that already does this).

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]