Path: csiph.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Stefan Reuther Newsgroups: comp.arch.embedded Subject: Re: Makefile or IDE? Date: Sun, 12 Dec 2021 11:27:00 +0100 Lines: 64 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: individual.net AsQtSVoNm95Kw7W9ZCJbaQ2J/0UxjfZSqc2lI9cx4zp1VfKPs1 Cancel-Lock: sha1:TQFWqoaLRatsvQB1jEOFiByJBpk= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 Hamster/2.1.0.1538 In-Reply-To: Xref: csiph.com comp.arch.embedded:30964 Am 11.12.2021 um 18:47 schrieb Hans-Bernhard Bröker: > Am 11.12.2021 um 10:01 schrieb Stefan Reuther: >> Am 10.12.2021 um 18:35 schrieb Hans-Bernhard Bröker: >>> But let's face it: we very rarely even look at object files, much less >>> work on them in any meaningful fashion.  They just have to be somewhere, >>> but it's no particular burden at all if they're all in a single folder, >>> per primary build target. >> >> But sometimes, we do look at them. Especially in an embedded context. > > In my experience, looking at individual object files does not occur in > embedded context any more often than in others. Neither in my experience, but this is because I look at individual object files even for desktop/server applications, but I don't expect that to be the rule :) >> Or to >> answer the question "how much code size do I pay for using this C++ >> feature?". "Did the compiler correctly inline this function I expected >> it to inline?". > > Both of those are way easier to check in the debugger or in the mapfile, > than by inspecting individual object files. For me, 'objdump -dr blah.o | less' or 'nm blah.o | awk ...' is the easiest way to answer such questions. The output of 'objdump | less' is much easier to handle than gdb's 'disas'. And how do you even get function sizes with a debugger? >> And if the linker gives me a "duplicate definition" error, I prefer that >> it is located in 'editor.o', not '3d3901cdeade62df1565f9616e607f89.o'. > > Both are equally useless. You want to know which source file they're in, > not which object files. I want to know in what translation unit they are in. It doesn't help to know that the duplicate definition comes from 'keys.inc' which is supposed to be included exactly once. I want to know which two translation units included it, and for that it helps to have the name of the translation unit - the initial *.c/cpp file - encoded in the object file name. > Do you actually use a tool that obfuscates the o file nimes like that? Encoding the command-line that generates a file (as a cryptographic hash) into the file name is a super-easy way to implement rebuild-on-rule-change. I use that for a number of temporary files. I do not use that for actual object files for the reasons given, but it would technically make sense. > I don't think you've actually mentioned a single one, so far.  None of > the things you mentioned had anything to do with _where_ the object > files are. There are no hard technical reasons. It's all about usability, and that's about the things you actually do. If you got a GUI that takes you to the assembler code of a function with a right-click in the editor, you don't need 'objdump'. I don't have such a GUI and don't want it most of the time. Stefan