public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Doug Evans <dje@google.com>
To: sami wagiaalla <swagiaal@redhat.com>
Cc: Tom Tromey <tromey@redhat.com>, gdb-patches@sourceware.org
Subject: Re: Regression for gdb.stabs/gdb11479.exp [Re: [patch 1/2] Use custom hash function with bcache]
Date: Wed, 01 Sep 2010 23:11:00 -0000	[thread overview]
Message-ID: <AANLkTimB6uPbPQOLY-0SFeG_Zfo0Ea1V1Xr0mj-j3cTB@mail.gmail.com> (raw)
In-Reply-To: <4C7EA94E.4010104@redhat.com>

On Wed, Sep 1, 2010 at 12:28 PM, sami wagiaalla <swagiaal@redhat.com> wrote:
>> I hope I'm not reducing the S/N ratio here, but there's something I
>> don't understand.
>> The original patch doesn't initialize obj_section (right?) (except by
>> virtue of using "static").  So if this fixes things, does it do so
>> only because we're taking advantage of the fact that obj_section will
>> be NULL in the static version
>
> Yes.
>
>  and that's sufficient?
>
> IIUC, it should be.
>
>  So do we need
>>
>> the memset of the original patch (which only zeros
>> psymbol.ginfo.value).
>>
>
> I don't really see why it is needed but I am inclined to believe the
> comment.

I think that stems from the old
bcache-the-entire-thing-as-a-byte-array behaviour, but that's gone now
(thankfully).

>> Plus, reverting to the original patch leaves me a little
>> uncomfortable: There's a comment that mentions gaps in the struct
>> causing cache misses, but that's no longer an issue with the custom
>> hash function (right?).
>
> I should probably fix that comment. The gabs in the struct, while bad, would
> not cause hash misses since the new supplied hash function only looks at the
> initialized fields.

Looking at the struct, and what's left to initialize, I like this patch.
Now everything is initialized.


2010-09-01  Doug Evans  <dje@google.com>

        * psymtab.c (add_psymbol_to_bcache): Initialize obj_section.

Index: psymtab.c
===================================================================
RCS file: /cvs/src/src/gdb/psymtab.c,v
retrieving revision 1.12
diff -u -p -r1.12 psymtab.c
--- psymtab.c   1 Sep 2010 21:50:26 -0000       1.12
+++ psymtab.c   1 Sep 2010 22:50:05 -0000
@@ -1394,6 +1394,7 @@ add_psymbol_to_bcache (char *name, int n
       SYMBOL_VALUE_ADDRESS (&psymbol) = coreaddr;
     }
   SYMBOL_SECTION (&psymbol) = 0;
+  SYMBOL_OBJ_SECTION (&psymbol) = NULL;
   SYMBOL_SET_LANGUAGE (&psymbol, language);
   PSYMBOL_DOMAIN (&psymbol) = domain;
   PSYMBOL_CLASS (&psymbol) = class;

WARNING: multiple messages have this Message-ID
From: Doug Evans <dje@google.com>
To: sami wagiaalla <swagiaal@redhat.com>
Cc: Tom Tromey <tromey@redhat.com>, gdb-patches@sourceware.org
Subject: Re: Regression for gdb.stabs/gdb11479.exp [Re: [patch 1/2] Use custom hash function with bcache]
Date: Wed, 01 Sep 2010 23:16:00 -0000	[thread overview]
Message-ID: <AANLkTimB6uPbPQOLY-0SFeG_Zfo0Ea1V1Xr0mj-j3cTB@mail.gmail.com> (raw)
Message-ID: <20100901231600.yKlIJhTiTghcvS_wpVovKmyItdI9bO0ly3XnMhY_P6Y@z> (raw)
In-Reply-To: <4C7EA94E.4010104@redhat.com>

On Wed, Sep 1, 2010 at 12:28 PM, sami wagiaalla <swagiaal@redhat.com> wrote:
>> I hope I'm not reducing the S/N ratio here, but there's something I
>> don't understand.
>> The original patch doesn't initialize obj_section (right?) (except by
>> virtue of using "static").  So if this fixes things, does it do so
>> only because we're taking advantage of the fact that obj_section will
>> be NULL in the static version
>
> Yes.
>
>  and that's sufficient?
>
> IIUC, it should be.
>
>  So do we need
>>
>> the memset of the original patch (which only zeros
>> psymbol.ginfo.value).
>>
>
> I don't really see why it is needed but I am inclined to believe the
> comment.

I think that stems from the old
bcache-the-entire-thing-as-a-byte-array behaviour, but that's gone now
(thankfully).

>> Plus, reverting to the original patch leaves me a little
>> uncomfortable: There's a comment that mentions gaps in the struct
>> causing cache misses, but that's no longer an issue with the custom
>> hash function (right?).
>
> I should probably fix that comment. The gabs in the struct, while bad, would
> not cause hash misses since the new supplied hash function only looks at the
> initialized fields.

Looking at the struct, and what's left to initialize, I like this patch.
Now everything is initialized.


2010-09-01  Doug Evans  <dje@google.com>

        * psymtab.c (add_psymbol_to_bcache): Initialize obj_section.

Index: psymtab.c
===================================================================
RCS file: /cvs/src/src/gdb/psymtab.c,v
retrieving revision 1.12
diff -u -p -r1.12 psymtab.c
--- psymtab.c   1 Sep 2010 21:50:26 -0000       1.12
+++ psymtab.c   1 Sep 2010 22:50:05 -0000
@@ -1394,6 +1394,7 @@ add_psymbol_to_bcache (char *name, int n
       SYMBOL_VALUE_ADDRESS (&psymbol) = coreaddr;
     }
   SYMBOL_SECTION (&psymbol) = 0;
+  SYMBOL_OBJ_SECTION (&psymbol) = NULL;
   SYMBOL_SET_LANGUAGE (&psymbol, language);
   PSYMBOL_DOMAIN (&psymbol) = domain;
   PSYMBOL_CLASS (&psymbol) = class;

WARNING: multiple messages have this Message-ID
From: Doug Evans <dje@google.com>
To: sami wagiaalla <swagiaal@redhat.com>
Cc: Tom Tromey <tromey@redhat.com>, gdb-patches@sourceware.org
Subject: Re: Regression for gdb.stabs/gdb11479.exp [Re: [patch 1/2] Use custom hash function with bcache]
Date: Wed, 01 Sep 2010 23:19:00 -0000	[thread overview]
Message-ID: <AANLkTimB6uPbPQOLY-0SFeG_Zfo0Ea1V1Xr0mj-j3cTB@mail.gmail.com> (raw)
Message-ID: <20100901231900.T3xYJLGkp6-xjm6NjTmcW7TVxymcyahVx5DJfYVy24E@z> (raw)
In-Reply-To: <4C7EA94E.4010104@redhat.com>

On Wed, Sep 1, 2010 at 12:28 PM, sami wagiaalla <swagiaal@redhat.com> wrote:
>> I hope I'm not reducing the S/N ratio here, but there's something I
>> don't understand.
>> The original patch doesn't initialize obj_section (right?) (except by
>> virtue of using "static").  So if this fixes things, does it do so
>> only because we're taking advantage of the fact that obj_section will
>> be NULL in the static version
>
> Yes.
>
>  and that's sufficient?
>
> IIUC, it should be.
>
>  So do we need
>>
>> the memset of the original patch (which only zeros
>> psymbol.ginfo.value).
>>
>
> I don't really see why it is needed but I am inclined to believe the
> comment.

I think that stems from the old
bcache-the-entire-thing-as-a-byte-array behaviour, but that's gone now
(thankfully).

>> Plus, reverting to the original patch leaves me a little
>> uncomfortable: There's a comment that mentions gaps in the struct
>> causing cache misses, but that's no longer an issue with the custom
>> hash function (right?).
>
> I should probably fix that comment. The gabs in the struct, while bad, would
> not cause hash misses since the new supplied hash function only looks at the
> initialized fields.

Looking at the struct, and what's left to initialize, I like this patch.
Now everything is initialized.


2010-09-01  Doug Evans  <dje@google.com>

        * psymtab.c (add_psymbol_to_bcache): Initialize obj_section.

Index: psymtab.c
===================================================================
RCS file: /cvs/src/src/gdb/psymtab.c,v
retrieving revision 1.12
diff -u -p -r1.12 psymtab.c
--- psymtab.c   1 Sep 2010 21:50:26 -0000       1.12
+++ psymtab.c   1 Sep 2010 22:50:05 -0000
@@ -1394,6 +1394,7 @@ add_psymbol_to_bcache (char *name, int n
       SYMBOL_VALUE_ADDRESS (&psymbol) = coreaddr;
     }
   SYMBOL_SECTION (&psymbol) = 0;
+  SYMBOL_OBJ_SECTION (&psymbol) = NULL;
   SYMBOL_SET_LANGUAGE (&psymbol, language);
   PSYMBOL_DOMAIN (&psymbol) = domain;
   PSYMBOL_CLASS (&psymbol) = class;

  reply	other threads:[~2010-09-01 23:04 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-08-16 14:11 [RFC] Use custom hash function with bcache sami wagiaalla
2010-08-16 18:29 ` Doug Evans
2010-08-16 18:56   ` Doug Evans
2010-08-16 19:56     ` sami wagiaalla
2010-08-19 16:32     ` [patch 1/2] Use custom hash function with bcache [Re: [RFC] Use custom hash function with bcache] sami wagiaalla
2010-08-19 20:26       ` Tom Tromey
2010-08-25 18:30         ` sami wagiaalla
2010-08-30 20:53           ` Tom Tromey
2010-09-01  8:25           ` Regression for gdb.stabs/gdb11479.exp [Re: [patch 1/2] " Jan Kratochvil
2010-09-01 16:20             ` Joel Brobecker
2010-09-01 16:47               ` Joel Brobecker
2010-09-01 17:03                 ` sami wagiaalla
2010-09-01 17:17                   ` Joel Brobecker
2010-09-01 18:09                 ` sami wagiaalla
2010-09-01 18:19                   ` Jan Kratochvil
2010-09-01 18:24                   ` Doug Evans
2010-09-01 18:38                     ` Tom Tromey
2010-09-01 19:01                       ` sami wagiaalla
2010-09-01 19:15                         ` Doug Evans
2010-09-01 19:17                           ` Doug Evans
2010-09-01 19:59                           ` sami wagiaalla
2010-09-01 23:11                             ` Doug Evans [this message]
2010-09-01 23:16                               ` Doug Evans
2010-09-01 23:19                               ` Doug Evans
2010-09-01 23:19                               ` Doug Evans
2010-09-02 15:43                               ` sami wagiaalla
2010-09-02 20:25                                 ` Doug Evans
2010-09-03 15:59                                   ` Doug Evans
2010-09-04 14:29                                     ` sami wagiaalla
2010-09-06  9:46                                       ` Daniel Jacobowitz
2010-08-16 19:14 ` [RFC] Use custom hash function with bcache Daniel Jacobowitz
2010-08-16 19:50   ` sami wagiaalla
2010-08-16 20:04     ` Daniel Jacobowitz
2010-08-16 20:11       ` sami wagiaalla
2010-08-16 20:49         ` Daniel Jacobowitz
2010-08-17 17:02           ` sami wagiaalla
2010-08-17 17:40             ` Daniel Jacobowitz
2010-08-17 23:26 ` Tom Tromey
2010-08-18 15:13   ` sami wagiaalla
2010-08-18 15:24     ` Tom Tromey
2010-08-19 16:33       ` sami wagiaalla
2010-08-19 16:37         ` [patch 2/2] Use custom hash function with bcache [Re: [RFC] Use custom hash function with bcache] sami wagiaalla
2010-08-19 20:32         ` [RFC] Use custom hash function with bcache Tom Tromey
2010-08-25 18:32           ` [patch 2/2] Use custom hash function with bcache [Re: [RFC] Use custom hash function with bcache] sami wagiaalla
2010-08-30 20:58             ` Tom Tromey
2010-08-30 21:13               ` Tom Tromey

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=AANLkTimB6uPbPQOLY-0SFeG_Zfo0Ea1V1Xr0mj-j3cTB@mail.gmail.com \
    --to=dje@google.com \
    --cc=gdb-patches@sourceware.org \
    --cc=swagiaal@redhat.com \
    --cc=tromey@redhat.com \
    /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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).