diff options
| author | Simon Marchi <simon.marchi@polymtl.ca> | 2021-05-27 15:18:49 -0400 |
|---|---|---|
| committer | Simon Marchi <simon.marchi@polymtl.ca> | 2021-05-27 15:18:49 -0400 |
| commit | 24b21115f522cd0fbe55986cd914a593576294ef (patch) | |
| tree | 6f2f71d9ede68e21d0371cc5db25b50d64de53af /gdb/i386-fbsd-nat.c | |
| parent | 01add95bed9afd5e7815439c3967db976be53f80 (diff) | |
| download | gdb-24b21115f522cd0fbe55986cd914a593576294ef.zip gdb-24b21115f522cd0fbe55986cd914a593576294ef.tar.gz gdb-24b21115f522cd0fbe55986cd914a593576294ef.tar.bz2 | |
gdb: fix tab after space indentation issues
I spotted some indentation issues where we had some spaces followed by
tabs at beginning of line, that I wanted to fix. So while at it, I did
a quick grep to find and fix all I could find.
gdb/ChangeLog:
* Fix tab after space indentation issues throughout.
Change-Id: I1acb414dd9c593b474ae2b8667496584df4316fd
Diffstat (limited to 'gdb/i386-fbsd-nat.c')
| -rw-r--r-- | gdb/i386-fbsd-nat.c | 16 |
1 files changed, 8 insertions, 8 deletions
diff --git a/gdb/i386-fbsd-nat.c b/gdb/i386-fbsd-nat.c index 76c7609..f15fd62 100644 --- a/gdb/i386-fbsd-nat.c +++ b/gdb/i386-fbsd-nat.c @@ -73,14 +73,14 @@ i386_fbsd_nat_target::resume (ptid_t ptid, int step, enum gdb_signal signal) ULONGEST eflags; /* Workaround for a bug in FreeBSD. Make sure that the trace - flag is off when doing a continue. There is a code path - through the kernel which leaves the flag set when it should - have been cleared. If a process has a signal pending (such - as SIGALRM) and we do a PT_STEP, the process never really has - a chance to run because the kernel needs to notify the - debugger that a signal is being sent. Therefore, the process - never goes through the kernel's trap() function which would - normally clear it. */ + flag is off when doing a continue. There is a code path + through the kernel which leaves the flag set when it should + have been cleared. If a process has a signal pending (such + as SIGALRM) and we do a PT_STEP, the process never really has + a chance to run because the kernel needs to notify the + debugger that a signal is being sent. Therefore, the process + never goes through the kernel's trap() function which would + normally clear it. */ regcache_cooked_read_unsigned (regcache, I386_EFLAGS_REGNUM, &eflags); |