This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC PATCH 0/3] Pretty-printing for errno


On Friday 30 June 2017 10:57 PM, Zack Weinberg wrote:
> The _primary_ goal of the glibc patches is to trigger a pretty-printer
> when someone does
> 
> (gdb) p errno
> 
> with no further adornment. Since pretty-printers are keyed by type
> (and since people do store errno codes in other places than errno),
> this involves a type 'error_t' (and its implementation-namespace alias
> '__error_t'), but if we can't get 'p errno' to work, we're probably
> not going to bother.
> 
> In all currently-supported configurations, this is glibc's definition of errno:
> 
> extern int *__errno_location (void) __THROW __attribute__ ((__const__));
> #define errno (*__errno_location ())
> 
> (__THROW is a macro expanding to 'throw ()' when compiling C++.)
> 
> The patches change that to
> 
> extern __error_t *__errno_location (void) __THROW __attribute__ ((__const__));
> 
> which should be sufficient to get the pretty-printing happening.  But
> obviously that's only going to work if GDB actually knows that the
> return type of __errno_location is __error_t*, and it doesn't seem to,
> *even when debug information for the definition is available*:
> 
>  $ gdb /lib/x86_64-linux-gnu/libc.so.6
> GNU gdb (Debian 7.12-6) 7.12.0.20161007-git
> ...
> 
> Reading symbols from /lib/x86_64-linux-gnu/libc.so.6...Reading symbols
> from /usr/lib/debug/.build-id/cc/80584889db7a969292959a46c718a2b1500702.debug...done.
> done.
> (gdb) ptype __errno_location
> type = int ()
> (gdb) p __errno_location
> $1 = {<text variable, no debug info>} 0x20590 <__GI___errno_location>
> 
> ... a suspicion occurs...
> 
> (gdb) ptype __GI___errno_location
> type = int *(void)
> (gdb) p __GI___errno_location
> $2 = {int *(void)} 0x20590 <__GI___errno_location>
> 
> ... so I guess this is a problem with the __GI_ indirection, which
> *may* be a thing we can resolve on our end.  I don't fully understand
> that stuff.
> 
> Still, It Would Be Nice™ if you _didn't_ have to have the debug
> symbols for libc.so installed for this to work.  Probably a lot of
> people think you only need those if you are debugging libc itself.

The __GI_* alias is an internal alias of __errno_location and I've seen
this before with other symbols, where a function address resolves to the
internal alias instead of the public one in gdb as well as other places
like objdump.  It might make sense to turn this around, but I suspect
there may be a reason for it that I am unaware of.

Siddhesh


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]