From: Pedro Alves <palves@redhat.com>
To: Zack Weinberg <zackw@panix.com>
Cc: Phil Muldoon <pmuldoon@redhat.com>,
GNU C Library <libc-alpha@sourceware.org>,
gdb@sourceware.org, Joseph Myers <joseph@codesourcery.com>,
Florian Weimer <fweimer@redhat.com>,
tom@tromey.com, Siddhesh Poyarekar <siddhesh@gotplt.org>
Subject: Re: [RFC PATCH 0/3] Pretty-printing for errno
Date: Fri, 30 Jun 2017 16:38:00 -0000 [thread overview]
Message-ID: <2f28f69b-406f-65e5-40e1-ae65632ea4f0@redhat.com> (raw)
In-Reply-To: <CAKCAbMgAwZOG95hpAAAVYJd4SP6j3aAahOf=WWedjNJkj7_JsA@mail.gmail.com>
On 06/30/2017 01:28 AM, Zack Weinberg wrote:
> On Thu, Jun 29, 2017 at 1:28 PM, Pedro Alves <palves@redhat.com> wrote:
>> With this code:
>>
>> typedef int zzz;
>> zzz z;
>>
>> gdb:
>>
>> (gdb) whatis z
>> type = zzz
>> (gdb) whatis (zzz)0
>> type = zzz
>> (gdb) whatis zzz
>> type = int
>
I've now sent the patch to gdb-patches:
https://sourceware.org/ml/gdb-patches/2017-06/msg00827.html
Could one of you check whether the type printer kicks in with that,
in the problematic cast case?
Phil, might it be a good idea to convert what you were
using to a real gdb testsuite test?
> For the glibc patch to go through, this case also needs to work:
>
> typedef int error_t;
> error_t var;
> extern error_t *errloc(void);
>
> int main(void)
> {
> return *errloc();
> }
>
> (compiled to .o file)
>
> (gdb) ptype errloc
> No symbol "errloc" in current context.
>
> This might be a problem with inadequate debugging information
> generated by the compiler
Debug info is generated for function definitions, not declarations.
I.e., that declaration for "errloc" alone produces no debug info
at all. Try 'readelf -dw' on the .o file.
But why is this a valid scenario? Even if you have no debug info,
GDB should be able to find the function's address in the elf dynamic
symbol table?
I'm not sure what you mean by "glibc patch to go through".
If you mean acceptance upstream, then I'd consider this a separate
issue, because now you're talking about being able to print the
"errno" variable in the first place, even as a plain int with no
printer? That is related, but orthogonal from the error_t type printer?
Otherwise, can you clarify?
-- it does work correctly if a function
> *definition* is visible. But we need it to work given only the above,
> possibly with no debug symbols in the shared library defining
> "errloc".
Won't __errno_location be always present in the dynamic symbol table?
If you strip everything from libc.so.6 / libpthread.so.0 including
dynamic symbols, leaving gdb with no clue about "__errno_location",
let alone its address, there's no way that gdb can call it.
(Unless you call it by address manually.)
The next problem is that without debug info for __errno_location,
gdb has no clue of its prototype, only that its a function, and so
it assumes that it has type "int()", i.e., that it returns int,
while in reality it returns int * / __error_t *. (Falling back
to assuming "int" is IMO not the best idea, but I don't know
the history behind it.)
I.e., with your example .o + a separate .o file defining
errloc (with no debug info), we now get:
(gdb) ptype errloc
type = int ()
and then calling "p *errloc()" (the equivalent of
'#define errno (*__errno_location ())' silently subtly does
the wrong thing.
One dirty way around it would be for the printer to
re-define the errno macro (using to cast __errno_location to
the correct type before calling it, I guess:
(gdb) macro define errno *(*(__error_t *(*) (void)) __errno_location) ()
That's make "errno" available when you compile with levels
lower than -g3, too.
Fedora gdb has a morally equivalent hack in the source code
directly.
Ideally, we'd find a clean way to make this all Just Work.
Thanks,
Pedro Alves
next prev parent reply other threads:[~2017-06-30 16:38 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-22 22:45 Zack Weinberg
2017-06-22 22:45 ` [PATCH 1/3] Improve testing of GDB pretty-printers Zack Weinberg
2017-06-22 22:46 ` [PATCH 3/3] Add pretty-printer for errno Zack Weinberg
2017-06-22 22:46 ` [PATCH 2/3] Make error_t always int; make __errno_location return an __error_t Zack Weinberg
2017-06-29 15:48 ` [RFC PATCH 0/3] Pretty-printing for errno Phil Muldoon
2017-06-29 16:53 ` Pedro Alves
2017-06-29 17:02 ` Pedro Alves
2017-06-29 17:28 ` Pedro Alves
2017-06-30 0:28 ` Zack Weinberg
2017-06-30 16:38 ` Pedro Alves [this message]
2017-06-30 16:47 ` Pedro Alves
2017-06-30 17:27 ` Zack Weinberg
2017-06-30 18:11 ` Pedro Alves
2017-07-01 11:56 ` Pedro Alves
2017-07-13 2:30 ` Pedro Alves
2017-09-04 21:25 ` Pedro Alves
2017-09-05 21:15 ` Zack Weinberg
2017-09-05 22:32 ` Pedro Alves
2017-09-06 13:05 ` Zack Weinberg
2017-09-06 13:32 ` Pedro Alves
2017-09-06 21:03 ` Zack Weinberg
[not found] ` <2432779a-f146-1612-236e-84dde15c5d01@redhat.com>
2017-09-13 11:22 ` Using libthread_db.so with single-threaded programs, for TLS access (was: Re: [RFC PATCH 0/3] Pretty-printing for errno) Pedro Alves
2017-09-13 19:27 ` Philippe Waroquiers
2017-09-14 0:02 ` Using libthread_db.so with single-threaded programs, for TLS access Pedro Alves
2017-09-18 13:17 ` Carlos O'Donell
2017-09-18 14:28 ` Pedro Alves
2017-07-01 14:35 ` [RFC PATCH 0/3] Pretty-printing for errno Siddhesh Poyarekar
2017-07-04 15:54 ` Pedro Alves
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2f28f69b-406f-65e5-40e1-ae65632ea4f0@redhat.com \
--to=palves@redhat.com \
--cc=fweimer@redhat.com \
--cc=gdb@sourceware.org \
--cc=joseph@codesourcery.com \
--cc=libc-alpha@sourceware.org \
--cc=pmuldoon@redhat.com \
--cc=siddhesh@gotplt.org \
--cc=tom@tromey.com \
--cc=zackw@panix.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox