| Summary: | Problems with accessing errno | ||
|---|---|---|---|
| Product: | gdb | Reporter: | Kevin Buettner <kevinb> |
| Component: | gdb | Assignee: | Kevin Buettner <kevinb> |
| Status: | ASSIGNED --- | ||
| Severity: | normal | CC: | pedro, vries |
| Priority: | P2 | ||
| Version: | HEAD | ||
| Target Milestone: | --- | ||
| Host: | Target: | ||
| Build: | Last reconfirmed: | ||
| Attachments: | C program for demonstrating problems w/ errno | ||
|
Description
Kevin Buettner
2024-03-27 02:10:18 UTC
I plan to look into these various errno problems... FWIW, this:
...
diff --git a/gdb/infcall.c b/gdb/infcall.c
index 23d5652dd21..bf836c93152 100644
--- a/gdb/infcall.c
+++ b/gdb/infcall.c
@@ -1092,9 +1092,13 @@ call_function_by_hand_dummy (struct value *function,
{
const char *name = get_function_name (funaddr,
name_buf, sizeof (name_buf));
- error (_("'%s' has unknown return type; "
- "cast the call to its declared return type"),
- name);
+ if (gdbarch_osabi (gdbarch) == GDB_OSABI_LINUX
+ && strcmp (name, "__errno_location") == 0)
+ values_type = lookup_pointer_type (builtin_type (gdbarch)->builtin_int);
+ else
+ error (_("'%s' has unknown return type; "
+ "cast the call to its declared return type"),
+ name);
}
values_type = check_typedef (values_type);
...
gives a few xpasses on the new test-case:
...
XPASS: gdb.base/check-errno.exp: macros: print errno
XPASS: gdb.base/check-errno.exp: macros: print (int) errno
XPASS: gdb.base/check-errno.exp: pthreads-macros: print errno
XPASS: gdb.base/check-errno.exp: pthreads-macros: print (int) errno
...
But it's still a bit hacky, in the sense that it doesn't fix ptype __errno_location, in other words, it only has effect when doing an inferior call.
The macro case should be fixed by adding the cast to the macro itself, IMNSHO. I.e., with a patch to glibc's errno header to insert the explicit cast there. Regarding the type of __errno_location...
When I run the test, compiled with -g3, on a machine without installed glibc debuginfo and also with debuginfod disabled, I see:
(gdb) p errno
'__errno_location' has unknown return type; cast the call to its declared return type
But, when I look at the DWARF for the binary, I see:
<1><32>: Abbrev Number: 2 (DW_TAG_subprogram)
<33> DW_AT_external : 1
<33> DW_AT_name : (indirect string, offset: 0x1f7e): __errno_location
<37> DW_AT_decl_file : 2
<38> DW_AT_decl_line : 37
<39> DW_AT_decl_column : 13
<3a> DW_AT_prototyped : 1
<3a> DW_AT_type : <0x3e>
<3e> DW_AT_declaration : 1
<1><3e>: Abbrev Number: 3 (DW_TAG_pointer_type)
<3f> DW_AT_byte_size : 8
<40> DW_AT_type : <0x44>
<1><44>: Abbrev Number: 4 (DW_TAG_base_type)
<45> DW_AT_byte_size : 4
<46> DW_AT_encoding : 5 (signed)
<47> DW_AT_name : int
So gdb could know the type if it didn't ignore it. (It is ignored in read_func_scope in gdb/dwarf2/read.c due to not having low and high pc attributes.)
Indeed. It has no pc range because it's a declaration (DW_AT_declaration).
It would also be interesting to test accessing errno in a program that never references it. Like:
int main()
{
return 0; // stop here and access errno.
}
This models a program that actually calls some function that sets errno, but in a different translation unit, potentially even in a library, and then the user wants to inspect errno.
Does your testcase cover this scenario?
This reminded me of clang's -fstandalone-debug, which is on by default:
https://clang.llvm.org/docs/UsersManual.html#cmdoption-fstandalone-debug
which I guess could also affect some of these scenarios.
(In reply to Pedro Alves from comment #5) > It would also be interesting to test accessing errno in a program that never > references it. Like: > > int main() > { > return 0; // stop here and access errno. > } > > This models a program that actually calls some function that sets errno, but > in a different translation unit, potentially even in a library, and then the > user wants to inspect errno. > > Does your testcase cover this scenario? No. I'd be inclined to write another/different test for that scenario. Also, I think that such a test should make a library/system call since the above example need not provide access to errno. |