| Message ID | 20231123160535.18658-2-roger.pau@citrix.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | livepatch-build-tools: fixes for non GNU tools | expand |
On Thu, Nov 23, 2023 at 4:08 PM Roger Pau Monne <roger.pau@citrix.com> wrote: > > And instead use plain awk. > > There's no need to use the --non-decimal-data option for gawk, since the > numbers that we want to print are already prefixed with '0x', and so plain awk > will do the conversion from hexadecimal to decimal just fine. I don't think that's true (at least with gnu awk 5.1.1): $ echo '<e98b7> DW_AT_byte_size : 0x14' | awk '{printf("%d\n", $4)}' 0 Having said that, my version of readelf actually gives the value in decimal so the patch still works. But is that the case for all versions of readelf? I assume the code was written like that for a reason... Ross
On 24/11/2023 11:43, Ross Lagerwall wrote: > On Thu, Nov 23, 2023 at 4:08 PM Roger Pau Monne <roger.pau@citrix.com> wrote: >> >> And instead use plain awk. >> >> There's no need to use the --non-decimal-data option for gawk, since the >> numbers that we want to print are already prefixed with '0x', and so plain awk >> will do the conversion from hexadecimal to decimal just fine. > > I don't think that's true (at least with gnu awk 5.1.1): > > $ echo '<e98b7> DW_AT_byte_size : 0x14' | awk '{printf("%d\n", $4)}' > 0 > I think it's a FreeBSD quirk. From their man page: > Historically, awk did not accept "0x" as a hex string. However, since > One True Awk used strtod to convert strings to floats, and since "0x12" > is a valid hexadecimal representation of a floating point number, On > FreeBSD, awk has accepted this notation as an extension since One True > Awk was imported in FreeBSD 5.0. Upstream One True Awk has restored > the historical behavior for better compatibility between the different > awk implementations. Both gawk and mawk already behave similarly. > Starting with FreeBSD 14.0 awk will no longer accept this extension. I'm guessing the latest FreeBSD doesn't have that behaviour either? Cheers, Alejandro
On Fri, Nov 24, 2023 at 12:10:57PM +0000, Alejandro Vallejo wrote: > On 24/11/2023 11:43, Ross Lagerwall wrote: > > On Thu, Nov 23, 2023 at 4:08 PM Roger Pau Monne <roger.pau@citrix.com> > wrote: > >> > >> And instead use plain awk. > >> > >> There's no need to use the --non-decimal-data option for gawk, since the > >> numbers that we want to print are already prefixed with '0x', and so > plain awk > >> will do the conversion from hexadecimal to decimal just fine. > > > > I don't think that's true (at least with gnu awk 5.1.1): > > > > $ echo '<e98b7> DW_AT_byte_size : 0x14' | awk '{printf("%d\n", $4)}' > > 0 > > > > I think it's a FreeBSD quirk. From their man page: Seems like BusyBox inherited that behavior: BusyBox v1.36.1 (2023-07-27 17:12:24 UTC) multi-call binary. $ echo '<e98b7> DW_AT_byte_size : 0x14' | awk '{printf("%d\n", $4)}' 20 I've assumed that Busybox was the lowest common denominator, but not in this case. > > Historically, awk did not accept "0x" as a hex string. However, > since > > One True Awk used strtod to convert strings to floats, and since > "0x12" > > is a valid hexadecimal representation of a floating point number, > On > > FreeBSD, awk has accepted this notation as an extension since One > True > > Awk was imported in FreeBSD 5.0. Upstream One True Awk has > restored > > the historical behavior for better compatibility between the > different > > awk implementations. Both gawk and mawk already behave similarly. > > Starting with FreeBSD 14.0 awk will no longer accept this > extension. > > I'm guessing the latest FreeBSD doesn't have that behaviour either? Hm, I guess my FreeBSD world is not new enough, as the awk (version 20210724) I have does parse hex numbers: # echo '<e98b7> DW_AT_byte_size : 0x14' | awk '{printf("%d\n", $4)}' 20 Will see what I can do to address this without requiring gawk if possible. I'm not sure if there are other issues that would prevent livepatch-build-tools from working on FreeBSD however. Thanks, Roger.
diff --git a/livepatch-build b/livepatch-build index 91d203bda0eb..26c88a2ed2c3 100755 --- a/livepatch-build +++ b/livepatch-build @@ -422,7 +422,7 @@ if [ "${SKIP}" != "build" ]; then echo "Reading special section data" # Using xen-syms built in the previous step by build_full(). SPECIAL_VARS=$(readelf -wi "$OUTPUT/xen-syms" | - gawk --non-decimal-data ' + awk ' BEGIN { a = b = e = 0 } a == 0 && /DW_AT_name.* alt_instr/ {a = 1; next} b == 0 && /DW_AT_name.* bug_frame/ {b = 1; next}
And instead use plain awk. There's no need to use the --non-decimal-data option for gawk, since the numbers that we want to print are already prefixed with '0x', and so plain awk will do the conversion from hexadecimal to decimal just fine. Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> --- livepatch-build | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) base-commit: e588b7914e7afa3abb64b15a32fc2fdb57ded341