This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Add a dwarf unit type to represent 24 bit values.


On Thu, Sep 13, 2018 at 1:35 AM, John Darrington
<john@darrington.wattle.id.au> wrote:
> On Mon, Sep 10, 2018 at 04:40:58PM +0100, Jason Merrill wrote:
>      On Mon, Sep 10, 2018 at 3:42 PM, John Darrington
>      <john@darrington.wattle.id.au> wrote:
>      > On Mon, Sep 10, 2018 at 03:36:26PM +0100, Jason Merrill wrote:
>      >      On Mon, Aug 27, 2018 at 8:20 PM, John Darrington
>      >      <john@darrington.wattle.id.au> wrote:
>      >      >         * include/dwarf2.h (enum dwarf_unit_type) [DE_EH_PE_udata3]: New member.
>      >
>      >
>      >      What's the rationale?  Do you have a separate patch that uses this new macro?
>      >
>      > Yes.   I there is an upcoming patch for GDB.  See
>      > https://sourceware.org/ml/gdb-patches/2018-08/msg00731.html
>
>      This looks like support for reading fixed 3-byte values from the
>      exception handling unwind information.  Do you expect this information
>      to ever need to store 3-byte values?
>
> Yes,  I've already come across that (which is why I created the patch).
> Without this patch, GDB will barf.  See the attached backtrace.

Well, that's curious, given that GCC doesn't have that address type either.

Ah, looking closer, I see that we aren't dealing with the EH unwind
information, but rather the normal DWARF unwind information, which
uses

      /* The encoding for FDE's in a normal .debug_frame section
         depends on the target address size.  */
      cie->encoding = DW_EH_PE_absptr;

it seems strange that GDB then wants to use one of the other codes as
a proxy for loading a particular number of bytes.

I also notice that the default definition of DWARF2_ADDR_SIZE in GCC
has a comment,

/* The size of addresses as they appear in the Dwarf 2 data.
   Some architectures use word addresses to refer to code locations,
   but Dwarf 2 info always uses byte addresses.  On such machines,
   Dwarf 2 addresses need to be larger than the architecture's
   pointers.  */
#define DWARF2_ADDR_SIZE ((POINTER_SIZE + BITS_PER_UNIT - 1) / BITS_PER_UNIT)

And many targets with smaller pointers override this in GCC and GAS, e.g.

./gas/config/tc-msp430.h:#define DWARF2_ADDR_SIZE(bfd) 4
./gas/config/tc-s12z.h:#define DWARF2_ADDR_SIZE(bfd) 4
./gas/config/tc-wasm32.h:#define DWARF2_ADDR_SIZE(bfd)           4
./gas/config/tc-xgate.h:#define DWARF2_ADDR_SIZE(bfd) 4
./gas/config/tc-aarch64.c:/* Implement DWARF2_ADDR_SIZE.  */
./gas/config/tc-csky.h:#define DWARF2_ADDR_SIZE(bfd)   4
./gas/config/tc-avr.h:#define DWARF2_ADDR_SIZE(bfd) 4

Is this appropriate for your target, as well?

Perhaps GCC should double check that DWARF2_ADDR_SIZE is 2, 4, or 8.

Jason


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]