clang generated code sometimes confuses fbt

[Dimitry Andric]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ctfconvert-dwarf-1.diff
Type: text/x-diff
Size: 537 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20130303/37501679/attachment.diff>