Date: Sun, 03 Mar 2013 21:02:03 +0100 From: Dimitry Andric <dim@FreeBSD.org> To: Andriy Gapon <avg@FreeBSD.org> Cc: freebsd-hackers@FreeBSD.org Subject: Re: clang generated code sometimes confuses fbt Message-ID: <5133AC3B.5040504@FreeBSD.org> In-Reply-To: <51337C27.7000105@FreeBSD.org> References: <5132387E.8010808@FreeBSD.org> <51323C62.4040506@FreeBSD.org> <51325FB3.7080300@FreeBSD.org> <51337018.30000@FreeBSD.org> <51337C27.7000105@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
This is a multi-part message in MIME format. --------------090508090006040708000301 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 2013-03-03 17:36, Andriy Gapon wrote: > on 03/03/2013 17:45 Dimitry Andric said the following: >> Debug log of ctfconvert operating on a gcc-compiled bpobj.o: >> >> http://www.andric.com/freebsd/ctfconvert-bpobj-gcc.log >> >> The same, but on a clang-compiled bpobj.o: >> >> http://www.andric.com/freebsd/ctfconvert-bpobj-clang.log >> >> This latter log does not change at all, if you change the FILE symbol to >> just "bpobj.c". So there seems to something else in (probably) the >> debug information that confuses ctfconvert. > > Sorry, but these two logs look so different to each other and your clang log is > so different from a log that I get here with that I believe that something is > wrong in your test. Indeed, apparently I copy/pasted the wrong command line from earlier in the build log, where it does not use -g (it is probably for the userland version of ctf). When I used the command line for the kernel build of bpobj.c, it did have -g, and the ctfconvert log had a lot more information. I have re-uploaded the logfile on the second URL above. I also had a look at ctfconvert, and it appears that in its dwarf reader, in cddl/contrib/opensolaris/tools/ctf/cvt/dwarf.c, it uses the basename, see lines 1825 through 1827: 1762 int 1763 dw_read(tdata_t *td, Elf *elf, char *filename __unused) 1764 { [...] 1824 if ((dw.dw_cuname = die_name(&dw, cu)) != NULL) { 1825 char *base = xstrdup(basename(dw.dw_cuname)); 1826 free(dw.dw_cuname); 1827 dw.dw_cuname = base; 1828 1829 debug(1, "CU name: %s\n", dw.dw_cuname); 1830 } while later on, in actually outputting the processed symbol table, in cddl/contrib/opensolaris/tools/ctf/cvt/output.c, it does not take the basename, but the full name: 336 static iiburst_t * 337 sort_iidescs(Elf *elf, const char *file, tdata_t *td, int fuzzymatch, 338 int dynsym) 339 { [...] 364 for (i = 0; i < nent; i++) { 365 GElf_Sym sym; [...] 372 if (gelf_getsym(data, i, &sym) == NULL) 373 elfterminate(file, "Couldn't read symbol %d", i); 374 375 match.iim_name = (char *)strdata->d_buf + sym.st_name; 376 match.iim_bind = GELF_ST_BIND(sym.st_info); 377 378 switch (GELF_ST_TYPE(sym.st_info)) { 379 case STT_FILE: 380 match.iim_file = match.iim_name; 381 continue; [...] 397 iidesc = find_iidesc(td, &match); 398 399 if (iidesc != NULL) { 400 tolist[*curr] = iidesc; 401 iidesc->ii_flags |= IIDESC_F_USED; 402 (*curr)++; 403 continue; 404 } On line 375, the full name is gotten from the elf symbol, on line 379 it is assigned to the iidesc_match_t struct which is used for searching, and in line 397 it does the actual search. So to fix this inconsistency, we could either change dw_read() to use the full name instead of the basename, or change sort_iidescs() to use the basename instead of the full name. The only upstream I have been able to find, Illumos, had the same code as FreeBSD for both of these functions, so it is likely they never noticed it before... My preference would be to remove the basename() call from dw_read(), as in the attached diff. That seems to fix the problem here; the diff of ctfdump output before and after becomes: --- ctfdump-before.log 2013-03-03 20:37:30.000000000 +0100 +++ ctfdump-after.log 2013-03-03 20:37:47.000000000 +0100 @@ -9,8 +9,8 @@ cth_lbloff = 0 cth_objtoff = 8 cth_funcoff = 10 - cth_typeoff = 140 - cth_stroff = 24164 + cth_typeoff = 160 + cth_stroff = 24184 cth_strlen = 20066 - Label Table ---------------------------------------------------------------- @@ -23,6 +23,8 @@ - Functions ------------------------------------------------------------------ + [0] FUNC (bpobj_iterate_impl) returns: 3 args: (1089, 1136, 56, 1092, 1163) + [1] FUNC (space_range_cb) returns: 3 args: (56, 1124, 1092) [2] FUNC (bpobj_alloc) returns: 324 args: (1080, 1092, 3) [3] FUNC (bpobj_alloc_empty) returns: 324 args: (1080, 3, 1092) [4] FUNC (bpobj_close) returns: 55 args: (1089) @@ -5099,10 +5101,10 @@ total number of data objects = 1 - total number of functions = 12 - total number of function arguments = 39 + total number of functions = 14 + total number of function arguments = 47 maximum argument list length = 6 - average argument list length = 3.25 + average argument list length = 3.36 total number of types = 1173 total number of integers = 18 --------------090508090006040708000301 Content-Type: text/x-diff; name="ctfconvert-dwarf-1.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ctfconvert-dwarf-1.diff" Index: cddl/contrib/opensolaris/tools/ctf/cvt/dwarf.c =================================================================== --- cddl/contrib/opensolaris/tools/ctf/cvt/dwarf.c (revision 247448) +++ cddl/contrib/opensolaris/tools/ctf/cvt/dwarf.c (working copy) @@ -1822,10 +1822,6 @@ dw_read(tdata_t *td, Elf *elf, char *filename __un } if ((dw.dw_cuname = die_name(&dw, cu)) != NULL) { - char *base = xstrdup(basename(dw.dw_cuname)); - free(dw.dw_cuname); - dw.dw_cuname = base; - debug(1, "CU name: %s\n", dw.dw_cuname); } --------------090508090006040708000301--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5133AC3B.5040504>