[Bug default/33048] logic of --header-file appears to be reversed

[woodard at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=33048

--- Comment #3 from Ben Woodard <woodard at redhat dot com> ---
the fact that --header-dir1 doesn't work as expected is particularly curious
since:

 [    b3]    subprogram           abbrev: 10
             external             (flag_present) yes
             name                 (string) "mid"
             decl_file            (data1) v1.c (1)
             decl_line            (data1) 12
             decl_column          (data1) 7
             prototyped           (flag_present) yes
             type                 (ref4) [    33]
             low_pc               (addr) +0x000000000000039c <mid>
             high_pc              (data8) 24 (+0x00000000000003b4
<__super_secret_function1>)
             frame_base           (exprloc) 
              [ 0] call_frame_cfa
             call_all_calls       (flag_present) yes
             sibling              (ref4) [    f0]

Which should have been picked up and suppressed because v1.c is in
--headers-dir1 `pwd` since the `pwd` should have yielded:
/home/ben/Work/abidiff which is the CWD. 

It is believed that 
$ abidiff --headers-dir1 `pwd` --headers-dir2 `pwd` impl1.so impl2.so
and
$ abidiff --headers-dir1 . --headers-dir2 . impl1.so impl2.so

should work to also suppress __super_secret_function{1,2}

The general use case that we want to ultimately support is:

$ git clone <some project>
$ cd project
$ autoreconf -i
$ cd ../build
$ CXXFLAGS="-g -O2" ../configure --prefix=`pwd`/../test
$ make
$ abidiff --header-file1 /usr/include/project/public-api.h
/usr/lib64/libproject.so ../build/lib/libproject.so

that would test that what the developer is making is ABI compatible with what
is already on the system.

$ make install
$ cd ..
$ rm -rf build
$ abidiff --header-file1 test/include/public-api.h /usr/lib64/libproject.so
test/lib/libproject.so

In that case the original build directory is gone and only the installed
library project continues to exist. So they want some way to deal with the the
fact that the paths may encode the build dir but they want to be able to
compare the installed version of the libraries.

It needs to be noted that there are a couple of projects within our set of
packages where there are filename name collisions. I don't recall the details
but I remember running into problems with GDB because there were two foo.cc's
within the same project in different directories and it would get confused when
one was already open. This is probably considerably less likely to happen with
header files but since we are talking about selectively ignoring or rewriting
portions of the path encoded in DWARF, I thought that this wrinkle was
important to bring up so that you keep it in mind when designing the system.

-- 
You are receiving this mail because:
You are on the CC list for the bug.