From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9047 invoked by alias); 2 May 2018 16:31:34 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 9025 invoked by uid 89); 2 May 2018 16:31:34 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=(unknown) X-HELO: a2-124.smtp-out.eu-west-1.amazonses.com Received: from a2-124.smtp-out.eu-west-1.amazonses.com (HELO a2-124.smtp-out.eu-west-1.amazonses.com) (54.240.2.124) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 02 May 2018 16:31:32 +0000 Subject: Re: [PATCH 3/4] Explicit fixed-width integral File I/O protocol types From: =?UTF-8?Q?Julio_Guerra?= To: =?UTF-8?Q?Joel_Brobecker?= Cc: =?UTF-8?Q?Pedro_Alves?= , =?UTF-8?Q?gdb-patches=40s?= =?UTF-8?Q?ourceware=2Eorg?= , =?UTF-8?Q?Mike_Frysinger?= Date: Wed, 02 May 2018 16:31:00 -0000 Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable In-Reply-To: <20180502161423.b57daq6zke6yxc63@adacore.com> References: <20180428011940.115515-1-julio@farjump.io> <20180428011940.115515-4-julio@farjump.io> <332abe88-4b88-3f06-7141-31a798f2b153@farjump.io> <01020163216ed537-dae77402-9d35-42f2-ad27-64c89137aa03-000000@eu-west-1.amazonses.com> <20180502161423.b57daq6zke6yxc63@adacore.com> Message-ID: <0102016321b1caae-c6368e6f-f4ec-468c-803e-ab7fd0de0c46-000000@eu-west-1.amazonses.com> X-SES-Outgoing: 2018.05.02-54.240.2.124 Feedback-ID: 1.eu-west-1.b24dn6frgCi6dh20skzbuMRr7UL8M6Soir/3ogtEjHQ=:AmazonSES X-IsSubscribed: yes X-SW-Source: 2018-05/txt/msg00021.txt.bz2 Le 02/05/2018 =C3=A0 18:14, Joel Brobecker a =C3=A9crit=C2=A0:=0D >> Since I am talking a lot of embedded software, I CC'd Joel Brobecker=0D >> from AdaCore to maybe give the final direction for a v2.=0D > I'm not really sure what is expected of me, can you clarify? If you=0D > are thinking of my experience with baremetal targets, that's no problem.= =0D > But, although I do work with C code on baremetal targets, it tends=0D > to be in situations where we have a C library (based on newlib, for=0D > the most part).=0D Yes, this is why I thought of you.=0D > Are we talking about the remote File-IO extension? I should say up front= =0D > that my knowledge of this extension was nearly null until I read the=0D > documentation in the manual. I think Pedro is the expert on that.=0D Yes, we are talking about the File IO extension.=0D > If I understand correctly, you are arguing that we should be providing=0D > fileio.h so that programs being debugged can use it? I don't understand=0D > how this would integrate with GDB, though. If I understand correctly,=0D > this file is used for the definition of some structures used within=0D > the remote protocol, so the information exchanged between GDB and=0D > GDBserver. How would you exploit that? (what this tells me is that=0D > your patch series deserves a documentation update)=0D No, these structures in fileio.h are passed from GDB to the target=0D program being debugged through its GDBserver.=0D =0D When encapsulated in the newlib, it requires to stub the available=0D syscalls using this extension (that's what we do) . The situation is the=0D same at the stub level (redefining File IO structures, changing the=0D endianness if necessary, and copying them into standard structures (for=0D struct stat and struct timeval).=0D =0D Ok, so let's wait Pedro's answer ;)=0D =0D Thank you,=0D =0D -- =0D Julio Guerra=0D =0D