You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

338 lines
6.8 KiB

// SPDX-License-Identifier: GPL-2.0-or-later
20 years ago
/*
* (C) Copyright David Gibson <dwg@au1.ibm.com>, IBM Corporation. 2005.
*/
#include "dtc.h"
#include "srcpos.h"
20 years ago
extern FILE *yyin;
extern int yyparse(void);
extern YYLTYPE yylloc;
struct dt_info *parser_output;
bool treesource_error;
struct dt_info *dt_from_source(const char *fname)
20 years ago
{
parser_output = NULL;
treesource_error = false;
srcfile_push(fname);
yyin = current_srcfile->f;
yylloc.file = current_srcfile;
20 years ago
if (yyparse() != 0)
die("Unable to parse input tree\n");
if (treesource_error)
die("Syntax error parsing input tree\n");
20 years ago
return parser_output;
20 years ago
}
static void write_prefix(FILE *f, int level)
{
int i;
for (i = 0; i < level; i++)
fputc('\t', f);
}
static bool isstring(char c)
{
return (isprint((unsigned char)c)
|| (c == '\0')
|| strchr("\a\b\t\n\v\f\r", c));
}
static void write_propval_string(FILE *f, const char *s, size_t len)
{
const char *end = s + len - 1;
if (!len)
return;
assert(*end == '\0');
fprintf(f, "\"");
while (s < end) {
char c = *s++;
switch (c) {
case '\a':
fprintf(f, "\\a");
break;
case '\b':
fprintf(f, "\\b");
break;
case '\t':
fprintf(f, "\\t");
break;
case '\n':
fprintf(f, "\\n");
break;
case '\v':
fprintf(f, "\\v");
break;
case '\f':
fprintf(f, "\\f");
break;
case '\r':
fprintf(f, "\\r");
break;
case '\\':
fprintf(f, "\\\\");
break;
case '\"':
fprintf(f, "\\\"");
break;
case '\0':
fprintf(f, "\\0");
break;
default:
if (isprint((unsigned char)c))
fprintf(f, "%c", c);
else
fprintf(f, "\\x%02"PRIx8, c);
}
}
fprintf(f, "\"");
}
static void write_propval_int(FILE *f, const char *p, size_t len, size_t width)
{
const char *end = p + len;
assert(len % width == 0);
for (; p < end; p += width) {
switch (width) {
case 1:
fprintf(f, "%02"PRIx8, *(const uint8_t*)p);
break;
case 2:
fprintf(f, "0x%02"PRIx16, dtb_ld16(p));
break;
case 4:
fprintf(f, "0x%02"PRIx32, dtb_ld32(p));
break;
case 8:
fprintf(f, "0x%02"PRIx64, dtb_ld64(p));
break;
}
if (p + width < end)
fputc(' ', f);
}
}
static const char *delim_start[] = {
[TYPE_UINT8] = "[",
[TYPE_UINT16] = "/bits/ 16 <",
[TYPE_UINT32] = "<",
[TYPE_UINT64] = "/bits/ 64 <",
[TYPE_STRING] = "",
};
static const char *delim_end[] = {
[TYPE_UINT8] = "]",
[TYPE_UINT16] = ">",
[TYPE_UINT32] = ">",
[TYPE_UINT64] = ">",
[TYPE_STRING] = "",
};
static enum markertype guess_value_type(struct property *prop)
{
int len = prop->val.len;
const char *p = prop->val.val;
struct marker *m = prop->val.markers;
int nnotstring = 0, nnul = 0;
int nnotstringlbl = 0, nnotcelllbl = 0;
int i;
for (i = 0; i < len; i++) {
if (! isstring(p[i]))
nnotstring++;
if (p[i] == '\0')
nnul++;
}
for_each_marker_of_type(m, LABEL) {
if ((m->offset > 0) && (prop->val.val[m->offset - 1] != '\0'))
nnotstringlbl++;
if ((m->offset % sizeof(cell_t)) != 0)
nnotcelllbl++;
}
if ((p[len-1] == '\0') && (nnotstring == 0) && (nnul <= (len-nnul))
&& (nnotstringlbl == 0)) {
return TYPE_STRING;
} else if (((len % sizeof(cell_t)) == 0) && (nnotcelllbl == 0)) {
return TYPE_UINT32;
}
return TYPE_UINT8;
}
static void write_propval(FILE *f, struct property *prop)
{
size_t len = prop->val.len;
struct marker *m = prop->val.markers;
struct marker dummy_marker;
enum markertype emit_type = TYPE_NONE;
annotations: add the annotation functionality Provide the new command-line option: --annotate (abbreviated -T) --annotate provides one or more filenames and line numbers indicating the origin of a given line. The filename is expressed relative the the filename provided on the command line. Nothing is printed for overlays, etc. -T can be repeated giving more verbose annotations. These consist of one or more tuples of: filename, starting line, starting column, ending line ending column. The full path is given for the file name. Overlays, etc are annotated with <no-file>:<no-line>. The verbose annotations may be too verbose for normal use. There are numerous changes in srcpos.c to provide the relative filenames (variables initial_path, initial_pathlen and initial_cpp, new functions set_initial_path and shorten_to_initial_path, and changes in srcfile_push and srcpos_set_line). The change in srcpos_set_line takes care of the case where cpp is used as a preprocessor. In that case the initial file name is not the one provided on the command line but the one found at the beginnning of the cpp output. shorten_to_initial_path only returns a string if it has some shortening to do. Otherwise it returns NULL and relies on the caller to use the initial string. This simplifies memory management, by making clear to the caller whether a new string is allocated. The new functions srcpos_string_comment, srcpos_string_first, and srcpos_string_last print the annotations. srcpos_string_comment is recursive to print a list of source file positions. Various changes are sprinkled throughout treesource.c to print the annotations. Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
6 years ago
char *srcstr;
if (len == 0) {
annotations: add the annotation functionality Provide the new command-line option: --annotate (abbreviated -T) --annotate provides one or more filenames and line numbers indicating the origin of a given line. The filename is expressed relative the the filename provided on the command line. Nothing is printed for overlays, etc. -T can be repeated giving more verbose annotations. These consist of one or more tuples of: filename, starting line, starting column, ending line ending column. The full path is given for the file name. Overlays, etc are annotated with <no-file>:<no-line>. The verbose annotations may be too verbose for normal use. There are numerous changes in srcpos.c to provide the relative filenames (variables initial_path, initial_pathlen and initial_cpp, new functions set_initial_path and shorten_to_initial_path, and changes in srcfile_push and srcpos_set_line). The change in srcpos_set_line takes care of the case where cpp is used as a preprocessor. In that case the initial file name is not the one provided on the command line but the one found at the beginnning of the cpp output. shorten_to_initial_path only returns a string if it has some shortening to do. Otherwise it returns NULL and relies on the caller to use the initial string. This simplifies memory management, by making clear to the caller whether a new string is allocated. The new functions srcpos_string_comment, srcpos_string_first, and srcpos_string_last print the annotations. srcpos_string_comment is recursive to print a list of source file positions. Various changes are sprinkled throughout treesource.c to print the annotations. Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
6 years ago
fprintf(f, ";");
if (annotate) {
srcstr = srcpos_string_first(prop->srcpos, annotate);
if (srcstr) {
fprintf(f, " /* %s */", srcstr);
free(srcstr);
}
}
fprintf(f, "\n");
return;
}
Fix missing labels when emitting dts format When there is a label inside a sequence of ints at the end of a property, an assertion is hit because write_propval() expects all the labels to be at the very end of the property data. This is clearly wrong behaviour. To reproduce run: "dtc -O dts tests/label01.dts". dtc fails on property /randomnode/blob. Fix by reworking the write_propval() loop to remove the separate iterating over label markers. Instead handle the label markers as part of the main marker iteration loop. This guarantees that each label marker is handled at the right location, even if all the data markers have already been handled, and has the added advantage of making the code simpler. However, a side effect of this code is that a label at the very end of an int sequence will be emitted outside the sequence delimiters. For example: Input: intprop = < 1 2 L1: >, L2: < 3 4 L3: > L4:; Output: intprop = < 1 2 >, L1: L2: < 3 4 > L3: L4:; The two representations are equivalent in the data model, but the current test case was looking for the former, but needed to be modified to look for the later. The alternative would be to render labels before closing the sequence, but that makes less sense syntactically because labels between sequences are normally to point at the next one, not the former. For example: Input: intprop = < 1 2 L1: >, L2: < 3 4 L3: > L4:; Output: intprop = < 1 2 L1: L2: >, < 3 4 L3: L4: >; DTC doesn't current have the information to know if the label should be inside or outside the sequence, but in common usage, it is more likely that L1 & L2 refer to the second sequence, not the end of the first. Fixes: 32b9c6130762 ("Preserve datatype markers when emitting dts format") Reported-by: Łukasz Dobrowolski <lukasz.dobrowolski@nokia.com> Signed-off-by: Grant Likely <grant.likely@arm.com> Cc: David Gibson <david@gibson.dropbear.id.au> Cc: Rob Herring <robh@kernel.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
6 years ago
fprintf(f, " =");
if (!next_type_marker(m)) {
/* data type information missing, need to guess */
dummy_marker.type = guess_value_type(prop);
dummy_marker.next = prop->val.markers;
dummy_marker.offset = 0;
dummy_marker.ref = NULL;
m = &dummy_marker;
}
for_each_marker(m) {
Fix missing labels when emitting dts format When there is a label inside a sequence of ints at the end of a property, an assertion is hit because write_propval() expects all the labels to be at the very end of the property data. This is clearly wrong behaviour. To reproduce run: "dtc -O dts tests/label01.dts". dtc fails on property /randomnode/blob. Fix by reworking the write_propval() loop to remove the separate iterating over label markers. Instead handle the label markers as part of the main marker iteration loop. This guarantees that each label marker is handled at the right location, even if all the data markers have already been handled, and has the added advantage of making the code simpler. However, a side effect of this code is that a label at the very end of an int sequence will be emitted outside the sequence delimiters. For example: Input: intprop = < 1 2 L1: >, L2: < 3 4 L3: > L4:; Output: intprop = < 1 2 >, L1: L2: < 3 4 > L3: L4:; The two representations are equivalent in the data model, but the current test case was looking for the former, but needed to be modified to look for the later. The alternative would be to render labels before closing the sequence, but that makes less sense syntactically because labels between sequences are normally to point at the next one, not the former. For example: Input: intprop = < 1 2 L1: >, L2: < 3 4 L3: > L4:; Output: intprop = < 1 2 L1: L2: >, < 3 4 L3: L4: >; DTC doesn't current have the information to know if the label should be inside or outside the sequence, but in common usage, it is more likely that L1 & L2 refer to the second sequence, not the end of the first. Fixes: 32b9c6130762 ("Preserve datatype markers when emitting dts format") Reported-by: Łukasz Dobrowolski <lukasz.dobrowolski@nokia.com> Signed-off-by: Grant Likely <grant.likely@arm.com> Cc: David Gibson <david@gibson.dropbear.id.au> Cc: Rob Herring <robh@kernel.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
6 years ago
size_t chunk_len = (m->next ? m->next->offset : len) - m->offset;
size_t data_len = type_marker_length(m) ? : len - m->offset;
const char *p = &prop->val.val[m->offset];
struct marker *m_phandle;
if (is_type_marker(m->type)) {
Fix missing labels when emitting dts format When there is a label inside a sequence of ints at the end of a property, an assertion is hit because write_propval() expects all the labels to be at the very end of the property data. This is clearly wrong behaviour. To reproduce run: "dtc -O dts tests/label01.dts". dtc fails on property /randomnode/blob. Fix by reworking the write_propval() loop to remove the separate iterating over label markers. Instead handle the label markers as part of the main marker iteration loop. This guarantees that each label marker is handled at the right location, even if all the data markers have already been handled, and has the added advantage of making the code simpler. However, a side effect of this code is that a label at the very end of an int sequence will be emitted outside the sequence delimiters. For example: Input: intprop = < 1 2 L1: >, L2: < 3 4 L3: > L4:; Output: intprop = < 1 2 >, L1: L2: < 3 4 > L3: L4:; The two representations are equivalent in the data model, but the current test case was looking for the former, but needed to be modified to look for the later. The alternative would be to render labels before closing the sequence, but that makes less sense syntactically because labels between sequences are normally to point at the next one, not the former. For example: Input: intprop = < 1 2 L1: >, L2: < 3 4 L3: > L4:; Output: intprop = < 1 2 L1: L2: >, < 3 4 L3: L4: >; DTC doesn't current have the information to know if the label should be inside or outside the sequence, but in common usage, it is more likely that L1 & L2 refer to the second sequence, not the end of the first. Fixes: 32b9c6130762 ("Preserve datatype markers when emitting dts format") Reported-by: Łukasz Dobrowolski <lukasz.dobrowolski@nokia.com> Signed-off-by: Grant Likely <grant.likely@arm.com> Cc: David Gibson <david@gibson.dropbear.id.au> Cc: Rob Herring <robh@kernel.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
6 years ago
emit_type = m->type;
fprintf(f, " %s", delim_start[emit_type]);
} else if (m->type == LABEL)
Fix missing labels when emitting dts format When there is a label inside a sequence of ints at the end of a property, an assertion is hit because write_propval() expects all the labels to be at the very end of the property data. This is clearly wrong behaviour. To reproduce run: "dtc -O dts tests/label01.dts". dtc fails on property /randomnode/blob. Fix by reworking the write_propval() loop to remove the separate iterating over label markers. Instead handle the label markers as part of the main marker iteration loop. This guarantees that each label marker is handled at the right location, even if all the data markers have already been handled, and has the added advantage of making the code simpler. However, a side effect of this code is that a label at the very end of an int sequence will be emitted outside the sequence delimiters. For example: Input: intprop = < 1 2 L1: >, L2: < 3 4 L3: > L4:; Output: intprop = < 1 2 >, L1: L2: < 3 4 > L3: L4:; The two representations are equivalent in the data model, but the current test case was looking for the former, but needed to be modified to look for the later. The alternative would be to render labels before closing the sequence, but that makes less sense syntactically because labels between sequences are normally to point at the next one, not the former. For example: Input: intprop = < 1 2 L1: >, L2: < 3 4 L3: > L4:; Output: intprop = < 1 2 L1: L2: >, < 3 4 L3: L4: >; DTC doesn't current have the information to know if the label should be inside or outside the sequence, but in common usage, it is more likely that L1 & L2 refer to the second sequence, not the end of the first. Fixes: 32b9c6130762 ("Preserve datatype markers when emitting dts format") Reported-by: Łukasz Dobrowolski <lukasz.dobrowolski@nokia.com> Signed-off-by: Grant Likely <grant.likely@arm.com> Cc: David Gibson <david@gibson.dropbear.id.au> Cc: Rob Herring <robh@kernel.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
6 years ago
fprintf(f, " %s:", m->ref);
if (emit_type == TYPE_NONE || chunk_len == 0)
continue;
switch(emit_type) {
case TYPE_UINT16:
write_propval_int(f, p, chunk_len, 2);
break;
case TYPE_UINT32:
m_phandle = prop->val.markers;
for_each_marker_of_type(m_phandle, REF_PHANDLE)
if (m->offset == m_phandle->offset)
break;
if (m_phandle) {
if (m_phandle->ref[0] == '/')
fprintf(f, "&{%s}", m_phandle->ref);
else
fprintf(f, "&%s", m_phandle->ref);
if (chunk_len > 4) {
fputc(' ', f);
write_propval_int(f, p + 4, chunk_len - 4, 4);
}
} else {
write_propval_int(f, p, chunk_len, 4);
}
break;
case TYPE_UINT64:
write_propval_int(f, p, chunk_len, 8);
break;
case TYPE_STRING:
write_propval_string(f, p, chunk_len);
break;
default:
write_propval_int(f, p, chunk_len, 1);
}
Fix missing labels when emitting dts format When there is a label inside a sequence of ints at the end of a property, an assertion is hit because write_propval() expects all the labels to be at the very end of the property data. This is clearly wrong behaviour. To reproduce run: "dtc -O dts tests/label01.dts". dtc fails on property /randomnode/blob. Fix by reworking the write_propval() loop to remove the separate iterating over label markers. Instead handle the label markers as part of the main marker iteration loop. This guarantees that each label marker is handled at the right location, even if all the data markers have already been handled, and has the added advantage of making the code simpler. However, a side effect of this code is that a label at the very end of an int sequence will be emitted outside the sequence delimiters. For example: Input: intprop = < 1 2 L1: >, L2: < 3 4 L3: > L4:; Output: intprop = < 1 2 >, L1: L2: < 3 4 > L3: L4:; The two representations are equivalent in the data model, but the current test case was looking for the former, but needed to be modified to look for the later. The alternative would be to render labels before closing the sequence, but that makes less sense syntactically because labels between sequences are normally to point at the next one, not the former. For example: Input: intprop = < 1 2 L1: >, L2: < 3 4 L3: > L4:; Output: intprop = < 1 2 L1: L2: >, < 3 4 L3: L4: >; DTC doesn't current have the information to know if the label should be inside or outside the sequence, but in common usage, it is more likely that L1 & L2 refer to the second sequence, not the end of the first. Fixes: 32b9c6130762 ("Preserve datatype markers when emitting dts format") Reported-by: Łukasz Dobrowolski <lukasz.dobrowolski@nokia.com> Signed-off-by: Grant Likely <grant.likely@arm.com> Cc: David Gibson <david@gibson.dropbear.id.au> Cc: Rob Herring <robh@kernel.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
6 years ago
if (chunk_len == data_len) {
size_t pos = m->offset + chunk_len;
fprintf(f, pos == len ? "%s" : "%s,",
delim_end[emit_type] ? : "");
emit_type = TYPE_NONE;
}
}
annotations: add the annotation functionality Provide the new command-line option: --annotate (abbreviated -T) --annotate provides one or more filenames and line numbers indicating the origin of a given line. The filename is expressed relative the the filename provided on the command line. Nothing is printed for overlays, etc. -T can be repeated giving more verbose annotations. These consist of one or more tuples of: filename, starting line, starting column, ending line ending column. The full path is given for the file name. Overlays, etc are annotated with <no-file>:<no-line>. The verbose annotations may be too verbose for normal use. There are numerous changes in srcpos.c to provide the relative filenames (variables initial_path, initial_pathlen and initial_cpp, new functions set_initial_path and shorten_to_initial_path, and changes in srcfile_push and srcpos_set_line). The change in srcpos_set_line takes care of the case where cpp is used as a preprocessor. In that case the initial file name is not the one provided on the command line but the one found at the beginnning of the cpp output. shorten_to_initial_path only returns a string if it has some shortening to do. Otherwise it returns NULL and relies on the caller to use the initial string. This simplifies memory management, by making clear to the caller whether a new string is allocated. The new functions srcpos_string_comment, srcpos_string_first, and srcpos_string_last print the annotations. srcpos_string_comment is recursive to print a list of source file positions. Various changes are sprinkled throughout treesource.c to print the annotations. Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
6 years ago
fprintf(f, ";");
if (annotate) {
srcstr = srcpos_string_first(prop->srcpos, annotate);
if (srcstr) {
fprintf(f, " /* %s */", srcstr);
free(srcstr);
}
}
fprintf(f, "\n");
}
static void write_tree_source_node(FILE *f, struct node *tree, int level)
20 years ago
{
struct property *prop;
struct node *child;
struct label *l;
annotations: add the annotation functionality Provide the new command-line option: --annotate (abbreviated -T) --annotate provides one or more filenames and line numbers indicating the origin of a given line. The filename is expressed relative the the filename provided on the command line. Nothing is printed for overlays, etc. -T can be repeated giving more verbose annotations. These consist of one or more tuples of: filename, starting line, starting column, ending line ending column. The full path is given for the file name. Overlays, etc are annotated with <no-file>:<no-line>. The verbose annotations may be too verbose for normal use. There are numerous changes in srcpos.c to provide the relative filenames (variables initial_path, initial_pathlen and initial_cpp, new functions set_initial_path and shorten_to_initial_path, and changes in srcfile_push and srcpos_set_line). The change in srcpos_set_line takes care of the case where cpp is used as a preprocessor. In that case the initial file name is not the one provided on the command line but the one found at the beginnning of the cpp output. shorten_to_initial_path only returns a string if it has some shortening to do. Otherwise it returns NULL and relies on the caller to use the initial string. This simplifies memory management, by making clear to the caller whether a new string is allocated. The new functions srcpos_string_comment, srcpos_string_first, and srcpos_string_last print the annotations. srcpos_string_comment is recursive to print a list of source file positions. Various changes are sprinkled throughout treesource.c to print the annotations. Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
6 years ago
char *srcstr;
20 years ago
write_prefix(f, level);
for_each_label(tree->labels, l)
fprintf(f, "%s: ", l->label);
20 years ago
if (tree->name && (*tree->name))
annotations: add the annotation functionality Provide the new command-line option: --annotate (abbreviated -T) --annotate provides one or more filenames and line numbers indicating the origin of a given line. The filename is expressed relative the the filename provided on the command line. Nothing is printed for overlays, etc. -T can be repeated giving more verbose annotations. These consist of one or more tuples of: filename, starting line, starting column, ending line ending column. The full path is given for the file name. Overlays, etc are annotated with <no-file>:<no-line>. The verbose annotations may be too verbose for normal use. There are numerous changes in srcpos.c to provide the relative filenames (variables initial_path, initial_pathlen and initial_cpp, new functions set_initial_path and shorten_to_initial_path, and changes in srcfile_push and srcpos_set_line). The change in srcpos_set_line takes care of the case where cpp is used as a preprocessor. In that case the initial file name is not the one provided on the command line but the one found at the beginnning of the cpp output. shorten_to_initial_path only returns a string if it has some shortening to do. Otherwise it returns NULL and relies on the caller to use the initial string. This simplifies memory management, by making clear to the caller whether a new string is allocated. The new functions srcpos_string_comment, srcpos_string_first, and srcpos_string_last print the annotations. srcpos_string_comment is recursive to print a list of source file positions. Various changes are sprinkled throughout treesource.c to print the annotations. Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
6 years ago
fprintf(f, "%s {", tree->name);
20 years ago
else
annotations: add the annotation functionality Provide the new command-line option: --annotate (abbreviated -T) --annotate provides one or more filenames and line numbers indicating the origin of a given line. The filename is expressed relative the the filename provided on the command line. Nothing is printed for overlays, etc. -T can be repeated giving more verbose annotations. These consist of one or more tuples of: filename, starting line, starting column, ending line ending column. The full path is given for the file name. Overlays, etc are annotated with <no-file>:<no-line>. The verbose annotations may be too verbose for normal use. There are numerous changes in srcpos.c to provide the relative filenames (variables initial_path, initial_pathlen and initial_cpp, new functions set_initial_path and shorten_to_initial_path, and changes in srcfile_push and srcpos_set_line). The change in srcpos_set_line takes care of the case where cpp is used as a preprocessor. In that case the initial file name is not the one provided on the command line but the one found at the beginnning of the cpp output. shorten_to_initial_path only returns a string if it has some shortening to do. Otherwise it returns NULL and relies on the caller to use the initial string. This simplifies memory management, by making clear to the caller whether a new string is allocated. The new functions srcpos_string_comment, srcpos_string_first, and srcpos_string_last print the annotations. srcpos_string_comment is recursive to print a list of source file positions. Various changes are sprinkled throughout treesource.c to print the annotations. Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
6 years ago
fprintf(f, "/ {");
if (annotate) {
srcstr = srcpos_string_first(tree->srcpos, annotate);
if (srcstr) {
fprintf(f, " /* %s */", srcstr);
free(srcstr);
}
}
fprintf(f, "\n");
20 years ago
for_each_property(tree, prop) {
write_prefix(f, level+1);
for_each_label(prop->labels, l)
fprintf(f, "%s: ", l->label);
fprintf(f, "%s", prop->name);
write_propval(f, prop);
20 years ago
}
for_each_child(tree, child) {
fprintf(f, "\n");
write_tree_source_node(f, child, level+1);
20 years ago
}
write_prefix(f, level);
annotations: add the annotation functionality Provide the new command-line option: --annotate (abbreviated -T) --annotate provides one or more filenames and line numbers indicating the origin of a given line. The filename is expressed relative the the filename provided on the command line. Nothing is printed for overlays, etc. -T can be repeated giving more verbose annotations. These consist of one or more tuples of: filename, starting line, starting column, ending line ending column. The full path is given for the file name. Overlays, etc are annotated with <no-file>:<no-line>. The verbose annotations may be too verbose for normal use. There are numerous changes in srcpos.c to provide the relative filenames (variables initial_path, initial_pathlen and initial_cpp, new functions set_initial_path and shorten_to_initial_path, and changes in srcfile_push and srcpos_set_line). The change in srcpos_set_line takes care of the case where cpp is used as a preprocessor. In that case the initial file name is not the one provided on the command line but the one found at the beginnning of the cpp output. shorten_to_initial_path only returns a string if it has some shortening to do. Otherwise it returns NULL and relies on the caller to use the initial string. This simplifies memory management, by making clear to the caller whether a new string is allocated. The new functions srcpos_string_comment, srcpos_string_first, and srcpos_string_last print the annotations. srcpos_string_comment is recursive to print a list of source file positions. Various changes are sprinkled throughout treesource.c to print the annotations. Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
6 years ago
fprintf(f, "};");
if (annotate) {
srcstr = srcpos_string_last(tree->srcpos, annotate);
if (srcstr) {
fprintf(f, " /* %s */", srcstr);
free(srcstr);
}
}
fprintf(f, "\n");
20 years ago
}
void dt_to_source(FILE *f, struct dt_info *dti)
{
struct reserve_info *re;
fprintf(f, "/dts-v1/;\n\n");
for (re = dti->reservelist; re; re = re->next) {
struct label *l;
for_each_label(re->labels, l)
fprintf(f, "%s: ", l->label);
fprintf(f, "/memreserve/\t0x%016llx 0x%016llx;\n",
(unsigned long long)re->address,
(unsigned long long)re->size);
}
write_tree_source_node(f, dti->dt, 0);
}