From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,URIBL_BLACK autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 32652 invoked from network); 17 Apr 2022 19:51:04 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 17 Apr 2022 19:51:04 -0000 Received: (qmail 31968 invoked by uid 550); 17 Apr 2022 19:51:00 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 31933 invoked from network); 17 Apr 2022 19:50:59 -0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=k89wa81989jBul+jDG9cZhTRz4ugwoZn15nb4c5fqcbFbgKXUzBch2xouYryLx31Yw2ukcDsN+gNQP1v9xaNxEhwFkOZD/Jv0kuLomGGQFT6gxnaVN4Ct8fUbctxGgFCkKS7cEI31M9sSPUeiKC+aOZ43TXpMgBUpKrIe1kJinQEhawOLYkhqk3d1J3bj/r5rKg6qmG1NsElGNor5WxTCGmrr62YxnbHP/XjZr9/wy1xBXgzx2l2QNG3bJC9mKMpw2CDComZYE0866LUS4dV+0s1WjX4kxOMBvGOdzjqcrc62x13TPXBDtXSuWHy3876xd7xAmgMaVbltI9g2lsy/Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=dyQenKlxLj81v1CzKASoeUunLtI8y5SyBu+XJWOi2ZM=; b=n00SJ+UsR9bBGenvGtb1JUpOz1P2imlyyX9dcWXlBaIz8ZzUZh3bDK02tOhHS8zGh6WnA0n1mUDWEWDqjg6hCmgGhpp38KTe4zR3xv/HevXJ45soxJHL3Mv261Sg+IpxZYbjmOOy+kiISe+O/DAAAfo1Uh/cQbxilvO52byAAFnvlMsq/v3GSMulbb1TY4+JRUxSSF8QFzCkk+6CfxsNNc2bX3zUSpoZqhvXMQnIZQm7gA+DJO9RZThjTLG2IHX0FIR4eiFYGfqmy6DVNpVDAjc/J0Z5Ow4O5K7jCLVTgMuH6u7oztYcz9Cnfs/ZTg4qHpvPEzPhVPAy2X7TtxDhBg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none X-Gm-Message-State: AOAM532OF3/MWbGy0C7iUZdYK3DoAd8OqiOBSH7eOj5ptfIN3sgOPlfi w9B71vyWk92z+yxlu6CzB91Z9m8hh6agkQHyK40= X-Google-Smtp-Source: ABdhPJzXo+6HZO8nU3PRp4YaN1oJeZM9HFSPpECXIX6gVmzjyfRJZAjB5u92b7pKgjwewwKgHwYyc+vPl855U6d01z0= X-Received: by 2002:ab0:29cf:0:b0:35c:7820:8fc9 with SMTP id i15-20020ab029cf000000b0035c78208fc9mr1624862uaq.89.1650225043371; Sun, 17 Apr 2022 12:50:43 -0700 (PDT) References: <20210716121625.38409b91@vostro> <20210716155735.GC13220@brightrain.aerifal.cx> <20210717103338.3085f754@vostro> In-Reply-To: <20210717103338.3085f754@vostro> From: Fangrui Song Date: Sun, 17 Apr 2022 12:50:32 -0700 X-Gmail-Original-Message-ID: Message-ID: To: musl@lists.openwall.com Cc: Rich Felker , Timo Teras Content-Type: text/plain; charset="UTF-8" X-TMN: [W5ITaZeGXnLtoHOuadw/ozsqXWo/9im0] X-ClientProxiedBy: BN9PR03CA0984.namprd03.prod.outlook.com (2603:10b6:408:109::29) To MWHPR1201MB0110.namprd12.prod.outlook.com (2603:10b6:301:56::8) X-Microsoft-Original-Message-ID: MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 5156b861-a5d4-4aa6-bdda-08da20ab9034 X-MS-TrafficTypeDiagnostic: CY4PR1201MB2468:EE_ X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: DZR/2UPf6Tgw6QP6f47tqVOwZhFx60kkNskrcQpxu9dIxLA8L25QAZp/x/CNH6GbEEiL1yI3a6rIDLtVB1VsGl968oQ/BPOBOhJ/5pX9TVwc6QR1o1RRj54+mvx8lWmrNtkwrAle8q/KGBjjIvUCf+HCLthD8rXOMG0Qlssi10VDQfFtke7RjlRFcZr+K7m8ToTszV5xnV0Jo504NYyjv1dHEz8w8nySKLuUvWP1czZjPhJdrCptGbDeb8X8t93aOHkEATmyZev+R9p7eIksTMhp/R6CeMjtVEXHs7BUrUCEFhALzGayrYfaYqkAGn4UCiKlMMQFPCUHHCAdvLDLozHtF3+ZCStNOovL2Y+DoZRnZm8Qjgi9YoroTi4lxIHfHHGIRrDqvOF3IKKTeA7rnRdys0MMyAcMpx4M9VZnLrB1bYytrYjVjxDEEn6bG8PMVHL4xK2wyclttfcV0CQiWfRKbaZtLtJISbAQ3xqnyTXf6bjNIKuulRx5uAuLkwCPGHYdE9P+ap+ZSnKw+4gllEoUUVXv/M+2fxeWP0sQSBJwsCNF1wf2PdYAmKWQruQUWkpNhHLIecP0tr113Pj1Qg4b7DPq850iT67vcRVtO3Sn7VdecXA09eMwOsZZ/x9S X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?WlBhVFhHb3JUS1FqRHNFSDZYRjNpdkZjdUxpcGgzaU5LOGxYbEhGc0RhZnk0?= =?utf-8?B?S09mWC9iZDdkeDRDeThtZ0M4d3pXNEk5eFhWTFpESENGaWFYbkx6S2drcFg4?= =?utf-8?B?Uk9XcEJ1cDVFSUtqSnhnOFplREcyb3pPNitSNlZCQS9CL1ZlMjl4SVo2RzNT?= =?utf-8?B?L2R3TThWRVFzSjJLY0gvZEx6enNwNy9nenRqV2p0d3k5QkNEdFdIMHZLU2Yv?= =?utf-8?B?VUNxUmVDb3lkY093VWNuVlBOL1FDR0dwWlIxS2VhR2dkMW5JYlAwa0Z5WEVV?= =?utf-8?B?YThKdXlXdzMxdXVmZ0VYU3RpME0yR0RtWG9OZ01IVW1ROStRRmVjdUJjQVdI?= =?utf-8?B?bFNiTCt5eS9xRFBxZWhIRlFFSmVWNXVWTTlnUTlQcnErZUZhRFMvRWRVSXJ5?= =?utf-8?B?WU5WcUVPK2JzN3R2SjlyK0dwb0JsWmh0cFZTdVRuN2swaDVvT1YxZ08xb2JR?= =?utf-8?B?SHhGTlUvaGpaelRrbmpWalVCeHI0ZUxEM0xXTGw1UWFQVThuTkd1R3RFMkhM?= =?utf-8?B?ZWo5elJHZnpiMVZZbzdnMElRYVNpY3M2MEI5bXkwRWNjd3lTMUprUG8rNVZw?= =?utf-8?B?VElNMDArS0FWWjVOSmVQTDluRUxET0xtWGk4Zi8vekxsampFY1VTK1dBMEtN?= =?utf-8?B?cThjclIzQ01RNEh4bExnSXdRY2lBRzd0UTFJU1k3V3YwTndhUFkxbVRNNGNt?= =?utf-8?B?OFZrbjRkQVpuMm5ndmZKWHZuSC9UcGdUblBmeGtoUDgwRExZdU14MGFXMGFa?= =?utf-8?B?WlNnSXlJanExRzhrcmlBbFNPV3BoUmFjVzUyS0pqUFFIeEVwaUY3WktaTjFY?= =?utf-8?B?SHBOUjVvbUphVzJrZ1E4VFZ0Znc2R1JjWkhIdzBJQVJiME4vcDZsSEhXcEpT?= =?utf-8?B?b2xaWm82b1Q1RnYramlDaER2dWtyZStqMTVkZ3d0MDFsWnFEQXRQSDlvOHZq?= =?utf-8?B?S2FpUUJhUXB4Y1k2RkRaMVhtd3UyeTFJaFFSbk1zbXMzVU9uMm1raEZYYnFD?= =?utf-8?B?Y0RVT2lYTW5YVVByYjg0WTNaY25WL2hTeEUwRWYwK3ZhQVRJa2ZuRHIwVkVN?= =?utf-8?B?STllUWJRTklXL2lpb1M3eUd5cGd6dlU5OFVsT2Z3c0RCVXN1eWdXMW0rZXU4?= =?utf-8?B?N3dEQ29XYUpCeEM1aUVtOGZBRXUySUsyYTNpa2c3TC9ZQUh3eVRqU1lET2VC?= =?utf-8?B?QTlCRW9tVzRZcDFqZmJyN1dMNnc1NC82ZHBEcFdaS3JuUlQ0c09iTElnQkxp?= =?utf-8?B?aWwzQ2dzTXNQWVlQSUU1c2l3RnA2dWxpT215dDlxUytIY1pmUldTY29yS1NX?= =?utf-8?B?ZGxXcWhtV3Q2Rmg0U3NYSjJXMFY0US9YS3dkZ2srNndxYmFDc2JaUFNUNVVZ?= =?utf-8?B?WEZidHhLMjF1V3NFekt5blVhNVRxcmRKVjdFeC85cG9aZGhvWkMyWlVxUVE2?= =?utf-8?B?bkhqSE4yeUN4Y3hyRzNMRkJ6M3pqM25rSUIvQVVnczh2MnJUMEphVDZyajl1?= =?utf-8?B?VUNteGY3NERjOUJIL05hU04rOHRRY0V6VzFicUpXZFozQ293ek9iYmRxSmJj?= =?utf-8?B?c2pYRnZKMFlSM3NDSEZ3clhDRitVVXE1OWR6eXdNcTA2UnpGc1ArZjNNcUla?= =?utf-8?B?WGV4bC8zWGNWcm82TzYybG40b2lzS2JncGlPUTBQWHFCSG10SkV6alo1Yytj?= =?utf-8?B?QUlGV292WSs0UjlyeitvWXhiNEcwZmQ4OFhqblZUMFVrd2JYblJPRHoyUHdL?= =?utf-8?B?b2NBNC9HbVJMVlZlZzQ2d3d1aFRTbjRQMjcxWUhwKzZHdVpGcEpESjhTeS9R?= =?utf-8?B?VmlueEllYytnLy9NRXJaVDlLRGx2WGFIQ2NoSU80bGJqS3V2TFg0Yk05dlFP?= =?utf-8?B?OFJteC9VM1dNZlZhZW5KTDB4dVRSL1dRc3RHbEtQN1RrZVE9PQ==?= X-OriginatorOrg: sct-15-20-4755-11-msonline-outlook-5183d.templateTenant X-MS-Exchange-CrossTenant-Network-Message-Id: 5156b861-a5d4-4aa6-bdda-08da20ab9034 X-MS-Exchange-CrossTenant-AuthSource: MWHPR1201MB0110.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Apr 2022 19:50:46.2530 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR1201MB2468 Subject: Re: [musl] option to enable eh_frame On Sat, Jul 17, 2021 at 12:33 AM Timo Teras wrote: > > On Fri, 16 Jul 2021 11:57:35 -0400 > Rich Felker wrote: > > > On Fri, Jul 16, 2021 at 12:16:25PM +0300, Timo Teras wrote: > > > > The debugger already can do debugging/unwinding because it has access > > to the debug information (if you've installed it) and there is a > > clear, understood-by-users contract that this information is not an > > inherent part of the program but something optional for external > > debugging tools only. > > This apparently the fundamental difference in thinking. The debugging > information is often huge, and people don't want to install it on > production or embedded devices. It ships ton of other features which > are not needed. However, the unwind/backtrace feature does provide > significant value for error reports and profiling. > > > > > Arguments to have .eh_frame: > > > - It allows debugging things even if musl-dbg is not or cannot be > > > installed for some reason (e.g. gdb, valgrind), or is no longer > > > available > > > - libunwind/libexecinfo will start to work and give meaningful > > > backtraces > > > > This is explicitly a reason not to. backtrace() considered harmful. > > Please elaborate. I agree it's harmful from SEGV handler when program > might be targeted. But used in other situations where it is useful. Do > you have additional reasons why backtrace() is harmful? > > Do note that libunwind --enable-debug-frame is enabled default by > upstream package on ARM and aarch64, and this would work if the debug > package is installed. > > This gives inconsistent behaviour based on arch and whether -dbg is > installed. Developer might think the unwind stuff works, only to find > it breaks on different install, and make the application depend on -dbg. > > > > - Continuous kernel based profiling (e.g. perf record -g dwarf) > > > will work > > > > This already works if you have debug info. > > As said, it was desire to make it work without debug info. > > > > Given that the main arguments against are either making UB crash, or > > > not the best fix, and keeping eh_frame enables useful features to > > > work, I think it would make sense to allow enabling it. > > > > > > Please consider the the attached patch to make it a configure > > > option to enable keeping eh_frame (defaulting still to not keeping > > > it). > > > > You can solve this problem just as well for the things you want to > > have work by including the (part of) the debug info you want in the > > main libc.so binary: .debug_frame. Of course I can't stop Alpine from > > doing it in a different way locally, but I would strongly recommend > > you do that rather than making a contract that diverges from musl. > > The .debug_frame in main is a possibility, but no one else does it. > Well, apparently some ship the full debug build always to achieve some > of the same things. I think this also achieves the same divergence from > the normal expectation. > > As small side note, the -fno-*unwind-tables flags are also in "tryflags" > so if compiler would not support it, you don't get it. So depending on > compiler you might still get .eh_frame ;) > > The .eh_frame is a ELF abi feature normally turned on, and usually > needs good reasons to turn it off. Could you Rich please explain in > detail all the reasons why you think it's so evil? Mostly I heard > "feature X is evil and people should not use it" and I find that > your personal opinion, not a valid technical reason. But listening > more and earlier things, I've heard: > > 1. Having it makes it seem an application can jump through C library > from e.g. qsort callback. Not having .eh_frame makes C++ exception > fail, but does not help with e.g. setjmp/longjmp. So this is not > complete solution. > > 2. Explicitly disabling backtrace() universally. I assume this is to > disable to widespread usage of it from SEGV handler. But there > seem to be also implementations reading .debug_frame, so this does > not really fix that either fully. And I think there are valid use > cases for backtrace() also, e.g. when having debug build and having > internal debug printing trigger it. > > 3. Adds little bit if size to the binary. And also the runtime memory > usage as it goes to LOAD segment. But 80kB is not a concern on > modern environment even on embedded platforms. > > 4. You want to still enforce this so people don't do 1 or 2. > For this, time has taught me, people need education, not enforcement. > If you don't teach them, they'll still go and do the same stupid > things even more stupid ways. > > Please add in any reasons I may have missed. I would like to have your > complete list of reasons why to remove .eh_frame. So far it has been > coming out in pieces. I'd like constructive discussion if some of these > items could be implemented stronger in other means than removing > .eh_frame. > > Please also explain why you think the .eh_frame is sufficient even > though it does not cover various situations as explained above. > > Now it may have been little bit early for me to go ahead and merge the > change in Alpine before going through this discussion. The intention > was not upset anyone or be unilateral. This is why I made the PR and > waited for a good while for comments. Unfortunately, I did not find the > comments convincing, but granted I should have asked the above questions > before merging. > > Currently, I still think reasons to have .eh_frame than not are more > weighty - it enables valid use cases in expected way. But I'm also > willing to revert if there's stronger reasons to do it. Either > technical, or just keeping peace. So far the technical reasons do not > convince me, but keeping peace and good relationship is something I > definitely want. > > I personally did not see this as an ABI or a "contract" change, and this > is perhaps why I made the merge earlier than later. > > While the "contract" may *seem* somewhat different. It was still > mentioned in the commit message that the change was not made to make > C++ exception through C library work. The "contract promise" has not > changed; though, granted, the user perceived "de facto contract" has > changed in this case. > > As said, for me the primary reason is observability: being able to gdb > and get back traces, and continuous profiling work without debug info. > Those are precious things to have on system where debug info is simply > not available. As mentioned backtrace() working is a side effect, and I > think it has also valid use cases even if it's also often misused. > > But fundamentally I think if we ship .debug_frame, all people wanting > do backtrace() and the silly stuff, will just enable .debug_frame > support in their code and still do the silly stuff in worse way, than > if .eh_frame was enabled. Since technically they are the same, even if > the intended use case is different. As seen libunwind does have > --enable-debug-frame. > > For me it's quite unusual to have .debug_frame but not other debug > sections. I assume it works. But the tooling certain does not endorse > this setup. I suppose it can be achieved with some objcopy magic, but > requires care. > > Timo I know this is a very old thread but I'd like to share some findings on unwinding through musl functions. https://maskray.me/blog/2022-04-10-unwinding-through-signal-handler#musl-x86-64 My main finding is that nongnu libunwind does not recognize __restore_rt as a signal trampoline on x86-64. If -funwind-tables is used, __restore_rt may need some CFI instructions. linux perf seems to use libunwind. I am not familiar with the tool and so would like to hear how unwind tables improve linux perf usage on musl. An alternative to -funwind-tables is -fno-omit-frame-pointer.