clang generated code sometimes confuses fbt

[Konstantin Belousov]

On Sat, Mar 02, 2013 at 09:23:15PM +0100, Dimitry Andric wrote:
> On 2013-03-02 18:52, Andriy Gapon wrote:
> > on 02/03/2013 19:35 Andriy Gapon said the following:
> >> Now, I am not quite sure why ctfconvert skips bpobj_iterate_impl in the
> >> clang-generated code.  Seems like some sort of a bug in ctfconvert.
> >
> > It seems that gcc and clang put different names for symbol of type FILE:
> > clang:
> > readelf -a -W /usr/obj/usr/src/sys/TRANT/bpobj.o| fgrep -w FILE
> >       1: 0000000000000000     0 FILE    LOCAL  DEFAULT  ABS
> > /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/bpobj.c
> >
> > gcc:
> > readelf -a -W /usr/obj/usr/src/sys/ODYSSEY/bpobj.o| fgrep -w FILE
> >       1: 0000000000000000     0 FILE    LOCAL  DEFAULT  ABS bpobj.c
> >
> > ctfconvert seems to compare this value with "bpobj.c" and so in the clang case
> > it doesn't recognize the static symbols.
> >
> > Does my analysis seem reasonable?
> 
> Have you verified that ctfconvert does the right thing, if you modify
> the FILE symbol to have just the filename?
> 
> Indeed, clang puts the original filename from the command line in the
> .file directive, while gcc explicitly removes any directory names; see
> contrib/gcc/toplev.c, around line 680:
> 
>    void
>    output_file_directive (FILE *asm_file, const char *input_name)
>    {
>      int len;
>      const char *na;
> 
>      if (input_name == NULL)
>        input_name = "<stdin>";
> 
>      len = strlen (input_name);
>      na = input_name + len;
> 
>      /* NA gets INPUT_NAME sans directory names.  */
>      while (na > input_name)
>        {
> 	if (IS_DIR_SEPARATOR (na[-1]))
> 	  break;
> 	na--;
>        }
> ...
> 
> That "NA gets INPUT_NAME sans directory names" comment was inserted by
> rms in r279. :-)  So I guess this is the way gcc has done it from the
> start, but there is no explanation as to why rms chose to remove those
> directory names.  I do not see the problem, except maybe for having
> reproducible builds?

I seems that at least gdb also depends on the stripping the path for stabs
(which is not dwarf) debugging format interpretation. On the FreeBSD
system, do 'info', select 'stabs' -> Stab Sections -> Elf Linker
Relocation. The last paragraph documents the gdb requirements.

So it seems that stripped path in the STT_FILE is the common expectation.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 834 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20130302/73534120/attachment.sig>