public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Pedro Alves <palves@redhat.com>
To: Alan Hayward <Alan.Hayward@arm.com>
Cc: GDB Patches <gdb-patches@sourceware.org>, nd <nd@arm.com>
Subject: Re: [PATCH v3 3/3] Aarch64: Fix segfault when casting dummy calls
Date: Wed, 24 Oct 2018 15:15:00 -0000	[thread overview]
Message-ID: <201c7a49-ddf3-636a-f15a-eb9a4ccf284e@redhat.com> (raw)
In-Reply-To: <9290BC71-862C-48B1-97FD-A46C5D15A65C@arm.com>

On 10/23/2018 05:08 PM, Alan Hayward wrote:
> 
> 
>> On 19 Oct 2018, at 12:35, Pedro Alves <palves@redhat.com> wrote:
>>
> 
> <snip>
> 
>>> to calculate lang_struct_return. This information is available in the
>>> return_method enum. The fix is to simply use this instead.
>>>
>>> Add common test case using a shared library to ensure FUNC resolving.
>>
>> What does "common" mean here?
> 
> By common I just meant not-aarch64-specific. I guess what I really meant
> was any target that supported shared libraries.

I see.  (Suggest clarifying it in the commit log then.)

> 
>>
>> And what does "to ensure FUNC resolving" mean too, btw?
>> AFAICT, the only reason to use a shared library is to
>> compile it with or without debug information, right?
>> Come to think of it, you could instead eliminate the
>> shared library and compile a separate .o file instead, right?
>> That would simplify the testcase a bit and expose it to more
>> targets.
>>
> 
> I could only get the bug to expose itself when using a .so
> 
> If I do the following using current HEAD then the bug is not present:
> 
> g++ -c condbreak-solib-main.cc -o condbreak-solib-main.o -fno-inline
> g++ -c condbreak-solib-lib.cc -o condbreak-solib-lib.o -fno-inline
> g++ condbreak-solib-main.o condbreak-solib-lib.o
> 
> It causes the type of the return value to be detected as
> TYPE_CODE_PTR->TYPE_CODE_INT.

Huh.  That's really strange.  Where is that pointer coming from?

What does "ptype cmp3" say for you?

(gdb) b foo if (int)cmp3("abc") == 1
Breakpoint 1 at 0x40048b
(gdb) ptype cmp3
type = <unknown return type> ()
(gdb) whatis cmp3
type = <text variable, no debug info>


I wonder if what you're looking at is actually the malloc call?
GDB will call malloc to allocate space for the "abc" string in
the inferior.  Look at the backtrace, see where the call is coming
from.

Actually, because of that, I think it would be better (more focused)
to pass in a variable instead of "abc".  You already have the
unused variable "word" there:

const char *word = "stuff";

So:

 (gdb) b foo if (int)cmp3(word) == 1

but please rename it to something else, because I tried that
locally and there's another symbol called "word"
in glibc's localeinfo.h, and gdb picks that one up.

Also, is there a reason for the test to be a C++ program?
If there's none, it'd be better to make it a C program, again
to expose it to more targets.

Thanks,
Pedro Alves

  reply	other threads:[~2018-10-24 15:15 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-11 14:49 [PATCH v3 0/3] " Alan Hayward
2018-10-11 14:49 ` [PATCH v3 3/3] " Alan Hayward
2018-10-19 11:36   ` Pedro Alves
2018-10-23 16:08     ` Alan Hayward
2018-10-24 15:15       ` Pedro Alves [this message]
2018-10-29 11:58         ` Alan Hayward
2018-10-29 12:38           ` Pedro Alves
2018-10-29 14:56             ` Alan Hayward
2018-10-29 18:13               ` Pedro Alves
2018-10-30 11:13                 ` Alan Hayward
2018-10-30 16:31                   ` Pedro Alves
2018-10-30 17:09                     ` Alan Hayward
2018-10-30 17:40                       ` Pedro Alves
2018-10-11 14:49 ` [PATCH v3 1/3] Use enum for return method for " Alan Hayward
2018-10-19 11:28   ` Pedro Alves
2018-10-11 14:49 ` [PATCH v3 2/3] Pass return_method to _push_dummy_call Alan Hayward
2018-10-19 11:31   ` Pedro Alves
2018-10-18  9:50 ` [PING][PATCH v3 0/3] Aarch64: Fix segfault when casting dummy calls Alan Hayward

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=201c7a49-ddf3-636a-f15a-eb9a4ccf284e@redhat.com \
    --to=palves@redhat.com \
    --cc=Alan.Hayward@arm.com \
    --cc=gdb-patches@sourceware.org \
    --cc=nd@arm.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).