Re: New gdb 31 & 64 bit patches for S/390

["Denis Joseph Barrow" <DJBARROW@de.ibm.com>]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2167 bytes --]

There are some target specific structures for to find out if I'm in a
signal handler which I
currently need see the s390_offsetof stuff in the tm-s390.c.

What about using the __attribute__(packed) gcc extension.
& add a
#ifndef gcc
define __attribute__
#endif
for non gcc compilers this would get around some of the common problems,
the only other way is for me to
add #defines for all the offsets I need.


D.J. Barrow Gnu/Linux for S/390 kernel developer
eMail: djbarrow@de.ibm.com,barrow_dj@yahoo.com
Phone: +49-(0)7031-16-2583
IBM Germany Lab, Schönaicherstr. 220, 71032 Böblingen


Andrew Cagney <ac131313@cygnus.com> on 05.07.2001 18:50:14

Please respond to Andrew Cagney <ac131313@cygnus.com>

To:   Denis Joseph Barrow/Germany/Contr/IBM@IBMDE
cc:   gdb-patches@sourceware.cygnus.com, s390-patches@gnu.org, Martin
      Schwidefsky/Germany/IBM@IBMDE, Christoph Arenz/Germany/IBM@IBMDE
Subject:  Re: New gdb 31 & 64 bit patches for S/390




> It'll be at least two weeks before I can go & update this stuff owing to
> other commitments.
> The asm/types.h in my opinion is currently needed, Andrew if you think it
> isn't, a
> config/arch/hosttypes.h with definitions for u8 u16 & u32 etc.
definitions
> should be introduced  for all archs
> IMO bfd_btye etc. as per previous suggestion simply doesn't cut mustard.


I don't think u8, u16, ... are needed.  As I noted:


> In the past it has been suggested that types like _u32, _u8 etc would
> allow the user to exactly describe structures and hence allow the
> programmer to exactly describe structure layout.  Unfortunatly, that
> won't work since allignment (and hence packing) also varies between
> hosts.
>
> If you need to read structures from memory you can use functions like:
>
>      LONGEST read_memory_integer (CORE_ADDR memaddr, int len);
>      ULONGEST read_memory_unsigned_integer (CORE_ADDR memaddr, int len);
>
> If you already have the memory local then:
>
>      LONGEST extract_signed_integer (void *, int);
>      ULONGEST extract_unsigned_integer (void *, int);
>
> will do the trick.


All other targets have managed to get things working using just the above.

     Andrew