[sorry for the delay, busy with univ.]
I feel really utterly stupid, I was using a old objdump that didn't
have the needed tweak you posted (bfd groking lwpstatus_t.pr_fpreg).
I still do not know what is wrong with gdb not being able to read the
core dump, but here is the output from the objdump i
> I'm a bit confused about the padding that we add to the core note
> segment in elfcore.c, it seems that it is 8 bytes long.
I really have no idea exactly what you are talking about. Be specific.
> If that is the case, then I really can't see any problems in the reading
> code, here is a smal
I'm a bit confused about the padding that we add to the core note
segment in elfcore.c, it seems that it is 8 bytes long. If that is
the case, then I really can't see any problems in the reading code,
here is a small bit from my debug session:
,
| Breakpoint 3, elfcore_grok_lwpstatus (abfd=0x
>>This is clearly wrong, it being zero. This suggests to me that
>>elfcore_grok_lwpstatus still does not have
>>HAVE_LWPSTATUS_T_PR_FPREG. Can you check that again?
>>
>> Yes, it is defined and all.
>
>Then you will have to step through that function to see w
,
| (top-gdb) x/480 note->descdata
| 0x82bf854: 0x 0x 0x 0x
| 0x82bf864: 0x 0x 0x001f 0x001f
| 0x82bf874: 0x001f 0x001f 0x 0x0003
| 0x82bf88
>This is clearly wrong, it being zero. This suggests to me that
>elfcore_grok_lwpstatus still does not have
>HAVE_LWPSTATUS_T_PR_FPREG. Can you check that again?
>
> Yes, it is defined and all.
Then you will have to step through that function to see what it is
d
>This is clearly wrong, it being zero. This suggests to me that
>elfcore_grok_lwpstatus still does not have
>HAVE_LWPSTATUS_T_PR_FPREG. Can you check that again?
>
> Yes, it is defined and all.
Then you will have to step through that function to see what it is doing.
I can't see how
> | 3 .reg2/23268 2**2
> | CONTENTS
> | 4 .reg2 2**2
> | CONTENTS
This is clearly wrong, it being zero. This suggests to me that
elfcore_grok_lwpstat
> | 1 .reg/23268004c 2554 2**2
> | CONTENTS
> | 2 .reg 004c 2554 2**2
> | CONTENTS
This offset (0x2554) might be right for that file, or maybe 4 off.
I haven't triple-checked the calcul
You can snatch it from: http://user.it.uu.se/~alsz8747/core.23268
That should be: http://user.it.uu.se/~alsz8747/core.23268
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
All the pr_*id values look sane to me. pr_[ug]id and pr_egid are
(unsigned)-1. If you look at elfcore.c, this is what to expect.
Ahhh... Why didn't I think of that.
> If you want to check it yourself, I can always send you the core
> dump, it is only 30k compressed.
Sure.
You c
>Like I said, this is the internal contents of the note. readelf
>tells you the sizes and locations of the note, and if those are
>sane, you can look at the data directly and interpret according to
>the struct type. This is what you have to do to have anything to
>say about wh
Like I said, this is the internal contents of the note. readelf
tells you the sizes and locations of the note, and if those are
sane, you can look at the data directly and interpret according to
the struct type. This is what you have to do to have anything to
say about whether the
> readelf doesn't produce much useful info IMHO. Like if fpregset etc
> are there or not.
Like I said, this is the internal contents of the note. readelf tells you
the sizes and locations of the note, and if those are sane, you can look at
the data directly and interpret according to the struct
[sorry for the late reply]
What bfd reports as sections are synthesized from the note data.
core files don't really have any sections. The clearest way to see
their contents is with readelf. Then you can tell whether the file
is wrong, or if the BFD code that reads it for gdb is wron
What bfd reports as sections are synthesized from the note data. core
files don't really have any sections. The clearest way to see their
contents is with readelf. Then you can tell whether the file is wrong, or
if the BFD code that reads it for gdb is wrong.
In the NT_LWPSTATUS note format tha
Hi, I'm back for a bit of hacking...
The notes are all ok so that was barking up the wrong tree, the
culprint here seems to be somwehere when reading or dumping the
fpregset data (which really should have been obvious!). I looked at
the actual core dump a bit, and it seems that the .reg2 (the one
17 matches
Mail list logo
