PR25369 rfc: debuginfod client api extension for progressfn prettying etc.

Simon Marchi simark@simark.ca
Tue Feb 25 03:50:00 GMT 2020


On 2020-02-24 10:35 p.m., Frank Ch. Eigler wrote:
> Hi -
> 
> As a part of PR25369, I propose this small set of client api
> extensions, requested by gdb developers and needed by personal
> experience.  (I plan to roll it out on my debuginfod servers shortly
> to let it soak.)  An end-user visible immediate difference is in the
> DEBUGINFOD_PROGRESS=1 format message, which now looks like this:
> 
> Downloading from debuginfod /
> Downloading from debuginfod -
> Downloading from debuginfod \
> Downloading from http://very:8222/buildid/817dcbd2ce0ecce19f22cbe5e136b6d9196428aa/executable 433130328/433130328
> 
> This latter is a bit long and should probably be abbreviated, wdyt?
> 
> I'd start reviewing this from the debuginfod.h header file outward.
> 
> 
> commit 4ace515d6b9ce92ea4a808eba4d608851ee9b56d (fche/pr25369)
> Author: Frank Ch. Eigler <fche@redhat.com>
> Date:   Mon Feb 24 22:23:55 2020 -0500
> 
>     PR25369: client api extensions, progress prettying
>     
>     This batch of changes extends the client api with a group of optional
>     functions that allow:
>     - debuginfod to pass along User-Agent and appropriate XFF to
>       others, important for tracking in federated mode
>     - client applications to query URLs, get/set a void* parameter
>     - let the DEBUGINFOD_PROGRESS=1 progress handler show pretty URLs

Hi Frank,

As far as I am concerned (with my GDB hat), this looks good.

The "URL" section of the man page could maybe talk about the lifetime of the
returned string, specifically say that it's only guaranteed to be valid during
the execution of the callback.  If you need it for longer, then you need to copy
it.

Thanks!

Simon



More information about the Elfutils-devel mailing list