tinycc-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Tinycc-devel] [patch] adding path resolution to #line directives


From: Raul Hernandez
Subject: Re: [Tinycc-devel] [patch] adding path resolution to #line directives
Date: Fri, 6 May 2022 11:13:27 +0200

Hi,


It would seem better to canonicalize during generating this, because the above and this don't look equivalent anyway (they are equivalent only when the above relative path is less that seven levels deep from /).

In our case this isn’t an issue, since the .c file is always compiled under /tmp/v_*/, so two levels would actually be enough here.


The problem is that we cannot use an absolute path either (/home/…), because tcc will always prepend the file’s directory, even if the #line directive contains an absolute path.
I guess a different fix could be to check for absolute paths, and prevent tcc from prepending the file surname if that’s the case, but I still think resolving relative paths is useful
(one could generate #line directives like /my/lang/stdlib/../thirdparty/foo.c), and tcc would resolve them down to /my/lang/thirdparty/foo.c for cleaner backtraces, for example.


So you simply remove '../' components without a matching directory part. That isn't correct in all circumstances.

This is only ever hit when enough ../’s have been parsed so that the beginning of the path (inserted by tcc or otherwise) has been completely removed, and we’re left at the root of the filesystem. In that case, /../ can be collapsed down to / .
Could you give me an example of where this would be incorrect?


You might consider using realpath(3) (which is in POSIX) to do all of this for you.

I tried that, but realpath() checks if the path actually exists on the filesystem, and returns an error if it does not, unfortunately.


This might be generally usefull to libtcc users, and the variant printing it out can be written in terms of the char** variant; so that seems sensible to have.

I can include that function then; the main__foo -> main.foo change is indeed very V-specific.

Related: libbacktrace has an API where it accepts a callback, which is then called with a backtrace frame's information (https://github.com/ianlancetaylor/libbacktrace/blob/master/backtrace.h#L91-L102), so that might be a useful alternative too.


Raul


reply via email to

[Prev in Thread] Current Thread [Next in Thread]