[Bug debuginfod/30589] New: debuginfod can't find sources even though they exist on disk

[Bug debuginfod/30589] New: debuginfod can't find sources even though they exist on disk

[russell at shotover dot com]

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

            Bug ID: 30589
           Summary: debuginfod can't find sources even though they exist
                    on disk
           Product: elfutils
           Version: unspecified
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P2
         Component: debuginfod
          Assignee: unassigned at sourceware dot org
          Reporter: russell at shotover dot com
                CC: elfutils-devel at sourceware dot org
  Target Milestone: ---

I'm trying to create a debuginfod server for our internal codebase, and would
like it to be able to serve correct sources, even for arbitrary old versions of
our software. We package as .deb, but the docs are pretty clear that that
doesn't support serving sources. So, I'm passing -ffile-prefix-map to where I
will eventually copy the sources, but debuginfod doesn't seem to want anything
to do with it:

```
echo 'int main() {}' > test.c
gcc -g -O0 test.c -Wl,--build-id=0xaaaaaaaaaabbbbbbbbbbccccccccccdddddddddd
-ffile-prefix-map=`pwd`=`pwd`/servefrom
mkdir servefrom
mv test.c a.out servefrom
rm ~/.debuginfod.sqlite
DEBUGINFOD_URLS="" debuginfod -F . -vvv
...
rm -rf ~/.cache/debuginfod_client
DEBUGINFOD_URLS="http://localhost:8002" debuginfod-find source
aaaaaaaaaabbbbbbbbbbccccccccccdddddddddd `pwd`/test.c
```
fails. Fetching the executable or debuginfo succeeds. 


The debuginfod log shows:

```
[Tue 27 Jun 2023 12:13:24 AM GMT] (496432/496443): 127.0.0.1:49688
UA:elfutils/0.189,Linux/x86_64,arch/ XFF: GET
/buildid/aaaaaaaaaabbbbbbbbbbccccccccccdddddddddd/source/tmp/asdf/servefrom/test.c
404 9 0+0ms
```


However, the same thing without the map works:

```
echo 'int main() {}' > test.c
gcc -g -O0 test.c -Wl,--build-id=0xaaaaaaaaaabbbbbbbbbbccccccccccdddddddddd
rm ~/.debuginfod.sqlite
DEBUGINFOD_URLS="" debuginfod -F . -vvv
...
rm -rf ~/.cache/debuginfod_client
DEBUGINFOD_URLS="http://localhost:8002" debuginfod-find source
aaaaaaaaaabbbbbbbbbbccccccccccdddddddddd `pwd`/test.c
```

I must have some incorrect assumption about how -F mode finds source
files....it seems like what I'm doing should be supported

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

[Bug debuginfod/30589] debuginfod can't find sources even though they exist on disk

[russell at shotover dot com]

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

--- Comment #1 from Russell Greene <russell at shotover dot com> ---
er, the correct command for the non-working case should be 

DEBUGINFOD_URLS="http://localhost:8002" debuginfod-find source
aaaaaaaaaabbbbbbbbbbccccccccccdddddddddd `pwd`/servefrom/test.c

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

[Bug debuginfod/30589] debuginfod can't find sources even though they exist on disk

[fche at redhat dot com]

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

Frank Ch. Eigler <fche at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fche at redhat dot com
   Last reconfirmed|                            |2023-06-27
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |WAITING

--- Comment #2 from Frank Ch. Eigler <fche at redhat dot com> ---
In my tests here on f38, the gcc -ffile-prefix-map option resulted in highly
sus dwarf:

% gcc -g -O0 test.c -Wl,--build-id=0xaaaaaaaaaabbbbbbbbbbccccccccccdddddddddd
-ffile-prefix-map=`pwd`=`pwd`/servefrom

% eu-readelf -w a.out
Directory table:
      [path(line_strp)]
 0     /home/fche/[...]/servefrom/servefrom (61)

i.e., the suffix was added twice.  On another test, where the map target
was to a non-subdirectory like /tmp/foo, gcc produced correct looking dwarf,
and debuginfod took it like a champ.

gcc version 13.1.1 20230614 (Red Hat 13.1.1-4) (GCC)

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

[Bug debuginfod/30589] debuginfod can't find sources even though they exist on disk

[russell at shotover dot com]

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

--- Comment #3 from Russell Greene <russell at shotover dot com> ---
Yeah, that looks like an issue for sure. Clang seems to omit more sane dwarf:

Directory table:
      [path(line_strp)]
 0     /home/russell/debuginfod_test/servefrom (0)


But debuginfod still doesn't seem to like it. 

Interestingly, the actual deployment didn't use a subpath, so I need to see
what's exactly going wrong with it--this issue here may actually be unrelated
to what I'm running into.

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

[Bug debuginfod/30589] debuginfod can't find sources even though they exist on disk

[russell at shotover dot com]

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

--- Comment #4 from Russell Greene <russell at shotover dot com> ---

% mkdir servefrom
% echo 'int main(){}' > test.c
% gcc -g test.c -ffile-prefix-map=`pwd`=`pwd`/servefrom -o test_gcc
% clang -g test.c -ffile-prefix-map=`pwd`=`pwd`/servefrom -o test_clang
% mv test.c servefrom
% gdb test_gcc -ex 'break main' -ex run -ex quit od
1       int main() {}
% gdb test_clang -ex 'break main' -ex run -ex quit od
1       int main() {}
% lldb test_gcc -o 'b main' -o 'run' -o 'quit'
( no source)
% lldb test_clang -o 'b main' -o 'run' -o 'quit'
-> 1    int main(){}


LLDB is not thrilled with whatever gcc is emitting here either. Maybe a GCC
bug? Think they would want this reported?

Regardless, this bug is pretty minor as mapping to a subdirectory seems to me a
pretty rare thing. I'll open a different bug report if I'm able to track the
bug I'm running into on (if it's not just a misconfiguration).

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