headers
H.J. Lu | 1 Mar 2010 01:15
Picon

Re: [patch] Add support for <struct> and <flags> in target descriptions

On Mon, Feb 22, 2010 at 8:45 AM, Daniel Jacobowitz <dan <at> codesourcery.com> wrote:
> Hi H.J.,
>
> This patch adds <flags> support to the XML language.  Could you try
> using this to move the two x86 flags registers from out of
> target-descriptions.c?
>
> The flags support is straightforward and covered by the manual.
> It's not tested because I couldn't find a way to do so; you can't
> ptype a flags register, and you can't add dummy registers whose value
> you can get at, only for ptype.
>
> The patch also adds <struct>, which is a little more interesting.
> It's got two forms:
>
> * Register containing integer bitfields.  Each field must be
> explicitly positioned.  The size must be pre-declared - otherwise
> the representation GDB uses for big-endian bitfields can't figure out
> how far from the MSB edge of the register the field is.
>
> * Register containing typed non-bitfield structures.  Each field must
> be implicitly positioned.  There's no support for padding.
>
> These are somewhat annoying limitations, but they suffice for
> everything I've needed this for since I wrote the patch, which was
> originally several years ago; it's been stuck in my submission queue
> because it was tangled up with other local patches.  Since they are
> "must" restrictions, they are easy to lift in the future; we can make
> GDB more permissive.
>
(Continue reading)

Permalink | Reply | 6 comments |
headers
H.J. Lu | 1 Mar 2010 01:56
Picon

Re: [patch] Add support for <struct> and <flags> in target descriptions

On Sun, Feb 28, 2010 at 4:15 PM, H.J. Lu <hjl.tools <at> gmail.com> wrote:
> On Mon, Feb 22, 2010 at 8:45 AM, Daniel Jacobowitz <dan <at> codesourcery.com> wrote:
>> Hi H.J.,
>>
>> This patch adds <flags> support to the XML language.  Could you try
>> using this to move the two x86 flags registers from out of
>> target-descriptions.c?
>>
>> The flags support is straightforward and covered by the manual.
>> It's not tested because I couldn't find a way to do so; you can't
>> ptype a flags register, and you can't add dummy registers whose value
>> you can get at, only for ptype.
>>
>> The patch also adds <struct>, which is a little more interesting.
>> It's got two forms:
>>
>> * Register containing integer bitfields.  Each field must be
>> explicitly positioned.  The size must be pre-declared - otherwise
>> the representation GDB uses for big-endian bitfields can't figure out
>> how far from the MSB edge of the register the field is.
>>
>> * Register containing typed non-bitfield structures.  Each field must
>> be implicitly positioned.  There's no support for padding.
>>
>> These are somewhat annoying limitations, but they suffice for
>> everything I've needed this for since I wrote the patch, which was
>> originally several years ago; it's been stuck in my submission queue
>> because it was tangled up with other local patches.  Since they are
>> "must" restrictions, they are easy to lift in the future; we can make
>> GDB more permissive.
(Continue reading)

Permalink | Reply | 5 comments |
headers
H.J. Lu | 1 Mar 2010 03:20
Picon

Re: [patch] Add support for <struct> and <flags> in target descriptions

On Sun, Feb 28, 2010 at 4:56 PM, H.J. Lu <hjl.tools <at> gmail.com> wrote:
> On Sun, Feb 28, 2010 at 4:15 PM, H.J. Lu <hjl.tools <at> gmail.com> wrote:
>> On Mon, Feb 22, 2010 at 8:45 AM, Daniel Jacobowitz <dan <at> codesourcery.com> wrote:
>>> Hi H.J.,
>>>
>>> This patch adds <flags> support to the XML language.  Could you try
>>> using this to move the two x86 flags registers from out of
>>> target-descriptions.c?
>>>
>>> The flags support is straightforward and covered by the manual.
>>> It's not tested because I couldn't find a way to do so; you can't
>>> ptype a flags register, and you can't add dummy registers whose value
>>> you can get at, only for ptype.
>>>
>>> The patch also adds <struct>, which is a little more interesting.
>>> It's got two forms:
>>>
>>> * Register containing integer bitfields.  Each field must be
>>> explicitly positioned.  The size must be pre-declared - otherwise
>>> the representation GDB uses for big-endian bitfields can't figure out
>>> how far from the MSB edge of the register the field is.
>>>
>>> * Register containing typed non-bitfield structures.  Each field must
>>> be implicitly positioned.  There's no support for padding.
>>>
>>> These are somewhat annoying limitations, but they suffice for
>>> everything I've needed this for since I wrote the patch, which was
>>> originally several years ago; it's been stuck in my submission queue
>>> because it was tangled up with other local patches.  Since they are
>>> "must" restrictions, they are easy to lift in the future; we can make
(Continue reading)

Permalink | Reply | 2 comments |
headers
Daniel Jacobowitz | 1 Mar 2010 03:45

Re: [patch] Add support for <struct> and <flags> in target descriptions

On Sun, Feb 28, 2010 at 04:56:50PM -0800, H.J. Lu wrote:
> This patch makes it to work. However, there is no equivalent of
> 
> append_flags_type_flag (type, 1, NULL);

Is this to separate unknown bits (which should be displayed) from
don't-care bits (which are hidden)?

--

-- 
Daniel Jacobowitz
CodeSourcery
Permalink | Reply | 1 comment |
headers
H.J. Lu | 1 Mar 2010 04:06
Picon

Re: [patch] Add support for <struct> and <flags> in target descriptions

On Sun, Feb 28, 2010 at 6:45 PM, Daniel Jacobowitz <dan <at> codesourcery.com> wrote:
> On Sun, Feb 28, 2010 at 04:56:50PM -0800, H.J. Lu wrote:
>> This patch makes it to work. However, there is no equivalent of
>>
>> append_flags_type_flag (type, 1, NULL);
>
> Is this to separate unknown bits (which should be displayed) from
> don't-care bits (which are hidden)?
>

I believe so.

--

-- 
H.J.
Permalink | Reply | 0 comments |
headers
Joel Brobecker | 1 Mar 2010 07:47
Favicon

Re: Build errors on AIX

> It would perhaps be better to autoconf the getthrds declaration being
> present, here, in gdb/configure.ac:
[...]
> But I really don't know much about AIX.  Joel?  What do you
> think?  You seem to be one of that last that touched
> this `getthrds' bit of code.  :-)

Yep, I agree that this is the way to go. I checked on AIX 5.3,
this function is not declared in any of the /usr/include/*.h file.

> > but:  6.1 has the same break point problems as 5.3:
> > - with no breakpoint before 1st run, break points can't be set later at all
> > - otherwise break points seem to work

This is indeed very weird. I don't see any of that on our end.
I follow the AIX status relatively closely - even if we don't run
the AIX testsuite nightly, we run the AdaCore one every second day.
The AIX port should be in good shape!  You might want to try AdaCore's
sources to see if it makes any difference (we might have forgotten to
contribute a couple of patches), but I don't think so.

http://libre.adacore.com/libre/tools/more_resources/gdb-for-ada-snapshot/

This is what we call gdb-head at AdaCore, which include all of AdaCore's
changes while tracking the HEAD from the FSF tree.

--

-- 
Joel
(Continue reading)

Permalink | Reply | 0 comments |
headers
Joel Brobecker | 1 Mar 2010 07:51
Favicon

Re: some compile errors fo gdb-7.0.1

> one more small patch for AIX in config/mh-ppc-aix in case $CC includes
> spaces.  for some reason in older gdb version we needed CC='gcc
> -isystem /usr/include' shows that quoting problem.  will test if this
> still is needed (read: what's the real problem and a better fix, iff
> still needed at alll).

Your patch looks reasonable to me, but it is not relevant to GDB
specifically.  You need to send it to gcc-patches.

> Index: mh-ppc-aix
> ===================================================================
> RCS file: /cvs/src/src/config/mh-ppc-aix,v
> retrieving revision 1.3
> diff -u -r1.3 mh-ppc-aix
> --- mh-ppc-aix	16 Aug 2009 12:49:48 -0000	1.3
> +++ mh-ppc-aix	23 Feb 2010 16:31:34 -0000
>  <at>  <at>  -5,4 +5,4  <at>  <at> 
>  # don't do it any more.
>  BOOT_ADAFLAGS = -gnatapg
>  BOOT_LDFLAGS = -Wl,-bbigtoc
> -LDFLAGS = `case $(CC) in *gcc*) echo -Wl,-bbigtoc ;; esac;`
> +LDFLAGS = `case "$(CC)" in *gcc*) echo -Wl,-bbigtoc ;; esac;`

--

-- 
Joel
Permalink | Reply | 0 comments |
headers
Corinna Vinschen | 1 Mar 2010 10:09
Picon
Favicon

Re: [RFA] windows-nat.c: Cygwin: Port to Cygwin 1.7

On Feb 28 17:30, Christopher Faylor wrote:
> On Sun, Feb 28, 2010 at 04:08:44PM +0100, Corinna Vinschen wrote:
> >Hi,
> >
> >the below patch ports GDB to the latest Cygwin version 1.7.
> >
> >Three problems have to be fixed:
> >
> >- The maximum path length in Cygwin is no longer MAX_PATH.  Rather it
> >  is PATH_MAX, which is now 4096.  Actually, even paths up to 32K are
> >  supported, which is the maximum path length of the underlying Windows,
> >  but usually 4K is more than enough.
> >
> >- The aforementioned change required to provide a new Win32<->POSIX
> >  path conversion API which allows to handle paths longer than MAX_PATH.
> >  The old cygwin_conv_to_[full_]win32_path and cygwin_conf_to_[full_]posix
> >  path functions are deprecated now.  The below patch uses the new
> >  cygwin_conv_path API instead.
> >
> >- The Windows ANSI functions have two drawbacks.
> >
> >  - They return paths always in the default ANSI codepage, which is
> >    typically not the default codeset used in Cygwin 1.7 anymore.  UTF-8
> >    is now the default codeset in Cygwin.
> >
> >  - They are restricted to a path length of MAX_PATH bytes.
> >
> >  Since UTF-8 support and support for long paths are key changes in
> >  Cygwin 1.7, Cygwin now uses only Unicode Windows or native NT
> >  functions internally.  To overcome the restrictions of the Win32 ANSI
(Continue reading)

Permalink | Reply | 0 comments |
headers
Roland Schwingel | 1 Mar 2010 11:04
Picon
Favicon

Re: [RFA] windows-nat.c: Cygwin: Port to Cygwin 1.7

Hi Corinna,

I just came along your patch.

gdb-patches-owner <at> sourceware.org wrote on 28.02.2010 16:08:44:

 > Hi,
 >
 > the below patch ports GDB to the latest Cygwin version 1.7.
...
When I have read that correctly this means gdb would now no longer 
compile with cygwin 1.5?
Here I frequently compile gdb head for both cygwin 1.5 and cygwin 1.7. 
With your patch this would
no longer be possible.

Wouldn't it be better to encapsulate the 1.5 code and the 1.7 specific 
code with
an #if CYGWIN_VERSION_DLL_MAJOR >= 1007 (or something similar).
So on compiletime the proper functions would be selected for the right 
cygwin version.

I believe there are for sure more people than me out in this world still 
using cygwin 1.5 and wanting
to have a recent gdb...

Roland
Permalink | Reply | 1 comment |
headers
Corinna Vinschen | 1 Mar 2010 11:31
Picon
Favicon

Re: [RFA] defs.h: Define GDB_DEFAULT_TARGET_[WIDE_]CHARSET for Cygwin and MingW builds

On Feb 28 17:27, Daniel Jacobowitz wrote:
> On Sun, Feb 28, 2010 at 08:21:59PM +0100, Corinna Vinschen wrote:
> > On Feb 28 13:47, Daniel Jacobowitz wrote:
> > > On Sun, Feb 28, 2010 at 04:03:18PM +0100, Corinna Vinschen wrote:
> > > > If the codeset is target-specific anyway, then the idea of the
> > > > GDB_DEFAULT_TARGET_WIDE_CHARSET and GDB_DEFAULT_TARGET_CHARSET variables
> > > > is either wrong, or it must be possible to define them somewhere
> > > > on a per-target base.  What about windows-tdep.h?
> > > 
> > > If it has to be per-target at all, it needs to go in gdbarch; it can't
> > > be a #define any more, because we support multiple compiled-in
> > > architectures.  This is going to be significantly more complicated,
> > > though; there needs to be an "auto (currently cp1252)" style setting.
> > 
> > There is already a setting for the target charsets.  We're just
> > talking about setting a sane default.
> 
> We're talking past each other.  Compare show_host_charset_name
> (which has an auto setting) to show_target_charset_name (which does
> not).
> 
> If the default becomes dependent on the target, we need to distinguish
> "user specified iso-8859-1" or "user didn't say anything, but now
> we're debugging i686-mingw32, and that usually uses cp1252".

Ok.  Would the below be sufficient for a start?

Corinna

	* charset.c (auto_target_charset_name): New variable.
(Continue reading)

Permalink | Reply | 45 comments |

Gmane