This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: PATCH: Add functions to write core notes for i386/amd64


On Mon, Apr 19, 2010 at 12:27 PM, Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
>> Date: Mon, 19 Apr 2010 12:03:39 -0700
>> From: "H.J. Lu" <hjl.tools@gmail.com>
>>
>> On Mon, Apr 19, 2010 at 11:46 AM, Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
>> >> Date: Mon, 19 Apr 2010 11:14:22 -0700
>> >> From: "H.J. Lu" <hjl.tools@gmail.com>
>> >>
>> >> On Mon, Apr 19, 2010 at 10:56 AM, Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
>> >> >> Date: Mon, 19 Apr 2010 09:20:11 -0700
>> >> >> From: "H.J. Lu" <hjl.tools@gmail.com>
>> >> >>
>> >> >> On Mon, Apr 19, 2010 at 9:03 AM, Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
>> >> >> > This adds the necessary backend functions to write proper core notes
>> >> >> > like the ppc code already has. ?This is necessary for GDB to generate
>> >> >> > proper 32-bit core dumps on 64-bit systems.
>> >> >> > ok?
>> >> >> >
>> >> >> >
>> >> >> > 2010-04-19 ?Mark Kettenis ?<kettenis@gnu.org>
>> >> >> >
>> >> >> > ? ? ? ?* elf64-x86-64.c (elf64_x86_64_write_core_note): New function.
>> >> >> > ? ? ? ?(elf_backend_write_core_note): Define.
>> >> >> > ? ? ? ?* elf32-i386.c (elf_i386_write_core_note): New function.
>> >> >> > ? ? ? ?(elf_backend_write_core_note): Define.
>> >> >> >
>> >> >>
>> >> >> It is not OK. I am not sure if it will work for Linux since Linux has
>> >> >> different note sizes.
>> >> >
>> >> > Where do you think I tested this code?
>> >> >
>> >> >> In any case, after
>> >> >>
>> >> >> http://sourceware.org/ml/binutils/2010-04/msg00131.html
>> >> >>
>> >> >> NT_PRPSINFO and NT_PRSTATUS should work fine on
>> >> >> Linux/x86-64.
>> >> >
>> >> > No, currently GDB writes out bogus notes for 32-bit core dumps on
>> >> > Linux/amd64 systems.
>> >>
>> >> Changing elf64-x86-64.c alone won't fix it. Have you tried your
>> >> GDB fix without changing elf64-x86-64.c?
>> >
>> > The change in elf64-x86-64.c won't help the 32-bit case at all. ?It is
>> > just there for consistency. ?And eventually *all* Linux ELF BFD
>> > targets should implement the core note writing functions of course.
>> >
>> > And yes, the elf32-i386.c change is not enough to fix things. ?But at
>> > least it will make things a bit clearer, since it will stop GDB from
>> > generating broken core dumps.
>> >
>> >> >> I think the proper way to fix it is to define PRPSINFO32_T and
>> >> >> PRPSINFO32_T for your x86-64 hosts.
>> >> >
>> >> > The long term plan in GDB is to make it possible to generate core
>> >> > dumps even on non-native configurations. ?In order to do that, it is
>> >> > necessary to add these functions that write out the proper core notes
>> >> > without depending on any host-specific header files.
>> >> >
>> >>
>> >> I thought about it. In theory, it is possible since GDB does have all
>> >> register info. I think reading core is OK today. Writing core is a problem.
>> >> I'd like to see the complete patch for non-native gcore. We may
>> >> need to adjust BFD interface to support it.
>> >
>> > No I don't have a diff; I was talking about long term plans. ?Further
>> > BFD changes may be necessary. ?But at least my diff brings Linux
>> > i386/amd64 with the other Linux target that implements biarch core
>> > file support in BFD.
>> >
>>
>> Please hold off your x86 BFD ELF core note patches since they
>> don't fix the real bug. We will revisit them together with non-native
>> gcore changes. I am not sure the current BFD interface is sufficient
>> ASIS.
>
> EDEADLOCK
>

What does it mean? My feeling is that you don't need to change
x86 BFD ELF core note functions for Linux/x86-64 GDB to generate
working Linux/i386 coredump. Please fix the GDB side first.

Thanks.


-- 
H.J.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]