Maciej W. Rozycki | 1 May 01:45 2012

Re: [PATCH] microMIPS support

On Fri, 27 Apr 2012, Eli Zaretskii wrote:

> >  So may I suggest fixing the release process to use the intended locale 
> > instead (C or en_US, or whatever)?
> 
> I don't know enough about the GDB releases to tell if this is
> practical.
> 
> Anyway, I try to keep all index entries start with a lower-case
> letter.  This is more reliable than imposing a certain locale on the
> environment where the release tarballs are made.

 I believe we already rely on this in some places.

> >  I'll see what I can do about it then, if that satisfies you.  However I 
> > still have troubles to accept this requirement.  So if the first word had 
> > to be a city or person's name, you'd demand it to start with a small 
> > letter too?
> 
> We don't have person names or cities in the GDB manual.  A manual that
> has many of these in the indices should probably consistently use
> capitalization of the first word in the index entries.

 I've just checked a random book that I have handy, that is "MIPS R4000 
Microprocessor User's Manual" and they mix cases in the index just fine on 
the similar principles that I'm referring to here.  As does "The Cambridge 
Grammar of the English Language" (a reference of a better authority 
probably, but only available in hard copy, so you may not have one readily 
available to check yourself).

(Continue reading)

Jan Kratochvil | 1 May 04:34 2012
Picon

Re: [PATCH] Remove board setting `gdb,cannot_call_functions'

On Tue, 24 Apr 2012 15:55:35 +0200, Pedro Alves wrote:
> The powerpc-sim ones could still be relevant, and tested, I suppose.

I have disabled powerpc-sim build in 2008 as it cannot run even a hello world
testcase. There was some small change in 2008, maybe some changes last in
2006, I doubt powerpc-sim can be used anymore.

Thanks,
Jan

Doug Evans | 1 May 04:57 2012
Picon

[commit] fix date in ChangeLog entry

Hi.

fyi, minor fix.

--- ChangeLog	30 Apr 2012 18:06:48 -0000	1.14189
+++ ChangeLog	1 May 2012 02:55:09 -0000
 <at>  <at>  -1,4 +1,4  <at>  <at> 
-2012-04-26  Sterling Augustine  <saugustine <at> google.com>
+2012-04-30  Sterling Augustine  <saugustine <at> google.com>

 	* contrib: New directory.
 	* contrib/test_pubnames_and_indexes.py: New file.

Yao Qi | 1 May 12:54 2012

[ping 2]: [patch] Setup kfail in gdb.mi/mi-solib.exp

On 04/12/2012 12:04 PM, Yao Qi wrote:
> 	* gdb.mi/mi-solib.exp: Setup kfail for gdb/13860.
> 
> diff --git a/gdb/testsuite/gdb.mi/mi-solib.exp b/gdb/testsuite/gdb.mi/mi-solib.exp
> index 8e99f90..8e548f4 100644
> --- a/gdb/testsuite/gdb.mi/mi-solib.exp
> +++ b/gdb/testsuite/gdb.mi/mi-solib.exp
>  <at>  <at>  -59,4 +59,9  <at>  <at>  mi_gdb_test "777-gdb-set stop-on-solib-events 1" "777\\^done" \
>  # We use "run" rather than "-exec-run" here in order to test that CLI
>  # commands still cause the correct MI output to be generated.
>  mi_run_with_cli
> +
> +global async
> +if { $async } {
> +    setup_kfail gdb/13860 *-*-*
> +}
>  mi_expect_stop solib-event .* .* .* .* .* "check for solib event"

Ping 2.  http://sourceware.org/ml/gdb-patches/2012-04/msg00271.html

The patch itself is quite simple.  Is it OK?

--

-- 
Yao (齐尧)

Jan Kratochvil | 1 May 16:04 2012
Picon

Re: [RFA] MIPS16 FP manual call/return fixes

On Mon, 30 Apr 2012 23:42:44 +0200, Maciej W. Rozycki wrote:
> +  find_pc_partial_function_gnu_ifunc (b->loc->address, NULL,
> +                                     &func_func_addr, NULL, &is_gnu_ifunc);
> +  gdb_assert (is_gnu_ifunc);

Please remove that gdb_assert and fall back somehow, IMO just pass FUNCTION as
NULL in such case.  Any resolving ADDRESS->SYMBOL can be ambiguous with weird
symbol files and it may find some overlapping non-IFUNC symbol instead.
Also user may have unloaded symbol files in the middle of the debugging etc.

Otherwise OK from me for the IFUNC part.

FYI getting with your original patch:

bfin-tdep.c: In function 'bfin_gdbarch_init':
bfin-tdep.c:841:3: error: passing argument 2 of 'set_gdbarch_return_value' from incompatible
pointer type [-Werror]
In file included from defs.h:945:0,
                 from bfin-tdep.c:22:
gdbarch.h:452:13: note: expected 'enum return_value_convention (*)(struct gdbarch *, struct value *,
struct type *, struct regcache *, gdb_byte *, const gdb_byte *)' but argument is of type 'enum
return_value_convention (*)(struct gdbarch *, struct type *, struct type *, struct regcache *,
gdb_byte *, const gdb_byte *)'

So maybe your patch I used is already obsolete or be sure you run with
"--enable-64-bit-bfd --enable-targets=all".

Thanks,
Jan

(Continue reading)

Maciej W. Rozycki | 1 May 19:21 2012

Re: [RFA] MIPS16 FP manual call/return fixes

On Tue, 1 May 2012, Jan Kratochvil wrote:

> > +  find_pc_partial_function_gnu_ifunc (b->loc->address, NULL,
> > +                                     &func_func_addr, NULL, &is_gnu_ifunc);
> > +  gdb_assert (is_gnu_ifunc);
> 
> Please remove that gdb_assert and fall back somehow, IMO just pass 
> FUNCTION as NULL in such case.

 It may not matter for most platforms, but if that ever happens for one of 
the MIPS ABIs affected, then this will fail an assertion in the backend 
instead.  It is invalid to call any of these backends with NULL FUNCTION 
and non-NULL READBUF both at a time, because the handler needs to retrieve 
the return value from the correct registers and it can only do that when 
it knows the address of the function called.

>  Any resolving ADDRESS->SYMBOL can be ambiguous with weird symbol files 
> and it may find some overlapping non-IFUNC symbol instead. Also user may 
> have unloaded symbol files in the middle of the debugging etc.

 OK, so let me put this another way.  Here we have just returned from a 
function that we called.  Obviously that function does exist somewhere no 
matter if symbol tables have been unloaded or whatever.  How can we 
determine the address of that function? -- in a different way, presumably.  
We must have somehow established its address previously or we couldn't 
have called it.  Is it possible to cache it somehow for example?

 Thanks for raising the issue of unloading symbol tables, that's an 
important point as to how MIPS16 and microMIPS symbols should be treated 
in general -- here I think it will only matter in the asynchronous mode. 
(Continue reading)

Maciej W. Rozycki | 1 May 22:17 2012

[PATCH] configure.ac: Also quote '$' in tbaseargs

Hi,

 While working on some GDB changes I have stumbled across this, which 
looks like a buglet in the top-level configure.  Perhaps a three-way merge 
error from the past.  Unfortunately there is nothing in ChangeLog that 
would indicate when these bits were introduced.

 We have these two variables, $baseargs and $tbaseargs, that we handle 
almost identically, except some bits are omitted from $tbaseargs only, 
based on $skip_targ.  However, at the point we decide to quote '$' in any 
of the options collected we only do so for $baseargs.  As a result, '$' 
won't be escaped correctly in $tbaseargs and will break in sub-makes used 
for the target.  Have I missed anything?

 If not, then here's an obvious fix.  Found by inspection, I don't have a 
test case handy.  OK to apply?

2012-05-01  Maciej W. Rozycki  <macro <at> codesourcery.com>

	* configure.ac: Also quote '$' in tbaseargs.
	* configure: Regenerate.

  Maciej

gcc-ac-fix.diff
Index: gcc-fsf-trunk-quilt/configure
===================================================================
--- gcc-fsf-trunk-quilt.orig/configure	2012-05-01 20:44:33.995609891 +0100
+++ gcc-fsf-trunk-quilt/configure	2012-05-01 20:52:00.345564017 +0100
 <at>  <at>  -7267,6 +7267,7  <at>  <at>  done
(Continue reading)

Joel Brobecker | 2 May 01:04 2012

Invalid segment resister value on x86_64-windows

Hello,

One of our customers noticed that GDB was displaying invalid values
for the ss & gs register.  It's obviously invalid because the value
was wider than the registers' size (16 bits). I noticed that the XML
files define these register as being 32bit, which I am assuming was
an oversight (?).

As a result of the 32bit size, GDB was reading the value of these
registers as 4 bytes, instead of just 2. On GNU/Linux, I did not
check the kernel sources, but it appears that it was harmless,
because the extra bytes were always zero. But on some Windows
systems, we werent' that lucky.  The extra 2 bytes were not null,
and thus we ended up with a polluted value.

This patch series first regenerates the .c files in features/i386,
because I noticed a difference between the current files and the
generated version.  And the second patch changes the size of all
segment registers to match the size found in the various reference
manuals.

The series was tested on x86_64-linux, standalone and then with
gdbserver. I also checked by hand that the new GDB is still able
to work with an older GDBserver (thanks to the fact that GDBserver
sends the target description to GDB). And I also tested this patch
on x86_64-windows, using AdaCore's testsuite.

Joel Brobecker | 2 May 01:04 2012

[RFA/commit 1/2] Regenerate the features/i386 target description .c files

There's been a minor change in the code generator that affects
how a couple of local variables are being declared.  This patch
regenerates the .c files in features/i386 to bring them up to
date.

gdb/ChangeLog:

	* features/i386/amd64-avx-linux.c, features/i386/amd64-avx.c,
	features/i386/amd64-linux.c, features/i386/amd64.c,
	features/i386/i386-avx-linux.c, features/i386/i386-avx.c,
	features/i386/i386-linux.c, features/i386/i386-mmx-linux.c,
	features/i386/i386.c, features/i386/x32-avx-linux.c,
	features/i386/x32-avx.c, features/i386/x32-linux.c,
	features/i386/x32.c: Regenerate.

Will commit in a day or two pending comments.

---
 gdb/features/i386/amd64-avx-linux.c |    3 ++-
 gdb/features/i386/amd64-avx.c       |    3 ++-
 gdb/features/i386/amd64-linux.c     |    3 ++-
 gdb/features/i386/amd64.c           |    3 ++-
 gdb/features/i386/i386-avx-linux.c  |    3 ++-
 gdb/features/i386/i386-avx.c        |    3 ++-
 gdb/features/i386/i386-linux.c      |    3 ++-
 gdb/features/i386/i386-mmx-linux.c  |    2 +-
 gdb/features/i386/i386.c            |    3 ++-
 gdb/features/i386/x32-avx-linux.c   |    3 ++-
 gdb/features/i386/x32-avx.c         |    3 ++-
 gdb/features/i386/x32-linux.c       |    3 ++-
(Continue reading)

Joel Brobecker | 2 May 01:04 2012

[RFA 2/2] [x86/x86_64] Segment registers are 16 bits long (not 32bits)

This patch changes the description of all segment registers for
x86 and x86_64 targets to 16 bits. On GNU/Linux systems, this
discrepancy appears to be harmless. But, on some Windows systems,
the wider size lead us to read the value of those registers as
4-byte values instead of 2 bytes values, resulting in incorrect
results.

gdb/changeLog:

	* features/i386/32bit-core.xml, features/i386/64bit-core.xml,
	features/i386/x32-core.xml: Set bitsize and type of all
	segment registers to 16 and "int16" respectively.
	* features/i386/amd64-avx-linux.c, features/i386/amd64-avx.c,
	features/i386/amd64-linux.c, features/i386/amd64.c,
	features/i386/i386-avx-linux.c, features/i386/i386-avx.c,
	features/i386/i386-linux.c, features/i386/i386-mmx-linux.c,
	features/i386/i386-mmx.c, features/i386/i386.c,
	features/i386/x32-avx-linux.c, features/i386/x32-avx.c,
	features/i386/x32-linux.c, features/i386/x32.c: Regenerate.
	* regformats/i386/amd64-avx-linux.dat, regformats/i386/amd64-avx.dat,
	regformats/i386/amd64-linux.dat, regformats/i386/amd64.dat,
	regformats/i386/i386-avx-linux.dat, regformats/i386/i386-avx.dat,
	regformats/i386/i386-linux.dat, regformats/i386/i386-mmx-linux.dat,
	regformats/i386/i386-mmx.dat, regformats/i386/i386.dat,
	regformats/i386/x32-avx-linux.dat, regformats/i386/x32-avx.dat,
	regformats/i386/x32-linux.dat, regformats/i386/x32.dat: Regenerate.

OK to commit?

Thanks,
(Continue reading)


Gmane