Trepan-Debuggers / remake

Enhanced GNU Make - tracing, error reporting, debugging, profiling and more
http://bashdb.sf.net/remake
GNU General Public License v3.0
796 stars 75 forks source link

remake dts #119

Closed charlinone closed 3 years ago

charlinone commented 3 years ago

remake uboot .report remake dts error. session.log

charlinone commented 3 years ago

but "make" worked ,no error

rocky commented 3 years ago

See if you can isolate this down into a small test case. Isolating a test case should be made easier by using the additional logging that remake has to offer. Also, there is a debugger included too which allows you stop at a particular target and see what's up.

charlinone commented 3 years ago

yes ,i try step by step by remake ,i can see how the error occur .and compared with “make”, it seems "remake" cannot parse some escape character correctly in calling function of my makefile .in attach i see there is unnecessary "\" at head of last line in dtc_cmd_error_dts.log cmpared.txt remake_error.log dtc_cmd_error_dts.log

rocky commented 3 years ago

Ok. This is a step in the right direction. You have traced the program down the the error. I wouldn't call this isolating it which would mean after stepping it removing all the unneeded parts leaving the essential parts. Such as the final make command on the final make target which can be run in isolation.

From the log though, I don't see this as a remake problem. At some point it looks like a complicated gcc comand (mipsel-linux-gcc) command is run after some setup. From the log it looks like this the input given to gcc is:

/*
 * Copyright (C) 2018 MediaTek Inc.
 *
 * Author: Weijie Gao <weijie.gao@mediatek.com>
 */

/dts-v1/;
#include "mt7621.dtsi"

/ {
        model = "MediaTek MT7621 reference board (NAND)";
        compatible = "mediatek,mt7621-nand-rfb", "mediatek,mt7621-soc";

        chosen {
                stdout-path = &uartlite0;
        };
};

And the character backslash \ at the beginning of the line, line 9?, does look erroneous.

I am not saying there isn't a bug in remake. There might be. Or there may be some small subtle environment issue which remake is picking up that GNU make doesn't.

In order to fix the bug, work is needed to isolate the problem which means coming up with a small test case that shows the difference between GNU make and GNU remake. This small test case does not for example traverse directories checking dependencies to find the one that fails if they both agree that the failing target needs to get remade. And if they don't then isolating would be showing that one decides to build a target while another one does not.

remakes "pwd" will show you what directory make was probably run from. the "target" command tells you what was being rebuilt.

In the simple case (which is is most definitely not), you could just cd to the target directory and run remake -xX <target>. However here there are probably numerous environment variables and files set up first.

In sum, what we need to fix the problem is

charlinone commented 3 years ago

i abstract some code from uboot makefile ,and write my test case.i attahed it and output log of "remake" and "make" with my case compared_my_output.txt my.zip

rocky commented 3 years ago

Thanks for for the work spent on this. Right now I don't see a problem in remake. According to compared_my_output.txt both return an error 1, right? So in effect they do the same thing.

It is totally expected that the wording of the error messages and what appears on stdout are different. That's one of the reasons for remake: to try to make the messages more understandable. However the behavior: both programs try to run some commands because a target needs remaking and both give an error in trying to do so - that's the same.

charlinone commented 3 years ago

i think the cmdline parsed unconrrectly after function "make-cmd" ,"make" parsed it into '\''#include "mt7621-u-boot.dts"'\'' but "remake" pasred it into '\''\#include "mt7621-u-boot.dts"'\''

rocky commented 3 years ago

This is unexpected because this kind of thing GNU remake doesn't touch. There are hooks added various places but the rest of the code is the same. So I'll guess that this might have been a GNU make bug too and if you were to run the corresponding GNU Make version you'd get the same error as well.

What versions of make and remake are you running?

charlinone commented 3 years ago

with -v ,i see GNU make is 4.1,remake is GNU make 4.3+dbg1.5,you mean they should be the same GNU make version

rocky commented 3 years ago

Yes. The first two digits of remake give the version of GNU make that this is based on. So your version of remake is based on GNU Make 4.3 while your version of GNU make is 4.1.

There is a version of remake that is based on GNU make 4.1. It has fewer features though, just as GNU make 4.1 has fewer features than GNU make 4.3.

There are a couple of morals here. First is of course learning how to isolate a problem. In all the data of the first report, the most important information given in your first report is nowhere to be found.

Second, I'll say that in a couple of my other open-source projects on github, when you open a new issue, the template that you are presented with in fact asks the person opening the issue to give the environment and version numbers. Only about half the time do people do this. But whether this information is solicited or not, good practice is to give version information up front.

Learning how to report a bug and isolate problems should be of interest, because unless you do that, I don't care that much whether this program works for whatever it is that you decide to use it on. I wrote this because I found it useful and no one else was going to do it. Afterwards, I shared with others.

Increasingly, I have less time and interest in this, except to the extent that I need to use it. Unless you are a sponsor of the project, it is incumbent upon those who want help, to make it easy for the limited time I have to spend on this.