From: Yao Qi <qiyaoltc@gmail.com>
To: Antoine Tremblay <antoine.tremblay@ericsson.com>
Cc: Yao Qi <qiyaoltc@gmail.com>, <gdb-patches@sourceware.org>
Subject: Re: [PATCH 3/5] Add support for ARM breakpoint types in GDBServer.
Date: Tue, 29 Sep 2015 08:32:00 -0000 [thread overview]
Message-ID: <86pp117hio.fsf@gmail.com> (raw)
In-Reply-To: <5609B069.6010200@ericsson.com> (Antoine Tremblay's message of "Mon, 28 Sep 2015 17:26:01 -0400")
Antoine Tremblay <antoine.tremblay@ericsson.com> writes:
> This will contain more stuff as I post the next patch sets for single
> stepping etc.. I would like to keep a more general name.
>
> It's basically all coming from arm-tdep.c but I don't want to name it
> common/arm-tdep.c to avoid confusion and Makefile problems.
>
> arm-ctdep.c ?
>
How about arm.c?
>> Please move this file to arch/ directory rather than common/
>
> It seems weird to me to have common objects somewhere else then in
> common/ , if common becomes more a lib we don't want it all over the
> place no ?
>
> Would creating a common/arch be acceptable ? I guess we would have to
> move things like x86-xstate.h etc.. there too ?
common/ was created in order to share code between GDB and GDBserver, see
https://sourceware.org/gdb/wiki/Common After that, we find that we'll
end up with moving most of gdb files into common/ and we'd better move
different common things into different common directory. Nowadays, we
have nat/ common/ and arch/ directories for common things. arm.c should
be put in arch/ directory.
>>> diff --git a/gdb/configure.tgt b/gdb/configure.tgt
>>> index c42b4df..e831f59 100644
>>> --- a/gdb/configure.tgt
>>> +++ b/gdb/configure.tgt
>>> @@ -89,7 +89,7 @@ arm*-wince-pe | arm*-*-mingw32ce*)
>>> ;;
>>> arm*-*-linux*)
>>> # Target: ARM based machine running GNU/Linux
>>> - gdb_target_obs="arm-tdep.o arm-linux-tdep.o glibc-tdep.o \
>>> + gdb_target_obs="arm-common.o arm-tdep.o arm-linux-tdep.o glibc-tdep.o \
>>> solib-svr4.o symfile-mem.o linux-tdep.o linux-record.o"
>>> build_gdbserver=yes
>>
>> since arm-common.o is moved out of arm-tdep.o, so it should be added to
>> every target which uses arm-tdep.o, such as aarch64*-*-linux*,
>> arm*-wince-pe, etc.
>
> Even if they don't use it ? But ok.
>
No, they use it. This patch moves thumb_insn_size to arm-common.o, but
thumb_insn_size is used by arm-tdep.c. If we don't add arm-common.o to
every target which uses arm-tdep.o, the build will fail on these targets
build/gdb/aarch64/gdb/../../../../binutils-gdb/gdb/arm-tdep.c:846: undefined reference to `thumb_insn_size'
build/gdb/aarch64/gdb/../../../../binutils-gdb/gdb/arm-tdep.c:846: undefined reference to `thumb_insn_size'
arm-tdep.o: In function `arm_adjust_breakpoint_address':
build/gdb/aarch64/gdb/../../../../binutils-gdb/gdb/arm-tdep.c:5417: undefined reference to `thumb_insn_size'
build/gdb/aarch64/gdb/../../../../binutils-gdb/gdb/arm-tdep.c:5467: undefined reference to `thumb_insn_size'
arm-tdep.o: In function `arm_breakpoint_from_pc':
build/gdb/aarch64/gdb/../../../../binutils-gdb/gdb/arm-tdep.c:8858: undefined reference to `thumb_insn_size'
>>
>>> diff --git a/gdb/gdbserver/linux-arm-low.c b/gdb/gdbserver/linux-arm-low.c
>>> index 367c704..15ecb70 100644
>>> --- a/gdb/gdbserver/linux-arm-low.c
>>> +++ b/gdb/gdbserver/linux-arm-low.c
>>> @@ -30,6 +30,8 @@
>>> #include "nat/gdb_ptrace.h"
>>> #include <signal.h>
>>>
>>> +#include "common/arm-common.h"
>>> +
>>> /* Defined in auto-generated files. */
>>> void init_registers_arm (void);
>>> extern const struct target_desc *tdesc_arm;
>>> @@ -234,19 +236,28 @@ arm_set_pc (struct regcache *regcache, CORE_ADDR pc)
>>> }
>>>
>>> /* Correct in either endianness. */
>>> -static const unsigned long arm_breakpoint = 0xef9f0001;
>>> -#define arm_breakpoint_len 4
>>> -static const unsigned short thumb_breakpoint = 0xde01;
>>> -static const unsigned short thumb2_breakpoint[] = { 0xf7f0, 0xa000 };
>>> +#define arm_abi_breakpoint 0xef9f0001UL
>>>
>>> /* For new EABI binaries. We recognize it regardless of which ABI
>>> is used for gdbserver, so single threaded debugging should work
>>> OK, but for multi-threaded debugging we only insert the current
>>> ABI's breakpoint instruction. For now at least. */
>>> -static const unsigned long arm_eabi_breakpoint = 0xe7f001f0;
>>> +#define arm_eabi_breakpoint 0xe7f001f0UL
>>> +
>>> +#ifndef __ARM_EABI__
>>> +static const unsigned long arm_breakpoint = arm_abi_breakpoint;
>>> +#else
>>> +static const unsigned long arm_breakpoint = arm_eabi_breakpoint;
>>> +#endif
>>> +
>>> +#define arm_breakpoint_len 4
>>> +static const unsigned short thumb_breakpoint = 0xde01;
>>> +#define thumb_breakpoint_len 2
>>> +static const unsigned short thumb2_breakpoint[] = { 0xf7f0, 0xa000 };
>>> +#define thumb2_breakpoint_len 4
>>
>> I am confused by your changes here. Why do you change them?
>>
>
> Before arm_breakpoint_from_pc would be :
>
> #ifndef __ARM_EABI__
> return (const unsigned char *) &arm_breakpoint;
> #else
> - return (const unsigned char *) &arm_eabi_breakpoint;
> #endif
>
> And arm_breakpoint_at would check for the arm_breakpoint ||
> arm_eabi_breakpoint.
>
> Thus the selected arm_breakpoint would be what that function returned
> and arm_breakpoint was arm_abi_breakpoint.
>
> It felt more clear to me to name those for what they are : 2 separate
> entities arm_abi_breakpoint and arm_eabi_breakpoint and set the
> current used one as arm_breakpoint.
>
> This allows a cleaner breakpoint_from_pc as it just returns
> arm_breakpoint rather than having the #ifdef in that function.
>
> Any other reference to the arm_breakpoint would also be clear of #ifdefs...
Please don't combine movement and refactoring. This patch is about
movement, so let us do movement only. Refactor can be done separately.
--
Yao (齐尧)
next prev parent reply other threads:[~2015-09-29 8:32 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-18 12:02 [PATCH 0/5] Software breakpoints support for ARM linux Antoine Tremblay
2015-09-18 12:02 ` [PATCH 2/5] Make breakpoint and breakpoint_len local variables in GDBServer Antoine Tremblay
2015-09-28 9:55 ` Yao Qi
2015-09-28 10:05 ` Eli Zaretskii
2015-09-28 21:01 ` Antoine Tremblay
2015-09-28 20:59 ` Antoine Tremblay
2015-09-18 12:03 ` [PATCH 5/5] Support software breakpoints for ARM linux " Antoine Tremblay
2015-09-18 12:03 ` [PATCH 1/5] Support multiple breakpoint types per target " Antoine Tremblay
2015-09-23 10:51 ` Yao Qi
2015-09-23 12:37 ` Antoine Tremblay
2015-09-23 14:46 ` Yao Qi
2015-09-23 14:56 ` Antoine Tremblay
2015-09-18 12:03 ` [PATCH 3/5] Add support for ARM breakpoint types " Antoine Tremblay
2015-09-28 10:29 ` Yao Qi
2015-09-28 21:26 ` Antoine Tremblay
2015-09-29 8:32 ` Yao Qi [this message]
2015-09-29 11:38 ` Antoine Tremblay
2015-09-29 11:43 ` Yao Qi
2015-09-18 12:03 ` [PATCH 4/5] Handle breakpoint kinds for software breakpoints " Antoine Tremblay
2015-09-28 10:33 ` Yao Qi
2015-09-29 11:55 ` Antoine Tremblay
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=86pp117hio.fsf@gmail.com \
--to=qiyaoltc@gmail.com \
--cc=antoine.tremblay@ericsson.com \
--cc=gdb-patches@sourceware.org \
/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