From: "Ulrich Weigand" <uweigand@de.ibm.com>
To: qiyaoltc@gmail.com (Yao Qi)
Cc: jan.kratochvil@redhat.com (Jan Kratochvil),
gdb-patches@sourceware.org (gdb-patches@sourceware.org),
kevinb@redhat.com (Kevin Buettner)
Subject: Re: [testsuite patchv2] [ppc64] gdb_target_symbol fix for function descriptors [Re: [testsuite patch] [ppc64] +kfail: gdb_target
Date: Tue, 12 Jul 2016 13:22:00 -0000 [thread overview]
Message-ID: <20160712132249.C26FA3BED@oc7340732750.ibm.com> (raw)
In-Reply-To: <CAH=s-PMPWJq4Jwdi9O=osKswyBHvTbr9rTuqCg0XH+YQ-UH2Bw@mail.gmail.com> from "Yao Qi" at Jul 12, 2016 01:56:36 PM
Yao Qi wrote:
> I am not sure what is the best approach of detecting function descriptor, so
> I copy Ulrich.
>
> I suspect we should check whether the program is compiled with ELFv1,
> in which function descriptor is used. So probably, we need to check
> __powerpc64__ and (!defined(_CALL_ELF) || _CALL_ELF !=3D 2) instead.
Well, most of the gdb.dwarf2 test cases simply use explicitly placed labels
for the DW_AT_low_pc / DW_AT_high_pc attributes.
See e.g. dw2-unresolved-main.c:
asm (".globl cu_text_start");
asm ("cu_text_start:");
int
main (void)
{
[...]
}
asm (".globl cu_text_end");
asm ("cu_text_end:");
and then in dw2-unresolved.S:
/* main */
.uleb128 3 /* Abbrev: DW_TAG_subprogram */
.byte 1 /* DW_AT_decl_file */
.byte 2 /* DW_AT_decl_line */
.ascii "main\0" /* DW_AT_name */
.4byte .Ltype_uchar-.Lcu1_begin /* DW_AT_type */
.4byte cu_text_start /* DW_AT_low_pc */
.4byte cu_text_end /* DW_AT_high_pc */
This is a bit of a hack, but should simply work on both architectures
with and without function descriptors. (Also, it actually gives you
something to use for DW_AT_high_pc as well, which would be hard to
come by otherwise in any case.)
If for some reason you want to check programmatically for presence of
function descriptors, then I agree that the __powerpc64__ ELFv1 ABI
check as you mention above is the correct way to do that.
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
Ulrich.Weigand@de.ibm.com
next prev parent reply other threads:[~2016-07-12 13:22 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-05 14:55 [testsuite patch] [ppc64] +kfail: gdb_target_symbol does not support function descriptors Jan Kratochvil
2016-07-06 7:51 ` Yao Qi
2016-07-06 8:11 ` Jan Kratochvil
2016-07-06 19:35 ` [testsuite patchv2] [ppc64] gdb_target_symbol fix for function descriptors [Re: [testsuite patch] [ppc64] +kfail: gdb_target_symbol does not support function descriptors] Jan Kratochvil
2016-07-12 12:56 ` Yao Qi
2016-07-12 13:22 ` Ulrich Weigand [this message]
2016-07-13 8:54 ` [testsuite patchv3] [ppc64] gdb_target_symbol fix for function descriptors [Re: [testsuite patch] [ppc64] +kfail: gdb_target Jan Kratochvil
2016-07-13 11:52 ` Ulrich Weigand
2016-07-13 12:02 ` [commit] " Jan Kratochvil
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=20160712132249.C26FA3BED@oc7340732750.ibm.com \
--to=uweigand@de.ibm.com \
--cc=gdb-patches@sourceware.org \
--cc=jan.kratochvil@redhat.com \
--cc=kevinb@redhat.com \
--cc=qiyaoltc@gmail.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