Odd log messages for apps using autotools and __FILE__

Odd log messages for apps using autotools and __FILE__

[Holger Freyther]

Hi,

in the Osmocom software and rauc and probably many applications that use __FILE__ in a
log statement the log output is now:

	/home/hfreyther/images/poky/build/tmp/work/sysmobts_v2-poky-linux-gnueabi/rauc/0+gitAUTOINC+d44adb0079-r4/git/src/install.c:811 I will unmount /mnt/rauc/rootfs.0

where it used to be:

	install.c:811 I will unmount /mnt/rauc/rootfs.0


I know I can use __BASE_FILE__ in gcc to get back to install.c but I wonder where this is
coming from? Is this a side-effect of using B!=S? Is there another config that was made to
pass the full path to the compiler?


kind regards

	holger

Re: Odd log messages for apps using autotools and __FILE__

[Richard Purdie]

On Fri, 2015-08-07 at 20:26 +0200, Holger Freyther wrote:
> Hi,
> 
> in the Osmocom software and rauc and probably many applications that use __FILE__ in a
> log statement the log output is now:
> 
> 	/home/hfreyther/images/poky/build/tmp/work/sysmobts_v2-poky-linux-gnueabi/rauc/0+gitAUTOINC+d44adb0079-r4/git/src/install.c:811 I will unmount /mnt/rauc/rootfs.0
> 
> where it used to be:
> 
> 	install.c:811 I will unmount /mnt/rauc/rootfs.0
> 
> 
> I know I can use __BASE_FILE__ in gcc to get back to install.c but I wonder where this is
> coming from? Is this a side-effect of using B!=S? Is there another config that was made to
> pass the full path to the compiler?

I can confirm that this is from the B != S change.

We've kept meaning to go and look at how gcc generates these paths to
maybe try and add the option to remove a prefix for example. The .debug
src paths have a rewrite mechanism and we could use this for other paths
too?

Cheers,

Richard

Re: Odd log messages for apps using autotools and __FILE__

[Holger Freyther]

> On 08 Aug 2015, at 18:30, Richard Purdie <richard.purdie@linuxfoundation.org> wrote:

> 
> I can confirm that this is from the B != S change.

Thank you. I like that OE is finally using this feature and that we could have a ro source
trree.

> We've kept meaning to go and look at how gcc generates these paths to
> maybe try and add the option to remove a prefix for example. The .debug
> src paths have a rewrite mechanism and we could use this for other paths
> too?

the macro is defined here[1] and on a very quick (<30s) look line-map doesn’t allow
any remapping. This means OE is the first buildsystem to systematically apply the
B != S? My hackish(?) solution would be to force __FILE__ to behave like __BASE_FILE__.

holger


[1] https://gcc.gnu.org/viewcvs/gcc/trunk/libcpp/macro.c?revision=225185&view=markup#l286
[2] https://gcc.gnu.org/viewcvs/gcc/trunk/libcpp/line-map.c?view=markup

Re: Odd log messages for apps using autotools and __FILE__

[Khem Raj]

[-- Attachment #1: Type: text/plain, Size: 2066 bytes --]


> On Aug 8, 2015, at 9:30 AM, Richard Purdie <richard.purdie@linuxfoundation.org> wrote:
> 
> On Fri, 2015-08-07 at 20:26 +0200, Holger Freyther wrote:
>> Hi,
>> 
>> in the Osmocom software and rauc and probably many applications that use __FILE__ in a
>> log statement the log output is now:
>> 
>> 	/home/hfreyther/images/poky/build/tmp/work/sysmobts_v2-poky-linux-gnueabi/rauc/0+gitAUTOINC+d44adb0079-r4/git/src/install.c:811 I will unmount /mnt/rauc/rootfs.0
>> 
>> where it used to be:
>> 
>> 	install.c:811 I will unmount /mnt/rauc/rootfs.0
>> 
>> 
>> I know I can use __BASE_FILE__ in gcc to get back to install.c

__BASE_FILE__ is a gnu extension, just be aware of that if you target portability

>> but I wonder where this is
>> coming from? Is this a side-effect of using B!=S? Is there another config that was made to
>> pass the full path to the compiler?
> 
> I can confirm that this is from the B != S change.
> 
> We've kept meaning to go and look at how gcc generates these paths to
> maybe try and add the option to remove a prefix for example. The .debug
> src paths have a rewrite mechanism and we could use this for other paths
> too?

__FILE__ is one of standard pre-processing macros that are computed by cpp and its supposed to contain the path and name by which cpp opens the current input file and naturally when B != S then you are referring to source file more commonly with absolute path, one could use relative paths  w.r.t build dir but thats up to components build system and may not be even possible in all cases. I don’t think there is any thing to fix there in compiler unless we want to violate the standard. .debug rewrite might be a different thing someone tried a stab at it see
https://sourceware.org/ml/gdb-patches/2011-06/msg00385.html but didn’t move very far since there were alternative ways.


> 
> Cheers,
> 
> Richard
> 
> --
> _______________________________________________
> poky mailing list
> poky@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/poky


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 211 bytes --]

Re: Odd log messages for apps using autotools and __FILE__

[Holger Freyther]

> On 08 Aug 2015, at 21:19, Khem Raj <raj.khem@gmail.com> wrote:
> 

>>> I know I can use __BASE_FILE__ in gcc to get back to install.c
> 
> __BASE_FILE__ is a gnu extension, just be aware of that if you target portability

Yes, that is mentioned in the GNU GCC documentation.


> __FILE__ is one of standard pre-processing macros that are computed by cpp and its supposed to contain the path and name by which cpp opens the current input file and naturally when B != S then you are referring to source file more commonly with absolute path, one could use relative paths  w.r.t build dir but thats up to components build system and may not be even possible in all cases. I don’t think there is any thing to fix there in compiler unless we want to violate the standard. .debug rewrite might be a different thing someone tried a stab at it see
> https://sourceware.org/ml/gdb-patches/2011-06/msg00385.html but didn’t move very far since there were alternative ways.

yes, but this leads to unreadable and huge log messages in many applications.
E.g. all invocations that do something like:


file.c:
	debug(__FILE__, __LINE__, “My message %d”, 23);

turns into

/home/hfreyther/poky/fido/build/tmp/work/armv5te-poky-musl/my-app/r0/git/src/component/file.c:2 My message 23

From my point of view this creates a usability issue for the developers. When I looked
at my BTS log. I couldn’t see the actual log messages (line wrapping, majority of output
being the path). Now it obvious that Poky is the first mainstream distribution to compile
with B!=S but is there a plan in regard to log messages? Migrate to use __BASE_FILE__?
Use __FILE__ but wrap it with strstr? Or is the situation okay enough?

kins regards
	holger