Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Doug Evans <dje@google.com>
To: Yao Qi <yao@codesourcery.com>
Cc: <gdb-patches@sourceware.org>
Subject: Re: [PATCH 0/6] Use correct function address in dwarf assembler
Date: Tue, 04 Nov 2014 23:01:00 -0000	[thread overview]
Message-ID: <21593.23259.292616.702553@ruffy2.mtv.corp.google.com> (raw)
In-Reply-To: <1414195968-3333-1-git-send-email-yao@codesourcery.com>

Yao Qi writes:
 > When we use dwarf assembler, it is common to generate DW_AT_low_pc and
 > DW_AT_high_pc attributes like this:
 > 
 >  	    subprogram {
 > 		{name main}
 > 		{low_pc main addr}
 > 		{high_pc main+0x100 addr}
 >             }
 > 
 > however, main is not resolved to function main's address on some
 > targets such as arm thumb mode and powerpc64.  One approach is to
 > get function address by labels, like this:
 > 
 >   asm ("func_start: .globl func_start");
 >   static void func (void) {}
 >   asm ("func_end: .globl func_end");
 > 
 > however, some compiler, such as clang, can't guarantee the order of
 > these labels and function, so it isn't portable.
 > 
 > In this patch series, we propose a new approach 
 > 
 >  1. get function start and end address correctly in a portable way,
 >  2. don't affect too much on existing test cases.
 > 
 > In patch 2/6, a new proc function_range is added.  In this proc, the
 > source file is compiled with debug info.
 > 
 >   int main (void)
 >   {
 >     asm ("main_label: .globl main_label");
 >     return 0;
 >   }
 > 
 > we can get the offset of main_label in function main, and then compute
 > the start address of main via main_label - main_label_offset.  This is
 > portable.
 > 
 > In order to avoid much changes to existing test cases, we have to use
 > function_range inside dwarf assembler.  Then, I invent some attribute
 > macros which look like DW attributes, but can be expanded to one or
 > more standard attributes.  The TAG_subprogram above will be simplified
 > with macro attribute used, it becomes:
 > 
 >     subprogram {
 > 	{MACRO_AT_func { func ${srcdir}/${subdir}/${srcfile} }}
 >     }
 > 
 > With this macro attribute, attributes name, low_pc and high_pc are
 > generated and set correctly.  See more details in patch 2/6.
 > 
 > Patch 4/6 is to use dwarf assembler to generate .S file, which is
 > identical to .S current one we are using.  Patch 3 and 5 is to use
 > macro attributes to get function start and end address correctly.
 > Patch 6 is remove labels and switch to use macro attribute to
 > get function start address to make clang happy.
 > 
 > I test the whole series by running tests under gdb.dwarf2/ on
 > powerpc-linux (both 32-bit and 64-bit), arm-none-eabi (arm mode
 > and thumb mode) and x86_64-linux.
 > 
 > Comments are very welcome!

Hi.
In general I like this a lot.
Just a few outstanding questions mentioned in replies to
the relevant patches.


      parent reply	other threads:[~2014-11-04 23:01 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-25  0:17 Yao Qi
2014-10-25  0:18 ` [PATCH 5/6] Fix implptr-optimized-out.exp fail Yao Qi
2014-11-04 22:53   ` Doug Evans
2014-10-25  0:18 ` [PATCH 6/6] Fix dw2-ifort-parameter.exp fail with clang Yao Qi
2014-11-04 22:54   ` Doug Evans
2014-10-25  0:18 ` [PATCH 1/6] New proc _handle_attribute Yao Qi
2014-11-04 22:48   ` Doug Evans
2014-10-25  0:18 ` [PATCH 3/6] Get start and end address of main in dwz.exp Yao Qi
2014-11-04 22:51   ` Doug Evans
2014-10-25  0:18 ` [PATCH 2/6] DW attribute macro MACRO_AT_func and MACRO_AT_range Yao Qi
2014-11-04 22:50   ` Doug Evans
2014-11-05  1:54     ` Yao Qi
2014-11-07 16:54       ` Doug Evans
2014-11-10  2:04         ` Yao Qi
2014-11-10 19:44           ` Doug Evans
2014-11-11  2:05             ` Yao Qi
2014-11-12  7:01               ` Doug Evans
2014-11-14  1:00                 ` Yao Qi
2014-11-04 22:59   ` Doug Evans
2014-10-25  0:18 ` [PATCH 4/6] Use Dwarf::assemble in implptr-optimized-out.exp Yao Qi
2014-11-04 22:53   ` Doug Evans
2014-11-04 23:01 ` Doug Evans [this message]

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=21593.23259.292616.702553@ruffy2.mtv.corp.google.com \
    --to=dje@google.com \
    --cc=gdb-patches@sourceware.org \
    --cc=yao@codesourcery.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