From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.polymtl.ca (smtp.polymtl.ca [132.207.4.11]) by sourceware.org (Postfix) with ESMTPS id 5DE5B385381D for ; Wed, 18 Aug 2021 20:49:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 5DE5B385381D Received: from simark.ca (simark.ca [158.69.221.121]) (authenticated bits=0) by smtp.polymtl.ca (8.14.7/8.14.7) with ESMTP id 17IKnbSZ008267 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 18 Aug 2021 16:49:42 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp.polymtl.ca 17IKnbSZ008267 Received: from [10.0.0.11] (192-222-157-6.qc.cable.ebox.net [192.222.157.6]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 5B5C91E4A3; Wed, 18 Aug 2021 16:49:37 -0400 (EDT) Subject: Re: GDB call and p func() on embedded target To: Maximilian Schneider , gdb@sourceware.org References: <10f7f78c-ac4d-b54f-b250-c915203c6f47@polymtl.ca> <6c9c737155f28ea174457f4a0eb41e1e408a73b3.camel@schneidersoft.net> <774bfb5f-7117-911f-58fc-c884ce92993c@polymtl.ca> From: Simon Marchi Message-ID: <39e739a1-c7b8-18ae-b78f-ee1bfdfa6e20@polymtl.ca> Date: Wed, 18 Aug 2021 16:49:36 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Poly-FromMTA: (simark.ca [158.69.221.121]) at Wed, 18 Aug 2021 20:49:37 +0000 X-Spam-Status: No, score=-5.0 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gdb@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2021 20:49:54 -0000 On 2021-08-18 4:31 p.m., Maximilian Schneider wrote: > Thank you for the great information! > > Turns out it was the start address. Since gdb is setting up a frame to > call my function and then return to the start address; it is no wonder > that it does not work. 0 is neither ram not flash so sw breakpoints > will not work there. HW breakpoints probably won't work there either. > > I added -e 0x2000000 to the compilation to set an explicit entry point > and huzza it works :) Ok, good news! > If gdb is already putting code on the stack to call my function why not > implement a sw breakpoint there? Why return to start? > > Why does gdb care at all what the start address is? Since this is an > external loader that lives in ram and has no main() i don't see what > the point of the entry point is. GDB just needs a place it can put a breakpoint and redirect execution to, to get back control when the inferior function call is done. It just happens that the entry point usually works fine for that, at least when you are talking about a program that runs on an OS like Linux. I guess it just doesn't work in all cases, such as yours. As we saw, other architectures do use the stack for this, they have gdbarch_call_dummy_location return ON_STACK and implement gdbarch_push_dummy_code. I suppose you would have to make the ARM architecture do that to make it work properly in your case. Simon